Анализатор 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Видео:Анализатор шины LIN. Обзор обновленной версии. LIN bus analyzer reviewСкачать

Arduino.ru

Видео:Lin-scan (Анализатор ЛИН шины)Скачать

LIN «шпион» Mitsubishi Lanser 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: Всесезонная шина dunlop grandtrek at20

Видео:Как работает LIN шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать

Анализатор 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).

**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.

**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).

Видео:CanHacker из 2CAN модуля своими руками КанХакер подробно в деталяхСкачать

About

An Arduino based LINBUS stack and signal interceptor/injector.

Видео:LIN шина - пример работы. LIN bus exampleСкачать

Анализатор 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

Видео:MCP2515, контроллер CAN шины с интерфейсом SPIСкачать

About

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

Видео:Оживление по шине LIN блока кнопок стеклоподъемников от Mercedes Benz W220Скачать

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

Встречайте третью часть из серии статей, посвященных протоколу 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.

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

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

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  
  

  источники:

  https://fasad-adelante.ru/analizator-lin-shiny-arduino

  🌟 Видео

  Логический LIN пробник, цифровой тестер лин, к лайн шины автомобиля. На Ардуино, OLED I2C, TJA 1020Скачать

  

  Управление корректором фар по шине LINСкачать

  

  CAN шина👏 Как это работаетСкачать

  

  LIN-BUS Анализатор бомбер ResponseСкачать

  

  Как CanHacker , но дешевле от CDEBYTEСкачать

  

  Arduino CAN Monitor (простейший монитор шины CAN)Скачать

  

  Универсальная плата CAN шиныСкачать

  

  Вебинар: Как найти любые данные из CAN-шины любого автомобиля?Скачать

  

  LINCAN Анализатор CAN и LINСкачать

  

  Запуск привода стеклоподъемника по шине LIN. Control a window lift via LIN bus and CAN busСкачать

  

  Тестер Kline LIN | проверка микросхем | однокнопочное решение для мастеровСкачать

  

  Экспресс диагностика CAN шины на автомобиле. №21Скачать

  

  Супер контролька я в восторге!!!Скачать