Lin-bus в магнитоле

Обновлено: 29.01.2025

Для работы с CAN шиной автомобиля необходимо знать:

CAN шина – это сеть обмена данными определенная в стандарте ISO 11898. Другие каналы обмена данными в автомобиле не могут быть названы CAN шиной. AVC-LAN, BEAN, J1708, VAN и другие старые протоколы это НЕ CAN !

В автомобиле может быть более одной CAN шины. Для каждого функционального сегмента автомобиля выделяется своя сеть CAN. Выделенные сети могут работать на разных скоростях.

Скорости работы CAN шины

CAN на разных автомобилях и в разных сегментах сети может работать на разных скоростях.

Названия сегментов сети: Мотор, Шасси, Комфорт, Салон – условны! У Каждого автопроизводителя свои названия этих участков сети!

Группа VAG: Мотор\шасси – 500 кбит\с, Комфорт – 100 кбит\с и с 2018 года шина Комфорт может иметь скорость 500 кбит\с., Диагностика: 500 кбит\с.
BMW : Мотор\Шасси – 500кбит\с, Комфорт – 100 кбит\с и с 2018 года шина Комфорт может иметь скорость 500 кбит\с., Диагностика: 500 кбит\с.
Mercedes-Benz : Мотор\Шасси – 500 кбит\с, Комфорт 83.333 кбит\с, 250 кбит\с, Диагностика: 500 кбит\с.
Ford, Mazda : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с. (Для Ford может быть больше вариантов)
KIA\Hyundai : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с, 500 кбит\с, Мультимедиа: 125 кбит\с, 500 кбит\с., Диагностика: 500 кбит\с.
GM : Мотор\Шасси – 500 кбит\с, Комфорт: 33.333 кбит\с, 95.2 кбит\с, Диагностика: 500 кбит\с.
Toyota, Nissan, Honda, Subaru, Suzuki : 500 кбит\с (может использоваться гейтвей)
Mitsubishi : Мотор\Шасси: 500 кбит\с, Салон\Комфорт – 83.333 кбит\с, 250 кбит\с, Диагностика: 500 кбит\с.
Volvo : Мотор\Шасси: 500 кбит\с, Салон\Комфорт – 500 кбит\с, 125 кбит\с, Диагностика: 500 кбит\с.
Renault : 500 кбит\с
Peugeot : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с.
Lada : 500 кбит\с
Коммерческая и специальная техника : Стандарт J1939 250 или 500 кбит\с.

Сегментация CAN шины по функциональному назначению

Как правило разные, сегменты сети разделены специальным устройством, которое называется Гейтвей (Gateway, ZGW, ETACS, ICU) .
В роли гейтвея может выступать панель приборов (для простых автомобилей) или отдельный специальный модуль межсетевого интерфейса.
Гейтвей разделяет потоки данных в разных сегментах сети и обеспечивает связь сегментов сети работающих на разных скоростях.
ВАЖНО: На многих автомобилях (особенно VAG, MB, BMW) CAN шина в диагностическом разъеме OBD2 отделена от других участков сети при помощи гейтвея, поэтому подключившись к CAN шине OBD разъема невозможно увидеть поток данных. В этом случае можно увидеть только обмен между диагностическим инструментом и автомобилем во время процесса диагностики! Так же модулем гейтвеем оборудованы автомобили японских марок с 2016..2018 годов в зависимости от модели.
ОБЯЗАТЕЛЬНО изучайте схемы на исследуемый автомобиль, чтобы знать к какому сегменту сети Вы подключаетесь!

Схема ниже изображена в общем виде для упрощения понимания роли Гейтвея. Количество CAN шин и варианты включения блоков управления к тому или другому сегменту сети могут отличаться.

Реализации CAN на уровне электрических сигналов

CAN шина может быть реализована физически тремя способами:

Классическая витая пара нагруженная с обоих концов резисторами 120 Ом.

В этом случае уровни на шине CAN выглядят так:

Для такой реализации сети используются как правило обычные CAN трансиверы в 8 выводном корпусе, аналоги PCA82C250, TJA1050 и им подобные. Работает такая конфигурация на скоростях 500 кбит\с и выше. (Но могут быть исключения) .

