Canhacker своими руками из 2can starline

Добавил пользователь Morpheus
Обновлено: 19.09.2024



и решил на её основе, использовать уже готовый имеющийся модуль 2CAN (описанный мной в предыдущей статье) совместно с написанной и довольно распространенной уже программой CANHacker. Удивительным образом, в статье автора, и имеющимся у меня модулем 2CAN совпадают по назначению все выводы микроконтроллера, разница только в частоте кварцевого генератора. Получается, вносить изменения в плату модуля мне не придётся. Установил программный продукт STM32Cube MX с необходимыми компонентами, и немного изменил настройки и код в проекте, любезно предоставленные автором статьи:


1. Меняем параметры системы тактирования:


2. Добавляем дополнительный вывод для контроля системы тактирования RCC_MCO -> PA8:


3. Далее генерируем код и затем автоматически запускаем компиляцию в KEIL, при этом возникает ошибка компиляции, имеющийся у меня KEIL не понимает две строчки на ассемблере, но так как мы не собираемся спать во время работы, закоментируем их:


5. Припаиваем к модулю 2CAN выводы для подключения к шине CAN, и выводы для программирования по SWD, питание же платы осуществляется через разъем USB:


6. Припаиваем резистор ( 560 Ом, но не критично ) для правильной работы USB:


7. Программируем:


Соответствие выводов платы и модуля такое:


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


9. Запускаем программу, настраиваем на заданный COM порт, и подключаемся к работающей CAN шине какого либо устройства (драйвера от STM были уже установлены), результат есть:


Подключаться к шине автомобиля решил с помощью имеющегося диагностического адаптера ELM327 (удобный корпус, легко устанавливать и вынимать), просто припаяв провода к его разъему от 2CAN модуля:


И видим такие данные:


Некоторые данные нуждаются в простой обработке, где-то поделить, где-то рассчитать по формуле. Но все просто и без заморочек.
Или к примеру, Outlander III, подключаемся к CAN шине салона автомобиля, за приборным щитком.

Смотрим данные на экране компьютера, и что меняется при нажатии на кнопку открыть и закрыть автомобиль. И пары нажатий на соответствующие кнопки, хватает узнать какие команды надо подать, чтобы открыть или закрыть автомобиль. Эти коды кратковременно появляются в строчке, обведенные красным овалом. Повторяем эти команды в окне для передачи и:


Открыть автомобиль:


Закрыть автомобиль:

Что было добавлено в исходный код (в файле usb_cdc_if.c), выбор скорости:


и несколько подобных процедур для задания скорости (в файле main.c, для примера укажу пару):

Про контрольные светодиоды думаю вопрос не актуальный.

Как то так, суеты на пол дня :). Конечно есть некоторые шероховатости в работе программы, но это уже не ко мне (я надеюсь). Если есть вопросы, советы, и если кому надо помочь запрограммировать такой модуль — спрашивайте тут. Извиняюсь за огромные фотки :)

Надеюсь, что никого не обидел написанием этой статьи…

С уважением, Астанин Сергей. ICQ 164487932.

(к сожалению, ветка форума с первоначального сайта с познавательной перепиской вся пропала, что смог восстанавливаю, ссылки на проект если кому надо добавлю)

P.S. Немного еще исправил код в проекте, можно менять скорость обмена, и обмениваться используя стандартные заголовки. Разобрался с программой CANHacker, можно улучшать и модернизировать проект по необходимости, все просто.

Связь вполне устойчивая с другими блоками автомобиля, можно использовать (проверено на Volvo, Renault и Mitsubishi).


В этой статье я расскажу как собрать свою уникальную виртуальную или цифровую панель приборов и получить данные с любых датчиков в автомобилях группы VAG (Volkswagen, Audi, Seat, Skoda).

Мною был собран новый CAN сниффер и CAN шилд для Raspberry Pi на базе модуля MCP2515 TJA1050 Niren, полученные с их помощью данные я применил в разработке цифровой панели приборов с использованием 7″ дисплея для Raspberry Pi. Помимо простого отображения информации цифровая панель реагирует на кнопки подрулевого переключателя и другие события в машине.

