Анализатор lin шины ардуино

Шина LIN. Сканирование “молчащих” блоков и датчиков

Как было описано в предыдущей статье, в структуре шины LIN есть Master узел и Slave узлы. Master опрашивает узлы Slave, а те ему отвечают. В большинстве случаев если просто подать питание на Slave и посмотреть что происходит на его выходе шины LIN, то мы ничего не увидим, поскольку Slave ожидает запрос или пакет от Master узла.

Master узлом как правило является какой-либо блок управления: Блок управления двигателем, салоном, креслами и т. д. А Slave узлы это различные цифровые датчики, приводы, блоки кнопок управления или джойстики.

Что же делать если стоит задача “оживить” Slave в отрыве от мастера? Например во время проведения ремонта с целью выяснить исправность Slave узла и вообще шины LIN.

Для решения этой задачи удобно использовать LIN адаптер LIN-K совместно с USB-CAN интерфейсом CAN-Hacker. Программное обеспечение нашего анализатора шины LIN позволяет автоматически искать запросы для Slave узлов сети LIN.

Анализатор lin шины ардуино

Блок управления стеклоподъемниками автомобиля LADA. Slave узел на шине LIN

В качестве примера рассмотрим работу с блоком управления стеклоподъемниками от автомобиля LADA Granta.

Блок управления стеклоподъемнками является Slave узлом в LIN шине автомобиля LADA, а Master узлом является блок управления комфортом, который отправляет запросы на Slave узлы, а те в свою очередь отвечают ему о своем состоянии. В частности блок управления стеклоподъемниками отвечает статусом нажатия кнопок.

Анализатор lin шины ардуино

Блок комфорта автомобиля LADA. Master на шине LIN

Если соединить эти блоки в сеть и параллельно подключить LIN анализатор LIN-K на скорости 9600 бод и будем нажимать кнопки на блоке стеклоподъемников, то мы увидим следующий обмен с пакетами имеющими >

Анализатор lin шины ардуино

Анализатор lin шины ардуино

Пакеты с данными: 00 00 00 C0 – говорят о том, что кнопки не нажаты, если же нули меняются на другие числа, например 20 02 00 С0 говорят о нажатии кнопок.

Теперь представим, что мастер узла в лице блока комфорта у нас нет, а запустить Slave – блок стеклоподъемников нужно. Для этого подадим питание на исследуемый блок и LIN адаптер и подключимся к выводу LIN.

Анализатор lin шины ардуино

Выберем в программе LIN-K виртуальный COM порт к которому подключен наш LIN адаптер, нажмем Connect. Затем установим скорость LIN 9600 бод и нажмем Open LIN.

Анализатор lin шины ардуино

В окне принятых сообщений ничего нет. Это следствие того, что Slave ждет запроса от Master -а.

Настроим LIN-K на передачу запросов в заданном диапазоне – функция Bombing

Анализатор lin шины ардуино

В такой конфигурации LIN-K будет передавать запросы узлу Slave в диапазоне всех возможных ID на шине LIN от 0 до 0x3C. С каждым ID будет передаваться по 10 запросов.

В случае если Slave прореагирует на отправленный запрос мы увидим этот факт в окне приема:

Анализатор lin шины ардуино

Как видно из скриншота Slave прореагировал на посылаемый ему запрос с >

Следует обратить внимание на то, что в передаваемых LIN анализатором ID автоматически рассчитываются биты защиты и значение ID отличается от значения в счетчике, например по счетчику а передаваемое значение с битами защиты будет равно =0x42

Далее мы можем убрать флаг Bombing и установить значение ID для Master запроса = 03 и мы будем получать ответы от “ожившего” блока кнопок

Arduino.ru

LIN «шпион» Mitsubishi Lanser 10

Всем првет, прошу подсказку. Есть подрулевой переключатель в авто (поворотники свет, дворники . ), сигнал с ручки выходит по LIN шине, мне нужно этот сигнал считать и идентифицировать по средствам Arduino.

Вот что удалось раздобыть и разобрать.

С ардуино знаком но с обработкой сигнала с байтами и битами у меня пробелы бооольшие =) кто нибудь может помочь ?

Первая и вторая осциллограмма включен — режим Авто -> габаритный свет

Анализатор lin шины ардуино

т.к. физически LIN это K-line

собирай k-Line ардуино сниффер или просто K-Line Terminal на компе сниффер. Осликом это жесть байты смотреть.

k-Line ардуино сниффер выглядит так и скетч к нему:

Анализатор lin шины ардуино

В строке 07 меняешь скорость, пока не увидешь в мониторе порта байт 0х55, если чё, в строке 13 играешься задержкой, для лучшей компановки кадров.

K-Line Terminal на компе сниффер выглядит так:

Анализатор lin шины ардуино

ну собственно это самый обычный USB K-line адаптер, можно купить недорого готовый в магазинах. Его подключаем к этому терминалу . И пробуем менять скорость, пока не увидим начало кадра 0x55.

Анализатор lin шины ардуино

1. Сначало : MC33290 -> USB UART -> Terminal2, находим нужную скорость .

2. Потом : MC33290 -> Arduino , подключаемся уже с известной скоростью .

Анализатор lin шины ардуино

1. Сначало : MC33290 -> USB UART -> Terminal2, находим нужную скорость .

2. Потом : MC33290 -> Arduino , подключаемся уже с известной скоростью .

1. Можно после нахождения нужной скорости и дальше терминалом расшифровывать данные , а ардуино использовать уже когда протокол будет хакнут.

2. Ну если вы найдёте MC33290. Гораздо проще найти тоже специализированную микросхему L9637D.