В этом варианте используется та же витая пара, но линии CAN-Low и CAN-High подтянуты к напряжению питания и массе соответственно.
Подробное описание FT-CAN по ссылке
Такой вариант CAN шины способен переключаться в однопроводный режим в случае повреждения одной из линий. Работает на скоростях до 250 кбит\с.Уровни сигнала на шине отличаются от High Speed CAN, при этом не теряется возможность работы с шиной FT-CAN используя трансиверы High-Speed CAN и соблюдая ряд условий.
Подробнее в нашей статье о FT-CAN – ссылка.

Fault tolerant CAN обычно используется для низкоскоростного обмена между блоками управления относящимися к сегменту сети Салон\Комфорт\Мультимедиа.

ВАЖНО: При подключении к шине Faul tolerant CAN, подключать терминальный резистор 120 Ом между линиями CAN-High и CAN-Low НЕ НУЖНО !

3 Single Wire CAN или SW-CAN

Однопроводный вариант шины CAN. Работает на скорости 33.333 кбит\с

Используется специальный тип трансиверов. Для того что бы подключиться к такому варианту шины CAN необходимо линию CAN-High анализатора подключить к шине SW-CAN а линию CAN-Low к массе\земле.

Встречайте третью часть из серии статей, посвященных протоколу LIN, предыдущие части доступны по ссылкам:

И в этой статье мы займемся ровно тем, чем и планировали, а именно напишем свой драйвер для обмена данными по LIN. Базой послужит обычный модуль UART микроконтроллера STM32. Но при желании можно будет легко портировать драйвер на любой другой микроконтроллер, внеся незначительные изменения. Никаких аппаратных возможностей именно STM32 для протокола LIN мы использовать не будем, все по-честному 👍

Итак физически драйвер по классике будет состоять из двух файлов - заголовочного и файла с исходным кодом:

Цель поставим себе такую - сделать использование LIN максимально простым, то есть вызвали одну функцию отправки/приема - получили результат. Вся остальная работа будет скрыта внутри драйвера.

Как и во второй статье цикла отправной точкой будут служить возможные состояния устройства при работе в качестве Master'а или Slave'а. Только здесь список состояний будет расширенным относительно нашего первого примера:

Без лишних слов переходим сразу к делу. И первое на очереди - это генерация (в случае ведущего устройства) и детектирование (в случае подчиненного) поля Break. Для этой задачи мы задействуем один из таймеров - выбрать можно абсолютно любой. Кроме того, само собой, необходимо выделить один из модулей USART для работы с LIN. Настраиваем все вышеперечисленное в STM32CubeMx:

Таймер у меня будет генерировать прерывание по переполнению каждые 25 мкс.

В программе объявим указатели для хранения данных обо всех выбранных периферийных модулях, то есть об USART'е, таймере и портах, которые будут работать в качестве сигналов Rx и Tx этого USART'а:

Да, кстати, конечно же, по устоявшейся традиции полный проект я прикреплю в конце статьи. При необходимости использования LIN в своих разработках можно не вникать в работу драйвера, а просто добавить к себе и использовать.

Продолжаем. Все эти указатели нужны для того, чтобы при изменении конкретной периферии, то есть перехода, например, с таймера TIM4 на TIM3 правки необходимо было произвести только в одном месте. А именно в функции инициализации LIN, вот, собственно, ее код:

В демо-примере для проверки работы драйвера у меня выбраны USART2, TIM4 и устройство работает в режиме Slave:

Кроме прочего, здесь еще выбираются ножки контроллера, относящиеся к USART'у. Концепция точно такая же - при изменении выводов нужно будет менять программу только в одном месте, а не искать обращения к периферии везде по коду драйвера.

Как видите, при инициализации мы также рассчитываем значения нескольких переменных:

breakCntLimit - это длительность поля Break, приведенная к периоду нашего таймера. В прерывании по переполнению таймера при генерации Break мы будем увеличивать счетчик. Соответственно, переменная breakCntLimit показывает, сколько раз должен переполниться таймер за время брейка.
breakCntUpperLimit и breakCntLowerLimit - это верхний и нижний порог для обнаружения Break. Если счетчик попадает в этот интервал, то мы считаем, что брейк обнаружен.

