
Комментарии 60
А DBC файлы его софт понимает, чтобы трафик на сигналы разложить? А то сырые CAN сообщения это очень маленькая часть работы с CAN шиной.
Конечно же нет. В России мало кто вообще знает про формат dbc .
Сan матрицы тут и по сей день передают в Excel таблицах.
Да и потом, не все протоколы хорошо описываются dbc форматом.
Тот же uds как правило размазывает один параметр по множеству can пакетов.
Автопроизводители прекрасно знают про dbc, canoe, pcan explorer, и всё прочее минимум с 2017 года. Не просто знают, а активно пользуются. Есть лицензии, софт. HIL стенды, валидация. Не нужно экспертно заявлять, что только вот бывший сотрудник arrival знает про dbc, а остальные в лесу живут дремучем
Я еще не встречал российского клиентского ПО для CAN адаптеров, которое умеет анализировать CAN-трафик согласно импортированному *.dbc файлу.
Ровно как и код-генераторов способных по *.dbc файлу написать Cи-функции разбора CAN пакетов.
А почему так? В РФ на CAN новые системы не строят или какой-то другой подход используют? Там же куча данных передается, из сырого HEX же ничего не понять.
Ну вот взять хоть мой опыт в яндекс.драйве.
Там никто про .dbc файлы не слышал.
Вендоры легковых авто РФ свои .dbc файлы не выдают.
В результате разработчкики прошивки телематики MT-32K_LTE_V2 каршеринга просто делают реверс инжиниринг трафика CAN шины и заносят то, что поняли в Google таблицу.
https://docs.google.com/spreadsheets/d/1AGdPkWEUJpL-DqwfBiQXcp8iG4rBm2TTlbpR1-Ipi3c/edit?gid=0#gid=0
Потом в прошивку парсеры руками вписывают.
И форматы стабильные чтоли там?
Я просто помню, что когда в Tesla работал, там формат сигналов в CAN сообщениях мог меняться между билдами практически как угодно. По сути каждый билд для машины мог иметь несовместимые DBC файлы. Вся инфраструктура была заточена на нахождение нужных DBC в артифактах, чтобы раскодировать трейсы.
Что такое трейсы? Красивое слово. Как будто из физики.
Это по сути запись всех сообщений с CAN шины в файл. Потом через DBC файлы оно раскодируется в сигналы и можно смотреть на них как в многоканальном осциллографе. С любой машины их можно было запросить и в онлайне анализировать.
Вот это да! По меркам РФ фантастические технологии.
Что такое трейсы? Красивое слово. Как будто из физики.
ммм как бы в рамках jtag термин с таким же почти смыслом.
Вот это да! По меркам РФ фантастические технологии.
вопрос выбора инструмента... с одной стороны kviser etc. у нас продавали и продают, значит кто то покупает и использует. с другой стороны можно и портянку hex анализировать (как сказали в фильме Матрица "а мне так удобней"). и с учетом тут сказанного это похоже мировая тенденция
И форматы стабильные чтоли там?
Нет. По моим тогдашним наблюдениям в Рено Логан формат CAN сигналов менялся от года к году выпуска модели.
Работать приходилось по сути IT-медвежатником.
Производители любых авто просто так никому свои dbc не выдают. Более того - существующие CAN протоколы передаются от разработчика одной системы автомобиля разработчику другой за колоссальные деньги.
То что Яндекс не смог или не захотел купить описание сообщений у производителя - это проблемы Яндекса, а не всея Руси.
А почему так? В РФ на CAN новые системы не строят
Можно, а зачем? Колесо изобретать некогда, надо грузы тащить срочно-срочно. ГОСТа на эти дела нет, особенно на .dbc файлы. а парсить все это .dbc - то еще удовольствие, много когда , много отладки, много времени.
Конкретно эта штука сделана вполне в духе госпредприятий, не удивлюсь если ее начальное назначение было (весьма ) специфичным и довольно узким.
а парсить все это .dbc - то еще удовольствие, много когда , много отладки, много времени.
Формат dbc текстовый.
BO_ 2583654654 IoStatusInputVoltage7: 8 Device
SG_ VoltageStatus_25 : 0|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_26 : 16|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_27 : 32|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_28 : 48|16@1+ (0.001,0) [0|64.255] "V" Host
BO_ 2583654910 IoStatusInputVoltage8: 8 Device
SG_ VoltageStatus_29 : 0|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_30 : 16|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_31 : 32|16@1+ (0.001,0) [0|64.255] "V" Host
SG_ VoltageStatus_32 : 48|16@1+ (0.001,0) [0|64.255] "V" HostПарсится синтаксическим разбором CSV строчек.
Можно, а зачем?
Если, что-то это наш местный автовазовский мем.
А то сырые CAN сообщения это очень маленькая часть работы с CAN шиной.
Это верно подмечено. Согласен.
А DBC файлы
Есть ли pdf спецификация с описанием текстового формата *.dbc файлов?
Описанием синтаксиса и семантики. Чтобы можно было понять как читать интерпретировать *.dbc файлы глазами.
Вот вроде норм описание: https://www.csselectronics.com/pages/can-dbc-file-database-intro
Я помню, что проблема была когда BigEndian использовался для некоторых сигналов.
Я вот про DBC файлы только что от вас узнал. Зато давно знал про DAT файлы, которые имеют особый бинарный формат описания шин, блоков на шинах и кодировки каждого ID.
Например, вот такой
Есть ненулевая вероятность, что каждый концерн и/или производитель использует вообще свои пропиетарные форматы.
В то время когда я в этой отрасли работал, мне казалось, что как Vector Group скажет работать тем и работают. Ну и PEAK-Systems еще, для тех груп кому бюджета не выдали.
И самописные скрипты конвертировать трейсы между PCAN-Explorer и CANape.
У меня коллега по яндексу до этого 5 лет в ФГУП НАМИ работал (головное предприятие российского автопрома, аналог европейского AVL).
Писал, что все те годы просил, чтобы ему преобразователь от Vector заказали. В итоге он его так и не увидел вживую. Ни разу.
Марафон выпускают линейку устройств с CANopen и CANwise предназначен работать с EDS-профилями для них, SDO и PDO обмен и прочее. На CANwise ставятся расширения функционала, но всё это работает только с их преобразователем. Вот для этого его и берут, использовать его как терминал и под запись трафика смысла нет, есть варианты и подешевле.
--Почему микроконтроллер LPC2366FBD100 и USB ASIC FTDI 2309-C FT2232HL соединены аж 16ю проводами? Это что за интерфейс такой их связывает вместе?
Обычный параллельный интерфейс. Х8 скорости по сравнению с UART, скорее всего подключен к FSMC и таким образом обращение к FTDI это атомарная команда LD/ST.
Да. Видимо подключены по MPSSE/ Multipurpose UART/FIFO Controller