В качестве фреймворка для рисования приборов отлично подошел Kivy для Python. Работает без Иксов и для вывода графики использует GL.

  1. CAN сниффер из Arduino Uno
  2. Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)
  3. Разработка панели приборов на основе Raspberry Pi и 7″ дисплея
  4. Софт панели приборов на Python и Kivy (UI framework)
  5. Видео работы цифровой панели приборов на базе Raspberry Pi

CAN сниффер из Arduino Uno

Чтобы послушать, что отправляет VCDS в CAN шину я собрал сниффер на макетке из Arduino и модуля MCP2515 TJA1050 Niren.

Схема подключения следующая:

CanHackerV2 позволяет смотреть пролетающий трафик, записывать и проигрывать команды с заданным интервалом, что очень сильно помогает в анализе данных.


Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)

Программно-аппаратный сканер VCDS предназначен для диагностики электронных систем управления, устанавливаемых на автомобилях группы VAG. Доступ ко всем системам: двигатель, ACP, АБС, климат-контроль, кузовая электроника и т.п., считывание и стирание кодов неисправностей, вывод текущих параметров, активация, базовые установки, адаптация, кодирование и т.п.


Подключив сниффер к линиям CAN_L и CAN_H в диагностическом шнурке я смог увидеть какие запросы делает VCDS и что отвечает авто.



Особенность авто группы VAG в том, что OBD2 разъем подключен к CAN шине через шлюз и шлюз не пропускает весь гуляющий по сети трафик, т.е. подключившись в OBD2 разъем сниффером вы ничего не увидите. Чтобы получить данные в OBD2 разъёме нужно отправлять шлюзу специальные запросы. Эти запросы и ответы видно при прослушивании трафика от VCDS. Например вот так можно получить пробег.

В VCDS можно получить информацию почти с любого датчика в машине. Меня в первую очередь интересовала информация, которой вообще нет на моей приборке, это:

  • температура масла
  • какая именно дверь открыта

Разработка панели приборов на основе Raspberry Pi и 7″ дисплея

В качестве аппаратной части я выбрал Raspberry Pi. Была идея использовать Android планшет, но показалось, что на Raspberry Pi будет проще и быстрее. В итоге докупил официальный 7″ дисплей, и сделал CAN шилд из модуля TJA1050 Niren.


OBD2 штекер использовал от старого ELM327 адаптера.


Используются контакты: CAN_L, CAN_H, +12, GND.


Тесты в машине прошли успешно и теперь нужно было все собрать. Плату дисплея, Raspberry Pi и блок питания разместил на куске черного пластика, очень удачно подобрал пластмассовые втулки, с ними ничего не болтается и надежно закреплено.


Местом установки выбрал бардачок на торпедо, которым я не пользуюсь. По примеркам в него как раз помещается весь бутерброд.


Напильником довел лист черного пластика до размера крышки бардачка, к нему прикрепил бутерброд и дисплей. Для прототипа сойдет, а 3D модель с крышкой для дисплея и всеми нужными крепежами уже в разработке.


Софт панели приборов на Python и Kivy (UI framework)

Параллельно со сборкой самой панели приборов я вел разработку приложения для отображения информации с датчиков. В самом начале я не планировал какой либо дизайн.



Первая версия панели приборов

По мере разработки решил визуализировать данные более наглядно. Хотел гоночный дизайн, а получилось, что-то в стиле 80-х.



Вторая версия панели приборов

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



Третья версия панели приборов

Ранее, я никогда не разрабатывал графические приложения под Linux поэтому не знал с чего начать. Вариант на вебе простой в разработке, но слишком много лишних компонентов: иксы, браузер, nodejs, хотелось быстрой загрузки. Попробовав Qt PySide2 я понял, что это займет у меня много времени, т.к. мало опыта. Остановился на Kivy — графический фреймворк для Python, простой в понимании с полной библиотекой графических элементов и дающий возможность быстро создать мобильный интерфейс.