В дефайны вынесены некоторые конфигурационные параметры:

LIN_TIMER_PERIOD_US - здесь мы указываем выбранный нами ранее период переполнения таймера.
LIN_BREAK_SIZE_BITS - размер поля Break в битах.
LIN_BREAK_DEVIATION_PERCENT - задает окно для обнаружения брейка относительно идеальной длительности, равной breakCntLimit . В нашем случае получаем ±10%.

Итак, давайте разберемся, как мы будем генерировать и отлавливать Break. С обнаружением все, в целом, несложно - если у нас Slave находится в режиме LIN_RECEIVING_BREAK , то в прерывании по таймеру проверяем уровень сигнала на ножке Rx:

Если точнее, то это происходит в функции LIN_TimerProcess() , которую мы вызываем из callback'а по переполнению. Если на ножке 0, то начинаем увеличивать счетчик breakCnt . Когда на Rx появляется единица - проверяем, что значение счетчика попадает в нужный нам интервал:

При отправке брейка задача усложняется. Нам нужно переконфигурировать Tx USART'а на работу в режиме обычного порта ввода-вывода, а затем, после отправки Break, вернуть все на круги своя:

И снова возвращаемся в обработчик прерывания таймера:

Обратите внимание, что здесь нам нет необходимости использовать диапазон допустимых значений длительности брейка. Просто сравниваем с идеальным рассчитанным значением breakCntLimit . Это вытекает из того, что при приеме длительность может плавать в зависимости от разных факторов, а при генерации брейка мы четко инкрементируем счетчик и выдаем нужный временной интервал.

В прерывании таймера у нас решается еще одна задача, а именно проверка на потерю части LIN пакета:

Когда устройство находится в ожидании принятых данных (идентификатора, байта данных или поля синхронизации), начинаем увеличивать счетчик rxTimeoutCnt . Обнуляется этот счетчик в callback'е по окончанию приема данных по USART. Соответственно, если данные так и не пришли, то rxTimeoutCnt становится равен rxTimeoutCntLimit и мы обрываем прием и переходим в состояние ожидания. Значения порога в микросекундах задается так:

Перемещаемся в функцию LIN_UartProcess() , вызывается она из callback-ов по окончанию приема и передачи данных по USART. И в ней мы, соответственно, обрабатываем поочередно все состояния LIN-устройства. Многое кстати похоже на то, что мы делали в предыдущей статье по протоколу LIN.

Не буду приводить полный код, ссылка обязательно будет в конце статьи, давайте лучше разберемся, как использовать наш драйвер в своем проекте. И для этого у нас есть ряд функций. Во первых, функция инициализации, с которой мы уже сталкивались:

Далее идет функция для организации процесса передачи данных:

Возможные возвращаемые значения выглядят следующим образом:

В качестве аргументов мы передаем PID, указатель на данные и количество байт для передачи. Контрольную сумму здесь не учитываем отдельным байтом и не добавляем в отправляемые данные, все произойдет автоматически. Чтобы отследить окончание передачи, можно использовать функцию:

Возвращаемое значение соответствует состоянию устройства. По окончанию передачи произойдет переход в режим ожидания - LIN_IDLE , что и можно отследить.

При использовании этой функции для Master'а в линию будут отправлены последовательно:

Поскольку Slave в LIN не может сам инициировать обмен данными, то для подчиненного эту функцию имеет смысл вызывать только из callback'а по приему PID (в том случае, если из значения идентификатора Slave понимает, что необходимо выслать ведущему данные).

Если мы, будучи ведущим устройством, хотим получить данные от Slave, то для этого припасена функция:

Возвращаемое значение и аргументы имеют точно такой же смысл как и для передачи. Аналогично, для Slave вызов этой функции должен происходить после приема идентификатора. Master же при вызове этой функции выдает в шину поля Break, Sync и PID и встает на прием данных:

Для Slave'а все процессы работают несколько иначе - никаких функций вызывать не нужно. Ведомый изначально переходит в состояние приема LIN-фрейма, а точнее в режим ожидания Break. И далее вся работа уже протекает по факту приема данных от Master'а. Для работы со Slave'ом я добавил два callback'а:

LIN_SlaveIdRxCallback(uint8_t id) - по приему PID - для анализа полученного значения и принятия решения о дальнейших действиях. Ведь именно из значения PID подчиненный понимает, нужно передавать данные или принимать, а также количество байт данных.
LIN_RxCpltCallback() - по окончанию приема данных. Этот callback нужен уже непосредственно для обработки принятых данных, при этом контрольную сумму проверять не нужно, это происходит внутри драйвера. И callback будет вызван только в том случае, если контрольная сумма верна.

Работа с этими функциями протекает точно также, как и с другими callback-ами. Просто переопределяем эти функции в своем коде и добавляем в них любые необходимые действия.

С этим разобрались, теперь организуем демо-проект для проверки возможностей и работоспособности драйвера. И для тестирования добавим модуль USART1, настроенный на работу в режиме LIN, как в этом примере.

В итоге на USART1 с аппаратной поддержкой LIN у нас будет Master. А на USART2 у нас будет Slave, который будет работать исключительно на голом USART'е при помощи нашего драйвера. Ну и, соответственно, соединяем эти модули USART между собой.

Первый тест - Master передает данные, а Slave принимает. Код ведущего у нас в цикле while(1) :

Для передачи данных Master'ом у нас используется PID 0x3A, а для запроса и приема данных от Slave - 0x3B.

Важное дополнение – как вы помните, байт PID помимо 6-ти битов идентификатора включает в себя еще два бита четности. Для примера же будем просто использовать вышеупомянутые значения, без учета четности.

Добавляем наш пользовательский код в callback по приему PID:

Анализируем принятый PID и решаем, принимаем или передаем. Кстати, опять же из идентификатора мы получаем количество байт для приема/передачи при помощи функции LIN_GetDataLength(id) . Кстати, заметьте, для Slave'а не важно, какое значение идентификатора мы передадим в функции приема и передачи, поскольку за выдачу в линию PID отвечает Master. Так что можем спокойно в качестве первого аргумента использовать 0.

И также переопределяем callback по окончанию передачи:

Здесь просто инкрементируем счетчик принятых фреймов. Запускаем программу и под отладчиком можем видеть, что счетчик переданных Master'ом пакетов ( linMasterTxCnt ) в точности соответствует счетчику пакетов, принятых Slave'ом:

А теперь второй тестовый режим - Master отправляет заголовок пакета и начинает прием данных от Slave'а:

Slave же про приему этого идентификатора начинает отправку своих данных. Для проверки у нас используются счетчик запросов ведущего linMasterRequestCnt и счетчик принятых, опять же ведущим, пакетов данных - linMasterRxCnt :

Все работает четко по плану 👍 Таким образом, можно просто добавить в свой проект драйвер LIN'а и использовать те функции, которые мы обсудили, для того, чтобы быстро и просто организовать работу с использованием LIN.

А теперь под занавес статьи, реализуем Master'а на нашем драйвере и поставим его на отправку данных раз в секунду. Кода минимум, раз:

Вот и все. А теперь посмотрим на сигнал на экране осциллографа:

Все в точности соответствует теоретическим аспектам работы протокола LIN, которые рассматривали ранее.

На это заканчиваем статью, подписывайтесь на обновления, вступайте в группу ВКонтакте, мы будем рады видеть вас снова )

В теме выкладываются и обсуждаются вопросы касающиеся модификации,
прошивки и установки/настройки ПО на: Lada GRANTA и Lada KALINA-2/Priora

Внимание. НЕЛЬЗЯ прошивать ММС с версией ПО 23.02.27 или 21.1.2.39 .
Перед прошивкой ММС , сверяйте версию ПО, проконсультируйтесь на форуме по этому поводу, не спешите убивать свой аппарат.
Все операции по прошивке ММС производить только на свой страх и риск! Что приводит к потери гарантийных обязательств производителя на ММС.

Вынуть все устройства из USB.
Создать в корне USB пустой файл explorer.txt. После перезагрузки должен загрузиться рабочий стол WinCE.
Отключить питание ММС (снять клемму аккумулятора) на 5 минут.
Прошить еще раз, по новой скопировав файлы на SD карту.

