Чтение lin шины ардуино

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

Шина 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 шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать

Чтение 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

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

About

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

Читайте также: Белые лебеди из шин

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

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 купить, пригодится полюбому.

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

AVR Freaks

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

LIN Bus — Arduino Mega + MCP2003 — Read Problem

Hello. I have a problem with LIN bus on Arduino Mega. In fact, it seems that it is okay when it comes to the physical aspect. MASTER and SLAVE built on MCP2003B. CS and RxD WAKE so as to be pulled etc. here is certainly good. MASTER connected to Serial1 and SLAVE to Serial2.

Sending works, for example, if I send a data frame from MASTER with the data as in the screenshot below, SLAVE receives it and displays the following on the Serial Monitor:

But when I send only the ID frame from the MASTER and the data is sent back to SLAVE, this is a problem. Ie. SLAVE sends back a data frame, but the MASTER does not read it at all. In the simplest case, I did so that SLAVE sent the same data as in case of MASTER’s broadcasting in the above example. So the frame looks the same as in the picture above.

It looks like the receiver in MASTER is inactive while SLAVE sends back the response.
I think the problem is therefore that to generate a BREAK signal needed to disable the serial port. But then, in the reading function, the data is opened again. Unless it can not be done in this way and the port is not being made? The reading function returns 0 so it does not see any data to read from the port at all. Maybe one of you knows how to set it properly? Thank you in advance for your help.

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

Hackaday

[Zapta] tipped us about his latest project: a LIN bus signal injector. For our unfamiliar readers, the LIN bus is a popular automotive bus that is used to interface with buttons, lights, etc. As [Zapta] was tired of having to press the Sport Mode button of his car each time he turned the ignition on, he thought it’d build the platform shown above to automatically simulate the button press.

The project is based around an ATMega328 and is therefore Arduino IDE compatible (recognized as an Arduino Mini Pro), making firmware customization easy. In the car, it is physically setup as a proxy between the LIN master and the slave (which explains the two 3-wires groups shown in the picture). It is interesting to note that the injection feature can be toggled by using a particular car buttons press sequence. The project is fully open source and a video of the system in action is embedded after the break.

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

12 thoughts on “ A LIN Bus Signal Injector ”

The whole reason behind that the car doesn’t remember the last state set for the “sports” mode is because of environmental concerns.

Automaker can simply sell a sporty car that defaults to economy mode, and then it will be classified as a economic car even if the owners themselves press the “sports” button right after ignition.

So it is simply good old fashioned rule bending.

In the Honda I drive I would use this device to set the ‘ECON’ mode each time the car starts. If I ever get around replacing the Japanese nav system with a tablet or similar, perhaps this unit could also be used to interface to the +13 buttons on the steering wheel. Nice work!

not just environment, it’s also more dangerous to drive … some cars lock the rear dif, stiffen the suspicion, tighten the steering, and disable safety features …. sports mode is a button for a reason … somthing you use just on the track or when someone starts matching speeds with you on an empty highway …

Читайте также: Шина типа pin 3р шаг 18мм 100а 1м ekf proxima

Awesome project. I bet this would be a huge marketable product. Think of when these cars are 10-20 years old and peoples children get a hold of them. These are the kind of hacks that will be installed in “old” cars of the future.

On old Toyotas the hack is simple. Replace the momentary “PWR” switch with a locking one and the job is done. Older models had locking switches and the ECU still recognizes this on newer ones.

OMG he had to turn the ignition AND push a button – that was dreadful.

Luckily kids today have microcontrollers to do such tedious tasks for them.

Must do this with the auto stop/start in my Subaru. Every time I hit traffic light the engine stops until I push the clutch in.

You can usually turn that off. I rented a Saab once that did that. Second day I had it I checked the manual and there was way to disable it.

Видео:Контролька на Arduino, с функциями осциллографа, поиска CAN шины, частотомера, вольтметра, прозвонкиСкачать

Драйвер протокола 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.

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

  📺 Видео

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

  

  Как управлять автомобилем через CAN-шину?Скачать

  

  Кан шина, что это? Поймет школьник! принцип работыСкачать

  

  Arduino CAN Sender ( Ардуино отправка пакетов в КАН шину)Скачать

  

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

  

  Arduino CanHacker Lowicel (дружим Ардуино с программой CanHacker)Скачать

  

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

  

  лекция 403 CAN шина- введениеСкачать

  

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

  

  Блок управления, генератор, CAN или LIN шина либо АКБ? P0401, P0523, U1113, U1132, U0106 (Видео 90)Скачать