Kivy позволяет запускать приложение без Иксов, прямо из консоли, в качестве рендера используется OpenGL. Благодаря этому полная загрузка системы может происходить за 10 секунд.

Алгоритм работы следующий, используется 3 потока:

  1. В главном потоке работаем с графическими элементы (спидометр, тахометр, часы, температуры и др) на экране
  2. Во втором потоке каждые 5 мс делаем опрос следующего датчика
  3. В третьем потоке слушаем CAN шину, получив ответ парсим его и обновляем соответствующий графический элемент

Проект цифровой панель приборов открытый. Рад буду предложениям и комментариям!


Непосредственно сама CAN шина используется уже много где, мне интересно её использование в автомобиле, хотя этой сферой можно и не ограничиваться. Тем более пару лет назад подвернулась такая возможность. Я посмотрел на общие спецификации — вроде бы ничего особо сложного нет. Посмотрел на программы, которые встречаются в интернете — и ни одна мне не приглянулась, у каждой не хватало чего-то такого, что казалось мне нужным на тот момент. Буду изобретать свой велосипед. Делаю свой CAN sniffer далее под катом.

CAN шина

Описывать технические подробности CAN шины в деталях — удел документации. В данной статье достаточно знать, что она:

  • имеет двухпроводное физическое подключение
  • бывают различные скорости передачи данных
  • для подключения уже имеются готовые микросхемы и даже готовые платы с распаянными деталями

Подключаюсь в диагностический разъём OBD (контакты 6 и 14) и смотрю осциллографом, что там имеется. После поворота ключа зажигания начинают бегать пакеты с амплитудой до 2,5 В. Ставлю паузу на осциллографе и смотрю на пакет.


Заметны стартовые и стоповые биты, какие-то данные в пакете. На тот момент я уже знал, что скорость передачи данных ожидается 500 кбит/с, как наиболее частая для моторной CAN шины. Длительность пакета получается около 230 мкс и перед пакетом наблюдается довольно большая пауза в передаче данных. Масштабирую время и вижу три пакета и паузы между ними.


Если сложить длительность передачи данных и паузу между пакетам получается, что передача одной порции данных занимает около 1 мс.

К чему я это всё вывожу? А вопрос чисто практический: хватит ли скорости последовательного порта для передачи всех данных? И исходя из увиденного, можно сделать вывод, что скорость 500 кбит/с развивается внутри пакета, который занимает примерно четверть времени на передачу. Значит средняя скорость передачи будет вчетверо меньшей. На тот момент я ещё не располагал тестами скорости последовательного интерфейса Arduino и забегая вперёд скажу, что даже с самым распространённым преобразователем Serial to USB CH340 стабильно работает скорость в 2 Мбит/с.

CAN scanner на Arduino

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


Именно с ним я и начал все эксперименты. Собрал простую схему с этим шилдом и жидкокристаллическим двухстрочным экраном. Цель была — вывести на экран хоть какие-то данные. Перебирал различные библиотеки для работы с CAN шиной на Arduino (сразу скажу, что правильная и рабочая библиотека называется CAN-BUS Shield by Seeed Studio с заголовочным файлом mcp_can.h), поменял кварцевый резонатор на шилде на 16 МГц (изначально стоял 8 МГц) — данных не было.

На шилде установлены две микросхемы: контроллер CAN шины MCP2515 и драйвер CAN шины TJA1050. Почитав документацию и различные форумы, решил поменять TJA1050 на более каноничный драйвер MCP2551 и данные появились. Возможно TJA1050 была изначально неисправна, так как с её подключением двумя проводками ошибиться было очень сложно, к тому же я использовал OBD и DB9 разъёмы для подключения.

За пару часов был написан простой CAN scanner, который выводил на жидкокристаллический дисплей номер захваченного пакета, его ID и до 8 байтов данных этого пакета.