Процессор - SiRF Atlas -V AT551
Оперативная память - 128 Мб
Внутренняя память - 5 341 184 байта
Операционныя система: Windows CE 6.0
Аппаратный декодер аудио/видео - отсутствует
Радио приемник - TEF6616 (управление по I2C)
Контроллер CAN и K-Line - Freescale S9S12G96F0CLF
Видеовход (камера з/х) - есть, но заблокирован.
Поддерживаемые форматы фото: *.JPEG, *.JPG, *.JPE, *.BMP, *.GIF, *.PNG.
Поддерживаемые видео форматы: WMV с разрешением 240х320 px. Для конвертации Ваших видео-файлов можно использовать любой доступный конвертер.
Поддерживаемые музыкальные форматы: MP3, WMA, WAV. При наличии в аудио файле сопроводительной информации (логотип, описание) она также отображается на экране.
Поддерживаемые носители информации: SD и SDHC (до 32Гб), USB (до версии 3.0, до 64 Гб) с файловыми системами FAT16, FAT32 или exFAT.

Прошивкой (англ. Firmware, fw) называют содержимое энергонезависимой памяти компьютера или любого цифрового вычислительного устройства, в которой содержится его микропрограмма. В широком смысле прошивка – это программное обеспечение, которое является операционной системой устройства.
Альтернативное меню - установка оболочки отличной от стандартной, поверх установленной прошивки!
Пример: Прошивка - это Windows, устанавливаемая на ММС. Альтменю - это программа, которую ставят на Windows. Различие лишь в том, что: Прошивку можно прошить один раз и долго ей пользоваться, а Альтменю можно переустанавливать от случая к случаю, по необходимости. Например, для обновления новой версии или исправлении ошибок.

Выйти на рабочий стол
Вытащить все из USB
Тапнуть по ярлыку NewMenu Uninstall
Перезагрузить магнитолу (15> секундным нажатием)
Удалить все из StaticStore
Установить новую версию(меню)
Подключить все в USB (желательно первым подключить GPS антенну)

Форматируем SD карту до 4 Гб в FAT
В корень SD карты скопировать файлы для прошивки: Chain.bin, chain.lst, NK.bin, TINYNK.bin .
Вынуть все из USB магнитолы.
Перезагрузить аппарат долгим (около 15с.) нажатием на кнопку питания(Калина 2/Priora) или кнопку громкости(Гранта)
После прошивки (пробежали 4-е статус бара), аппарат сам перезагрузится в рабочий стол.
Берем стилус (зубочистку, ключ и т.п.)
Ни в коем случае не перезагружаем аппарат! Заходим в: Start/Settings/Control Panel/Stilus/ на вкладку Calibration/Recalibrate. Калибруем экран и тапаем по экрану во время обратного отсчета.
( или для новичков: Тапаем на рабочем столе по иконке Home, ждем загрузки штатного меню. заходим в настройки -> экран -> калибровка экрана, калибруем не забывая тапнуть по экрану во время обратного отсчета. Далее нажимаем пальцем иконку настройки, не убирая палец ждем пока запустится рабочий стол.)
Перезагружаем аппарат, SD карта должна быть вставлена.
Аппарат прошит , SD карту можно извлекать.

Если не включается заставка, то попробуйте ее активировать: Настройки>Hастройки newmenu>Hастройки экрана>Заставка

Удерживайте НАСТРОЙКИ в течении более 15 секунд. Если не выходит, то у вас старая версия ПО, не имеющая выход на рабочий стол. Для выхода потребуется прошивка.

[size=4][b]Штатная мультимедийная система Kalina II/Priora/Granta[/b][/size]

