Что такое шина LIN

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

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

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

With LIN bus

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

 

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

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

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

LIN electrical

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

LIN transsiver

 

 

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

LIN Network

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

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

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

LIN frame

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

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

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

LIN Frame structure vertical

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

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

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

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

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

LIN PID jpg

В структуре байта 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 сложнее анализировать при помощи сниффера — приходится вводить специальный алгоритм разделения пакетов, который угадывает сколько байтов данных было в принятом пакете.

Data Linbus

На этой схеме мы видим как один Мастер общается с двумя узлами Slave.

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

LIN BUS MASTER SLAVE

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

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

LIN BUS MASTER

 

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

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

Обмен диагностическими сообщениями на шине LIN выглядит так :

LIN diagnostic frame JPG

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

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