Вот тут и пригодились кнопочки на шилде, которыми я реализовал переключение между номером отображаемого пакета.

Вообще, эти кнопочки потом много для чего пригодились. Именно с ними я начинал тестирование управления некоторыми устройствами автомобиля.

Начало было положено, надо переходить к более интересной реализации.

CAN sniffer на Arduino

Задача стояла достаточно простая:

  • принимаем пакет из CAN шины
  • укладываем полученные данные в свою структуру
  • отправляем структуру через последовательный порт

Для того, чтобы отправляемые данные корректно обрабатывались на стороне компьютера, перед каждой очередной порцией данных в поток вставляется префикс из четырёх байтов 0xAA55AA55 (почему-то вспомнились эти байты по последним двум байтам загрузочного сектора DOS, только они там были в другом порядке). Логика такая:

  • компьютер читает весь поток из последовательного порта и находит в нём искомую последовательность префикса 0xAA55AA55
  • сразу после префикса будут 4 байта идентификатора пакета
  • далее длина данных этого пакета, по ней контролируется длина всего пакета
  • до 8 байтов данных

Так же я написал простой генератор пакетов данных для отладки, чтобы отлаживаться дома — он просто отправляет в последовательный порт пакеты со случайными данными, что позволяет отлаживать приложение на компьютере в комфортных условиях.

Примерно в это же время прибыли более миниатюрные компоненты Arduino Nano и Mini CAN shield.


Я спроектировал небольшой корпус, распечатал его и разместил внутри все компоненты.



Снаружи с одной стороны OBD разъём, с другой — Mini USB. Внутри имеется переключатель для терминирующего резистора.

CAN sniffer на PC с использованием wxWidgets

Ранее я в нескольких проектах использовал библиотеку wxWidgets и о ней у меня только приятные впечатления. Она легковесная, нет необходимости тащить с собой различные библиотеки и даже кросс-платформенная, что вселяет надежду, что интерфейсную часть кода можно перенести без значительных переделок на другие платформы. В конце статьи будет ссылка на скомпилированную программу, если возиться со всем этим не будет желания.

Можно скачать и посмотреть видео (менее восьми минут), а можно выполнить 6 шагов по описанию ниже.

Установка и компиляция wxWidgets:

2. Создать переменную окружения WXWIN указывающую на папку, куда установили или распаковали (например C:\wxWidgets):

Свойства системы -> Дополнительные параметры системы -> Переменные среды -> Создать
WXWIN = C:\wxWidgets

3. Из папки C:\wxWidgets\build\msw открыть файл решения под соответствующую Visual Studio (wx_vc16.sln для Visual Studio 2019)

4. В Solution Expolorer, с помощью клавиши Shift, выделить все проекты, кроме _custom_build и зайти в Properties проектов.

5. В разделе C/C++ -> Code Generation изменить параметр Runtime Library:

Для конфигурации Debug выбрать /MTd
Для конфигурации Release выбрать /MT

6. Скомпилировать библиотеки wxWidgets по очереди для Debug и Release конфигураций.

Пробное приложение и настройка проекта в Visual Studio (для проверки)

1. В Visual Studio создать Empty Project с указанием типа приложения Desktop Application (.exe)

2. В окне View -> Property Manager для своего проекта правой кнопкой выбрать меню Add existing property sheet… и выбрать файл:

3. Создать файл main.cpp и скопировать в него содержимое файла:

4. В настройках проекта C/C++ -> Code Generation изменить (если пункт не появился — сделать пробную сборку):

Runtime Library для конфигурации Debug: /MTd
Runtime Library для конфигурации Release: /MT

5. Дополнительно, если необходимы привилегии UAC, в разделе Linker -> Manifest File:

UAC Execution Level: requireAdministrator

6. Для добавления иконки exe-файлу надо добавить ресурсный файл со следующим содержимым:

Первый реализованный прототип на C++ и wxWidgets показал, что даже нетбук справляется с отображением данных в таблице и я приступил к разработке задуманного.