[color=green][size=2][b]В этой теме выкладываются и обсуждаются вопросы касающиеся модификации , прошивки и установки/настройке ПО на: [/b][/size][/color]
[attachment="3615804:Гранта.jpg"] [size=4][b][color=blue](G)[/color][/b][/size] [color=blue][size=2][b]Штатную ММС Лада Granta[/b][/size][/color] [attachment="3615806:Калина.jpg"] [size=4][b][color=orangered](K)[/color][/b][/size] [color=orangered][size=2][b]Штатную ММС Лада Kalina II/Priora[/b][/size][/color]
[color=blue][b][size=2]ЭСУД , электрика , диагностика автомобилей Kalina II/Proira/Granta обсуждаем в [url="http://4pda.to/forum/index.php?showtopic=582521"]Диагностики и электрике Гранта\Калина\Приора[/url][/size][/b][/color]

Стоковая прошивка ver.35-[attachment="3622625:Kalina_v. 3.0.2.35.rar"] [color=green]Проверенно . [/color]
Стоковая прошивка ver.32-[attachment="3617032:Kalina_v. 3.0.2.32.rar"] [color=green]Проверенно . [/color][/spoiler][spoiler=2) Модифицированные прошивки магнитолы Калина 2]
Прошивка с альтменю ver.32-[attachment="3616422:Kalina_m. 3.0.2.32.rar"][color=green]Проверенно . [/color]
[color=red]Русифицированное время и дата и корректно отображающиеся русские символы [/color] [attachment="3761322:Kalina_I. us_clock.rar"]
Постоянно обновляемые сборки от [url="http://4pda.to/forum/index.php?showtopic=510378&st=0&view=findpost&p=26085318"]TarLink[/url] и от [url="http://4pda.to/forum/index.php?showtopic=510378&st=0&view=findpost&p=26084502"]magix79[/url] ([color=red]Читать описание обязательно ![/color])[/spoiler][/spoiler][/spoiler][spoiler=[size=2][color=darkblue]Инструкции,подсказки, FAQ[/color][/size]][spoiler=1) Инструкция по прошивке стокового ПО]
1. [color=red]Форматируем SD карту до 4 Гб в FAT[/color].
2. В корень SD карты скопировать файлы для прошивки: [color=red]Chain.bin , chain.lst , NK.bin , TINYNK.bin[/color].
3. Перезагрузить аппарат долгим (около 15с.) нажатием на [color=red]кнопку питания если на КАЛИНЕ[/color] и [color=red]кнопка громкости на ГРАНТЕ[/color]
4. После прошивки (пробежали статус бары, их 4), аппарат сам перезагрузится в рабочий стол.
5. Ни в коем случае не перезагружаем аппарат(важный момент!), давим:
[color=red]Start/Settings/Control Panel/Stilus/Вкладка Calibration/Recalibrate[/color]
калибруем экран и не забываем тапнуть по экрану во время обратного отсчета.
6. Перезагружаем аппарат, SD карта должна быть вставлена.
7. Аппарат прошит , SD карту можно извлекать.[/spoiler][spoiler=2) Инструкция по прошивке ПО с альтменю]
Изменения:
1. Исправлен ранее используемый NK - убраны не нужные строки из реестра, из-за которых не верно работал блютуз и радио в штатной оболочке.
2. Добавлена удобная наэкранная клавиатура и ее вызов из некоторых программ.
3. Добавлена возможность настроить 3G модем и создать подключение прямо из меню, минуя рабочий стол и проводник.
4. Добавлен браузер Opera с автоконнектом к интернету.
5. Добавлена возможность настроить GPS ресивер.

Установка:
1. [color=red]Форматируем SD карту до 4 Гб в FAT[/color], копируем содержимое на карту.
2. Из папки "FirmWare" файлы скопировать[color=red](именно скопировать. ) в корень SD карты[/color].
3. Перезагрузить аппарат долгим (около 15с.) [color=red]нажатием на кнопку питания если КАЛИНА[/color] или [color=red]кнопку громкость если ГРАНТА[/color]
4. После прошивки (пробежали статус бары, их 4), аппарат сам перезагрузится в рабочий стол.
5. [color=red]Ни в коем случае не перезагружаем аппарат(важный момент!)[/color], давим:
[color=red]Start/Settings/Control Panel/Stilus/Вкладка Calibration/Recalibrate[/color]
калибруем экран и не забываем тапнуть по экрану во время обратного отсчета.
6. Перезагружаем аппарат, SD карта должна быть вставлена.