схема будет похожая, в любом случае к-лайн нужно вешать на софтсериал соединение, чтобы хард сериал оставался для вывода на сериал монитор компа. Схема примерно такая.

Анализатор lin шины ардуино

Но я бы сделал на дешевой LM393 — стоит 10 рублей и есть в любом магазине, или вообще готовый к-лайн адаптер типа VAG COM KKL 409 купить, пригодится полюбому.

Анализатор lin шины ардуино

An Arduino based LINBUS stack that allow to explore and hack linbus based system.

Unless specified otherwise, the PCBs can be used with standard Aruduino IDE, behaving as Arduino Pro Mini 5V 16Mhz with ATMEGA328.

**Analyzer** — a small PCB that connects on one hand to linbus and to a computer USB port on the other. The analyzer decode all the linbus frames and dump them to the computer. The USB connection emulates a serial port using a builtin FTDI adapter and can be read with standard serial application. A special python script is provided in the tools directory to dump the serial data in diff mode such that only changed bits are displayed. The board design support also linbus TX which allow to have this board functioning as a linbus master or slave (this however requires firmware changes).

Анализатор lin шины ардуино

**Beeper** — a small PCB and firmware that monitors a linbus and activates a buzzer when certain conditions met. The provided firmware includes a car specific example that beeps when the reverse gear in my car is engaged. The car specific logic is in the car_module* files and can be adapted to different applications.

Анализатор lin шины ардуино

**Injector** — a small PCB board with two linbus interfaces that connects in series between a linbus master and a linbus slave. The injector looks as a slave to the master and as a master to slave and it transparantly proxying LIN frame between the. At the same time, it can monitor bus signals, apply application spefici logic and can inject signals back to the bus by modifying on the fly LIN frames it proxys between the master and the slave. The Injector was developed to modiy the behavior of existing LIN bus based system (e.g. automatic activation of the Sport mode in my car).

Анализатор lin шины ардуино

**Feature Comparison**

FeatureAnalyzerBeeperInjector
Max LIN speed20kps20kps20kps
Min LIN speed1kps1kps1kps
Operating voltage12V12V12V
Max voltage40V40V40V
LIN frame dump/logYesYesYes
LIN checksumsV1/V2V1/V2V1/V2
Computer serial interfaceFTDI/USBSerial 5VSerial 5V
Computer serial speed115,200115,200115,200
Audible outputNoYesNo
LIN signal interceptionYesYesYes
LIN signal injectionNoNoYes
Arduino IDE compatibleYesYesYes
Programming languageC/C++C/C++C/C++
MCUATMEGA328PATMEGA328PATMEGA328P
MCU speed16Mhz16Mhz16Mhz
Schematic/Layout softwareCadsoft EagleCadsoft EagleCadsoft Eagle
PCB Size (inches)1.3 x 1.51.15 x 1.61.31 x 1.44
PCB layers222
Component mountingSMDSMDSMD
Min component size080508050805
OSHPark compatibleYesYesYes

About

An Arduino based LINBUS stack and signal interceptor/injector.

Анализатор lin шины ардуино

Library and examples for LIN (Local Interconnect Network) on Arduino. Developed for the Macchina M2. Can be modified for any Arduino board with UART available and any LIN slave.

Several example sketches are included in the LIN Library to demonstrate typical usage:

Lin2Lin M2 acts as the Sniffer – when traffic on one LIN channel is detected, incoming data is saved and then sent to another LIN channel with no modification. Arduino Due with simple 1-bit ADC is used as Master Node on first LIN bus and Ambient Light Module is used as a slave on another LIN bus.

Master works with Microchip’s Ambient Light Module. User builds an array of bytes, which is the length of the message and contains packages to be send to the module. Package is built out of Control Byte (control intensity, dim and ramp functions for the RGB LED), Red, Green and Blue Color Bytes and Zone Byte. Checksum calculation is supported in v2.0 library. There is no need to calculate checksum and include in it package.

Slave M2 acts like sniffer: when traffic is detected on LIN bus, incoming data is saved and processed. Arduino Due with simple 1-bit ADC is used as master. Master Node needs to be programmed with Master example Slave_Master

Data processing: If Identification Byte is correct, Checksum Byte is compared with Checksum calculated from received data. If Checksum Byte is correct, data is printed on Serial Monitor via SerialUSB. Otherwise error is printed on Serial Monitor and data cleared.

  • Sniffer M2 monitors traffic on LIN bus periodically. When traffic is detected, Sniffer reads incoming data and prints it on Serial Monitor via SerialUSB.

LIN Stack was developed using the following:

Microchip’s Interior Ambient Lighting Module with LIN Interface User Guide http://ww1.microchip.com/downloads/en/DeviceDoc/51714a.pdf

More information about LIN can be found in those documents.

  • correct checksum calculation, removed +1
  • inserted parity calculation in writeRequest method
  • implemented parity calculation
  • implemented bus wake up for proper lin bus waking up
  • Changed default baudrate to 19200 which is more common in automotive applications

About

Arduino library to add dual LIN support on SAM3X based boards with a TJA1021/TJA1027 transceiver

Драйвер протокола LIN для микроконтроллеров на базе UART.

Анализатор lin шины ардуино

Анализатор lin шины ардуино

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

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

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

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

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

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

Анализатор lin шины ардуино

Анализатор lin шины ардуино

Таймер у меня будет генерировать прерывание по переполнению каждые 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’а в линию будут отправлены последовательно:

Анализатор lin шины ардуино

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

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

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

Анализатор lin шины ардуино

Для 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’ом:

Анализатор lin шины ардуино

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

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

Анализатор lin шины ардуино

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

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

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

Анализатор lin шины ардуино

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

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

Проект можно скачать по ссылке — MT_LIN_SW_Example.

Источник