Архитектурно программа состоит из двух потоков: интерфейсный и поток работы с последовательным портом. Никаких невероятно интересных алгоритмов не применялось. Код обильно снабжён комментариями и должен быть довольно понятен. Ссылка на исходники будет в конце статьи.

Первое что было сделано — раскраска ячеек данных в таблице по давности получения этих данных. Уже в первом прототипе, глядя на 17 строк данных меняющихся непрерывно значений, я понял, что надо как-то различать свежие данные и данные, которые не изменяются или меняется редко. Сделал раскраску в два этапа:

  • впервые пришедшие данные выделяются зелёным цветом фона ячеек
  • данные пришедшие повторно и далее — выделяются красным фоном, который постепенно выцветает до белого если больше эти данные не меняются

Далее мне захотелось всё-таки проверить, справляется ли последовательный порт с потоком данных. Для этого я на стороне Arduino добавил счётчики количества принятых пакетов и счетчик байтов в пакете. Эти счётчики отправляются на компьютер в пакете с идентификатором 0x000. Программа при получении этих данных не выводит их в таблицу, а отображает в отдельных информационных полях сверху. Полученные результаты даже весьма понравились. В среднем принимается до 750 пакетов/с со скоростью до 9,5 кБ/с, а это где в районе до 80 кбит/с, что вполне по силам последовательному порту. Но всё равно, обмен данными настроен по умолчанию на 500 кбит/с, пусть лучше будет запас.

Продолжая изучать что же передаётся в этих пакетах пришёл к ещё одной идее: при клике на ячейку в таблице, в окне программы справа выводить двоичное и десятичное значение этого байта, а так же брать следующий байт и дополнять до слова. Далее это слово умножать на некий коэффициент и получить десятичный результат. Звучит не очень понятно, но вот в связи с чем это делалось: обороты мотора приходят в пакете CAN ID 0x180, в первых двух байтах. Эти два байта дают некое слово, которое пропорционально оборотам. Если значение этого слова разделить на 8, то получатся текущие обороты. Поэтому указывается множитель 0,125, как обратная величина от 8. Далее это слово визуализируется в графике с динамической подстройкой по амплитуде. В принципе, множитель можно искать в обратной последовательности: нашёл ячейки, которые по графику очень похожи на обороты мотора или ещё что-то искомое, после чего подгоняется множитель для получения действительных значений.


Ну а двоичное представление позволяет искать различные битовые индикаторы. Например поиск индикаторов указателей поворота сводится к тому, чтобы включить их и наблюдать какая ячейка начинает изменяться, в примере ниже это CAN ID 0x481 байт 2. После чего клик по ячейке приводит к отображению её двоичного значения в соответствующем поле, где уже видны переключающиеся младшие два бита (левый, правый и если вместе — аварийная сигнализация).


И напоследок мне понадобилось сделать отправку некоторых управляющих данных в CAN шину и посмотреть реакцию на эти команды. В программу на Arduino был добавлен код, который принимает данные со стороны компьютера и передаёт в CAN шину. Именно на этом этапе пришлось отказаться от CyberLib, так как у неё не было поддержки прерывания поступления данных в буфер последовательного порта. В программе на компьютере добавил несколько текстовых полей, в которые можно ввести различные параметры и таблицу для просмотра ответа исполнительного устройства. В примере ниже показаны команды управления включить/отключить первую скорость вентилятора охлаждения (0x0A) и включить/отключить муфту кондиционера (0x0B).

Практически нигде не найти полные расшифровки данных производителей, тем более официальных. В лучшем случае это будут чьи-то изыскания в рамках реализации какой-то дополнительной функции. CAN sniffer может помочь в поиске этих данных. Я смог найти порядка 40 различных параметров автомобиля и ради эксперимента, на базе полученных данных, я сделал собственное управление вентилятором охлаждения.


После установки драйвера и подключения интерфейса к компьютеру в диспетчере устройств в разделе Порты должно появиться устройство “STM Virtual Com Port”. Порту будет присвоен номер, например COM3, как на скриншоте ниже. Номер порта будет необходимо ввести в программе CARBUS Analyzer при подключении к интерфейсу, поэтому запомните этот номер.

Возможные проблемы при установки драйвера и методы их решения

Проблемы при установке драйвера могут возникать на старых версиях Windows XP и Windows 7. При этом в диспетчере интерфейс определяется как виртуальный COM порт, но при попытке соединиться с ним, программное обеспечение зависает, либо выдает ошибку. В этом случае обратите внимание на, что на нашем сайте доступны для загрузки два варианта драйверов, и необходимо попробовать установить версию драйвера отличную от той, которая была установлена в первую очередь. Как правило это помогает решить проблему.
Вторая проблема может заключаться в низкой скорости работы интерфейса. В этом случае принимаемые пакеты отображаются с явной задержкой. Это может является следствием того, что на компьютере устаревший контроллер USB. Решить проблему поможет использование внешнего USB хаба (разветвителя), который согласует размер пакетов интерфейса и USB контроллера материнской платы компьютера.



Для работы с интерфейсом CAN-Hacker CH-P в качестве анализатора шин CAN и LIN необходимо скачать программное обеспечение CARBUS Analyzer на странице СКАЧАТЬ.
Затем распаковать скачанный архив.
В архиве находится как сама программа CARBUS Analyzer, так и утилита для обновления прошивок UBT (папка UBT) и папка с набором актуальных прошивок (UBT\Firmware files)

Настройка программы CARBUS Analyzer и интерфейса для работы с шиной CAN

Если Вы новичок в работе с шиной CAN, обязательно прочтите материал по ссылке.


Перед началом работы необходимо настроить интерфейс в меню Settings


В выпадающем списке Device type выбираем CH-P

В выпадающем списке Device mode необходимо выбрать режим работы интерфейса. Доступные режимы:

  1. CAN Dual channel + LIN – режим одновременной работы с шинами CAN и LIN.
  2. CAN Dual channel – режим анализатора CAN.
  3. LIN – режим работы анализатора только с шиной LIN


В выпадающем списке Source необходимо выбрать порт, на котором определяется интерфейс в системе .

Настройка каналов CAN

Настройка каналов CAN осуществляется на вкладках Channel 1: CAN и Channel 2: CAN. Эти вкладки становятся видимой после выбора режима интерфейса для работы с шиной CAN.
Channel baudrate – задает скорость работы CAN шины.

Флаг Listen only mode – переводит интерфейс в режим Listen only, в котором теряется возможность отправки пакетов, но при приеме передаваемых по шине пакетов интерфейс не выставляет на шине флаг подтверждение приема ACK, что делает интерфейс невидимым для других устройств на шине.


Флаг Connect terminator 120 Ohm подключает внутренние терминаторы между линиями CAN-High и CAN-Low на каждом из каналов.

Подключение к CAN шине


Подключение к CAN шине осуществляется при помощи поставляемого с интерфейсом кабеля

Назначение проводов:
Желтый с черной полосой – CAN-Low канал 1
Желтый с белой полосой– CAN-High канал 1
Оранжевый с черной полосой – CAN-Low канал 2
Оранжевый с белой полосой – CAN-High канал 2

Для работы с вариантом шины Fault tolerant CAN ознакомьтесь с материалом по ссылке.

При подключении к однопроводным шинам CAN (SWCAN – Single wire CAN, GMLAN) необходимо провод CAN-Low подключить на массу (GND) исследуемого автомобиля или блока управления, а провод CAN-High на линию SWCAN\GMLAN.

Если настройки CAN произведены верно, физическое подключение к шине верно и на шине присутствует обмен данными то после нажатия кнопки Connect в окне приема отобразятся данные передаваемые по шине CAN.


Подробное описание работы с программой CARBUS Analyzer в качестве анализатора CAN шины Вы найдете на отдельной странице – ссылка.

Работа с шиной LIN

Для работы с шиной LIN необходимо перевести интерфейс CAN-Hacker CH-P в режим работы анализатора шины LIN. Для этого необходимо:

  • Зайти в меню Settings
  • В выпадающем списке Device type выбрать CH-P
  • В выпадающем списке Device mode выбрать CAN Dual channel+LIN или LIN
  • В выпадающем списке Source выбрать порт на котором в системе определился интерфейс.


После выбора типа и режима интерфейса необходимо:


  • Перейти на вкладку Channel 1: LIN. Которая активируется после выбора режима LIN на предыдущей вкладке Device.
  • В выпадающем списке Channel baudrate выбрать скорость обмена на шине LIN
  • В выпадающем списке Detection time выбрать минимальную предполагаемую паузу между пакетами. Рекомендуется оставить значение по умолчанию –2 миллисекунды.
  • Выбрать тип контрольной суммы. Если тип определен неверно, ничего страшного, на прием пакетов это не влияет.

Параметр LIN CRC Type определяет тип используемой методики расчета контрольной суммы при работе с шиной LIN. На способность интерфейса принимать пакеты этот параметр не влияет. В случае если тип контрольной суммы определен неверно, то при передачи пакетов через интерфейс, принимающая сторона будет эти пакеты игнорировать.


Подключение к шине LIN осуществляется при помощи поставляемого с опцией анализатора LIN кабеля.

Назначение проводов LIN кабеля:
Красный – +12 В
Черный – Масса (GND)
Голубой – шина LIN

Внимание! Подключение к шине LIN исследуемого устройства или автомобиля требует обязательного подключения массы (GND) и напряжения питания +12 В.

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


Подробное описание работы с программой CARBUS Analyzer в качестве анализатора LIN шины Вы найдете на отдельной странице – ссылка.

Пожалуйста, прочитайте этот материал полностью!

Установка драйвера


После установки драйвера и подключения интерфейса к компьютеру в диспетчере устройств в разделе Порты должно появиться устройство “STM Virtual Com Port”. Порту будет присвоен номер, например COM3, как на скриншоте ниже. Номер порта будет необходимо ввести в программе CARBUS Analyzer при подключении к интерфейсу, поэтому запомните этот номер.

Возможные проблемы при установки драйвера и методы их решения

Проблемы при установке драйвера могут возникать на старых версиях Windows XP и Windows 7. При этом в диспетчере интерфейс определяется как виртуальный COM порт, но при попытке соединиться с ним, программное обеспечение зависает, либо выдает ошибку. В этом случае обратите внимание на, что на нашем сайте доступны для загрузки два варианта драйверов, и необходимо попробовать установить версию драйвера отличную от той, которая была установлена в первую очередь. Как правило это помогает решить проблему.
Вторая проблема может заключаться в низкой скорости работы интерфейса. В этом случае принимаемые пакеты отображаются с явной задержкой. Это может является следствием того, что на компьютере устаревший контроллер USB. Решить проблему поможет использование внешнего USB хаба (разветвителя), который согласует размер пакетов интерфейса и USB контроллера материнской платы компьютера.



Для работы с интерфейсом CAN-Hacker 3.2 в качестве анализатора шин CAN и LIN необходимо скачать программное обеспечение CARBUS Analyzer на странице СКАЧАТЬ.
Затем распаковать скачанный архив.
В архиве находится как сама программа CARBUS Analyzer, так и утилита для обновления прошивок UBT (папка UBT) с папка с набором актуальных прошивок (UBT\Firmware files)

Настройка программы CARBUS Analyzer и интерфейса для работы с шиной CAN

Если Вы новичок в работе с шиной CAN, обязательно прочтите материал по ссылке.


В меню Settings, в выпадающем списке Device type выбрать CAN_Hacker v 3.x


В выпадающем списке Device mode необходимо выбрать режим работы интерфейса. Доступные режимы:

  • CAN Dual channel + LIN – работа с шинами CAN и LIN одновременно (опция LIN должна быть активирована)
  • CAN Dual channel – работа только с шиной CAN
  • LIN Only – работа только с шиной LIN (опция LIN должна быть активирована)


В выпадающем списке Source необходимо выбрать порт, на котором определяется интерфейс в системе .

Настройка каналов CAN

Настройка каналов CAN осуществляется на вкладках Channel 1: CAN и Channel 2: CAN. Эти вкладки становятся видимой после выбора режима интерфейса для работы с шиной CAN.
Channel baudrate – задает скорость работы CAN шины.


Флаг Listen only mode – переводит интерфейс в режим Listen only, в котором теряется возможность отправки пакетов, но при приеме передаваемых по шине пакетов интерфейс не выставляет на шине флаг подтверждение приема ACK, что делает интерфейс невидимым для других устройств на шине.

Подключение к CAN шине


Подключение к CAN шине осуществляется при помощи поставляемого с интерфейсом кабеля

Назначение проводов:
Желтый с черной полосой – CAN-Low канал 1
Желтый с белой полосой– CAN-High канал 1
Оранжевый с черной полосой – CAN-Low канал 2
Оранжевый с белой полосой – CAN-High канал 2

Назначение переключателей на плате



DIP переключатель на плате устройства служит для подключения резисторов терминаторов 120 Ом между линиями CAN-High и CAN-Low. В положении ON резисторы подключены.

При подключении к однопроводным шинам CAN (SWCAN – Single wire CAN, GMLAN) необходимо провод CAN-Low подключить на массу (GND) исследуемого автомобиля или блока управления, а провод CAN-High на линию SWCAN\GMLAN.

Если настройки CAN произведены верно, физическое подключение к шине верно и на шине присутствует обмен данными то после нажатия кнопки Connect в окне приема отобразятся данные передаваемые по шине CAN.


Подробное описание работы с программой CARBUS Analyzer в качестве анализатора CAN шины Вы найдете на отдельной странице – ссылка.

Работа с шиной LIN
(Должен быть установлен и активирован LIN адаптер )

Для работы с шиной LIN необходимо перевести интерфейс CAN-Hacker 3.2 в режим работы анализатора шины LIN. Для этого необходимо:

  • Зайти в меню Settings
  • В выпадающем списке Device type выбрать CAN-Hacker v3.x
  • В выпадающем списке Device mode выбрать CAN Dual channel + LIN или LIN Only
  • В выпадающем списке Source выбрать порт на котором в системе определился интерфейс.


После выбора типа и режима интерфейса необходимо:


  • Перейти на вкладку Channel 1: LIN. Которая активируется после выбора режима LIN на предыдущей вкладке Device.
  • В выпадающем списке Channel baudrate выбрать скорость обмена на шине LIN
  • В выпадающем списке Detection time выбрать минимальную предполагаемую паузу между пакетами. Рекомендуется оставить значение по умолчанию –2 миллисекунды.
  • Выбрать тип контрольной суммы. Если тип определен неверно, ничего страшного, на прием пакетов это не влияет.

Параметр LIN CRC Type определяет тип используемой методики расчета контрольной суммы при работе с шиной LIN. На способность интерфейса принимать пакеты этот параметр не влияет. В случае если тип контрольной суммы определен неверно, то при передачи пакетов через интерфейс, принимающая сторона будет эти пакеты игнорировать.


Подключение к шине LIN осуществляется при помощи поставляемого с опцией анализатора LIN кабеля.

Назначение проводов LIN кабеля:
Красный – +12 В
Черный – Масса (GND)
Голубой – шина LIN


Либо по схеме:

Внимание! Подключение к шине LIN исследуемого устройства или автомобиля требует обязательного подключения массы (GND) и напряжения питания +12 В.

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


Подробное описание работы с программой CARBUS Analyzer в качестве анализатора LIN шины Вы найдете на отдельной странице – ссылка.

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