Шина LIN – это простая последовательная однопроводная шина для автомобильных применений и используется в тех случаях когда применение CAN шины – дорого. По шине LIN управляются различные приводы (корректоры фар, заслонки климатической системы, приводы центрального замка), а так же собирается информация с простых датчиков (датчики дождя, света, температуры).

Для изучения шины LIN Вы можете использовать наш адаптер CAN-Hacker 3.0 с дополнительной опцией LIN анализатора.
А так же интерфейс CAN-Hacker CH-P

Пример системы управления дверью с шиной LIN и без нее:

Еще пример, в автомобиле Porsche Macan 2015 г. все привода и датчики климатической системы подключены к шине LIN а сам блок климат контроля связан с автомобилем при помощи CAN шины.

Дешевизна LIN обусловлена тем что реализация протокола LIN полностью программная и строится на базе обычного UART (родственник RS232, COM порт). Так же LIN не требует применения точных времязадающих цепей – кварцевых резонаторов и генераторов. Поэтому можно применять дешевые микроконтроллеры.

Скорость передачи данных

Скорость передачи данных на шине LIN стандартная для устройств построенных на базе UART: 2400; 9600; 10400; 19200; 20000 Бод. Это немного но достаточно для передачи данных от датчиков и для управления медленными механизмами.

Электрическая реализация LIN

Электрически интерфейс LIN реализован так же просто. В каждом узле линия шины подтянута к шине питания +12V. Передача осуществляется опусканием уровня шины до уровня массы GND. Микроконтроллер подключается к шине LIN при помощи специальной микросхемы Трансивера, например TJA1021

Подключение LIN трансивера к микроконтроллеру

Архитектура сети LIN

Особенностью шины LIN является то, что в сети присутствует два вида узлов: Master и Slave, Master – ведущий, Slave – подчиненный.

Master может опрашивать Slave о его состоянии, будить его, отправлять ему команды. Обмен информации на шине LIN происходит в формате обмена пакетами, и на первый взгляд может показаться что механизм идентичен шине CAN, это не так. Объясняем почему:

Структура LIN пакета выглядит так:

Frame – Header – заголовок кадра, который отправляется в шину Мастером. Включает в себя ID кадра

Frame – Response – данные которые отправляет Slave в ответ на запрос Master -а.

Уловите разницу – в шине CAN все узлы передают и ID кадра и данные. В шине LIN – заголовок пакета это задача Мастер-узла.

Поле Frame-Header состоит из полей:

BREAK – Это сигнал шине о том что мастер сейчас будет говорить

Поле синхронизации – это просто байт = 0x55. При его передаче приемники подстраивают свою скорость.

PID – это поле защищенного идентификатора. В дальнейшем будем писать просто – идентификатор.

Идентификатор может принимать значения от 0 до 59 (0x3B в HEX) для пользовательских пакетов. Так же возможно использование специальных служебных пакетов с ID 0x3C, 0x3D, 0x3E и 0x3F. Защищенность идентификатора заключена в следующем:

В структуре байта ID мы видим биты собственно самого идентификатора с ID0 по ID5, а затем идут два контрольных бита P0 и P1, которые рассчитываются так:

P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4
P1 = ¬ (ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)

ID = 0x00 PID =0x80

ID = 0x0C PID = 0x4C

Если в PID контрольные биты рассчитаны неверно то пакет не будет обработан принимающей стороной.

В случае если мы будем эмулировать работу какого либо узла Master, предварительно изучив отправляемые им данные при помощи LIN сниффера, то нам не придется задумываться о расчете контрольных битов ID, поскольку в пакетах которые мы видим сниффером все уже посчитано до нас.

После того как Slave принял Header мастера он отвечает полем Frame Response который состоит из байтов данных в количестве от 1 до 8 и байта контрольной суммы.

Контрольная сумма (CRC) считается как инвертированная сумма всех байтов данных с переносом либо сумма всех байтов данных + значение защищенного ID . В первом случае CRC называется классической, во втором – расширенной. Вариант подсчета контрольной суммы определяется версией стандарта шины LIN. В версиях 1.xx применяется классический алгоритм, в версиях 2.xx применяется расширенный.