Оно ещё и не чувствителен к настройкам COM порта в таком включении (всегда на максимальной скорости, практически на скорости USB конкретной реализации чипа) + можно управлять через либу D2xx, которая позволяет открывать устройство по серийнику (и пофигу, на каком логическом СОМ он определился) и работать с блоками данных а не побайтно, оптимизируя скорость на стороне ПК.
Как перестать гадать, какой сегодня номер Serial port'а.
весь смысл подобных переходников только в привязанном к ним ПО, и то пока кетайцы клон не станут продавать в разы дешевле.
https://habr.com/ru/articles/944112/?ysclid=mmce5nabbl339655129
USB2CANFD_V1 вообще 600 руб стоит, но клиентское ПО СanGaroo - жуть, да и прошивка USB2CANFD_V1 зависает при отправке обильного трафика.

Можно вообще купить за 1500руб отладочную плату JZ-F407VET6 и портировать на нее open-source проект PCAN-Pro-X.
Вот репозитории на выбор
https://github.com/mkelehk/pcan_pro_x_g431
https://github.com/moonglow/pcan_pro_x
https://github.com/eeshuibuxing/pcan_pro_x
Далее устанавливаете клиентский софт от Peak Systems, получаете бесплатный драйвер, бесплатную нормальную Windows клиентскую программу (PCAN-View).
минутка саморекламы :) https://habr.com/ru/posts/931834/
мне такое чтото надо, на замену технологического кан-монитора:
-ловит определенные пакеты, парсит и выводит на экран
-по кнопке отправляет команды управления
-в режиме моста перекидывает пакеты в ком-порт.
исходя из последнего пункта нужна поддержка ПО для компьютера, и хотелось бы использовать уже готовое. нашёл только исходники на CANable



в режиме моста перекидывает пакеты в ком-порт
пока еще не понятно. в каком формате нужно выходные данные гнать и куда? В принципе такую задачу выполняют целый список железок с открытыми исходниками, на выходе "стандартный" протокол. в принципе даже такую связку можно использовать с добавочным софтом на ПК. можно допилить имеющиеся прошивки до автономного состояния, использовать готовые прошивки как пример. Можно это сделать хоть на arduino, хоть на esp32 есть куча примеров, но с железом не так удобно.
а еще можно в качестве "табло" использовать смартфон/планшет на android - есть и такой софт называется RealDash, как раз для типовых адаптеров CAN USB
. в каком формате нужно выходные данные гнать и куда?
очевидно любой формат который принимает ПО на компьютере
в данный момент у меня это терминал с настроенными парсерами

целый список железок с открытыми исходниками
я в этом направлении пока никуда не продвинулся, но здесь выше подсказали проект для PCAN, буду изучать.
с железом не так удобно
как раз тупая железка с разноцветными лампочками, толстыми кнопочками, дубовым переключателем и однозначными надписями на экране в моём случае предпочтительнее
но здесь выше подсказали проект
очевидно любой формат который принимает ПО на компьютере
на картинке все выглядит очень даже очень, но тчное назначение я так и не угадал.
на всякий случай еще раз https://habr.com/ru/posts/931834/ это памятка с десятком таких проектов, все ищется на github Если задача мониторинга скажем так отладочного, диагностического то все эти проекты для этого и предназначены. в простейшем случае чтобы мониторить и отправлять пакеты hex. а в сложном случае - чтобы обрабатывать их фильтрамами .dbс, графики строить, скрипты писать. И протокол под это заточен.
но я по контексту так понял что требуется более консумерский вариант, скажем для технологов, возможно для обработки в специализированном софте. а софтов много, форматов - тоже
с железом не так удобно
я тут про другое. на stm32 много законченных плат с can трансивером (опять же см. ссылку). На esp32 знаю только одну готовую плату. Но возможностей больше - можно по wifi/bluetooth че то передавать.
памятку я видел, надо много информации рассмотреть, но что-то всё время не сходится: то прошивка есть а исходников не нахожу, то плата картинками а схемы для альтиума нет, ПО надо полнофункциональное.
сейчас такую плату рассматриваю
на stm32 много законченных плат с can трансивером
Есть ли возможность привести примеры?
сколь я помню качал все без регистрации когда то...
а вообще поскольку виртуальный порт - разбираем протокол и пишем свой софт. или используя библиотеки производителя.
22 тысячи рублей %)))
Не самый дорогой вариант

"Связь с компьютером: USB 2.0 Virtual COM Port, класс CDC"
Virtual COM Port позволяет подключаться к преобразователю одновременно из нескольких программ?
Virtual COM Port позволяет подключаться к преобразователю одновременно из нескольких программ?
А зачем?
Для отладки.
Я думаю, что ни один не позволяет. А зачем отлаживать? Или что отлаживать?
У pcan , например, можно открыть хоть 10 экземпляров клиентской программы. Одна будет с правами отправки, а права приема будут у всех.
Так можно отлаживать потерю пакетов в custom утилитах, которые работают с преобразователем.
pcan работает через хуки? Потому что даже обычный железный СОМ порт при открытии в одной программе даже с SHARED атрибутом всё равно не позволял другим программам открывать его через create() потому что, видимо, всё равно требовалась запись, даже если её не использовать. Но в том же время всякие COM мониторы подключались к хукам и подслушивали трафик. Вероятно, множественные легальные подключения без танцев с бубном только у устройств работающих только на чтение, но я не проверял эту теорию.
Хотя, если pcan использует свой драйвер, то может там реализован и редиректор. Драйвер vCOM от ST это обычный системный \\.\СОМ, без изысков.
неправда, доступ к ком-порту эксклюзивный. разве что за исключением сниферов.
Сниферы используют хуки. Поэтому копии программы только считывают, как сказано выше. Другого объяснения нет.
в теории можно запустить отдельный процесс для работы с железом и все копии гуи будут работать через него
Это называется редиректор. Только вот если гуи работают через аппаратуру, скажем, \\.\COM, то для каждого гуя редиректору придётся создавать свой виртуальный. Если гуи могут в сеть, то уже легче, ибо можно пробрасывать на localhost:port и принимать запросы с реюзом порта (т.е. так же, как вебсерверы работают). Тут можно будет даже организовать запись ото всех клиентов, с приоритезацией и арбитражем, чтобы на стороне устройства одно сообщение не вклинивалось в тело другого, нарушая протокол. Это хорошая мысль, ибо гуй при этом может быть на другой машине, например. Но так получилось, что почти все упомянутые гуи в проектах работают только с физическим портом эксклюзивно...

Обзор Преобразователя USB-CAN от Marathon