Обратите внимание на отсутствие поля DLC отвечающего за количество байтов данных как в CAN шине. В шине LIN количество байтов данных определяется на этапе написания ПО контроллера. Поэтому процесс обмена на шине LIN сложнее анализировать при помощи сниффера – приходится вводить специальный алгоритм разделения пакетов, который угадывает сколько байтов данных было в принятом пакете.

На этой схеме мы видим как один Мастер общается с двумя узлами Slave. Обратите внимание на третий кадр, в нем заголовок Header и тело пакета Response передает Мастер – это важный момент, такие кадры используются для диагностики и конфигурирования Slave узлов.

На осциллограмме обмен одного Master и одного Slave выглядит так:

Здесь мы видим запрос мастера состоящий из полей Break – S – затем следует ответ узла Slave состоящий из четырех байт и контрольной суммы равной 0x3F.

Если мы отключим узел Slave от шины LIN, то увидим уже такую осциллограмму:

Так же в протоколе шины LIN предусмотрены и специальные служебные пакеты служащие для диагностики шины, пробуждения устройств и других функций. В этом случае Master может передавать как Frame Header так и Frame Response последовательно, тогда пакет Master -а может иметь такой вид:

ID=0x3C DATA : FF FF FF FF FF FF FF FF

При помощи длинных пакетов Master может конфигурировать и программировать узлы Slave. Если для программирования или конфигурирования узла LIN необходимо более 8 байт, то поток данных сегментируется и пересылается частями. Механика передачи данных определяется специальным транспортным протоколом работающим поверх физики шины LIN, о нем мы напишем в следующих статьях.

Видео пример работы с шиной LIN и адаптером CAN-Hacker 3.2

LIN -шина, это однопроводная цифровая шина для управления по одному проводу группой разнообразных исполнительных устройств, широко применяемая в современных автомобилях. Например двигателями заслонок климата, корректорами фар, замками и стеклоподъемниками дверей и т.п. Конкретно у меня сейчас стоит задача заставить управлять шаговыми двигателями корректора фар. Шаговые двигатели управляются драйвером-контроллером AMIS-30621 Моя задача сделать контроллер, который бы умел контролировать и управлять шаговыми моторчиками корректора фар. А чтоб сделать контроллер, необходимо изучить сам протокол данных LIN и конкретно сам даташит драйвера.
Протокол LIN достаточно не сложный, не быстрый, но при этом надежный и в общем мне очень понравился. В даташитах все подробно описано, я лишь пробегусь вкратце. Если кратко, то цифровая посылка LIN контроллера состоит из этого:

Sync Break — передача данных всегда начинается с притягиванию к нулю шины не менее чем на 13 тактов. Увидев эту притяжку, все устройства на шине оживают, и понимают, что сейчас пойдет что то интересное и начинают ждать. А далее следует:
Sync Field — сигнал синхронизации. Все устройства на шине обязаны подстроится под этот сигнал и подстроить свои тактовые сигналы.
PID Field — служебный байт, который содержит адрес конкретного устройства на шине, последующую длину данных байт и два бита контроля ошибок
Data — передаваемые данные, до восьми байт
Checksum — контрольная сумма

Общее описание стало понятно, пора было собрать макетную плату контроллера шины.
За основу взят микроконтроллер ATTiny13 и транслятор-приемник шины LIN TJA1020 Регулятор положения сделан на обычном энкодере. Вот получилась такая схема:

Далее пошло изучение даташита контроллера шагового мотора. AMIS-30621 это контроллер последнего поколения, который включает в себя все, что можно. Он имеет ЦАП, контроль тока, контроль температуры, напряжения, режим разгона-торможения, настройку силы тока и еще кучу настраиваемых параметров. Достаточно ему подать команду, насколько нужно нашагать, остальное полностью он делает сам. Очень умный драйвер короче. Даташит немного замудреный, много неясностей было при прочтении, но в итоге удалось оживить этого монстра, читать с него данные и управлять им. Вот пример из анализатора:

А вот пример из кода:
Сначала нужно считать данные состояния, это обязательное условие из даташита:
void GetFullStatus (void)

Читайте также: