Пролог

Попробуем разузнать что-нибудь про CAN FD (Controller Area Network Flexible Data-Rate). Однако сначала вспомним, как работает классический CAN (Controller Area Network). Образно выражаясь CAN - это труба для чисел. Можно метафорично сказать, что CAN - это нервная система автомобиля. Именно по САN передаются сигналы от датчиков и команды к исполнительным механизмам агрегатов.

CAN - это двух проводной дифференциальный последовательный полудуплексный интерфейс для передачи бинарных данных между электронными платами PCB. В качестве кабеля чаще всего применяют одну экранированную витую пару проводов: CAN_L, CAN_H.

CAN определяет аж два уровня модели OSI-7 (стек сетевых протоколов): физический и канальный. То есть CAN определяет также и бинарную структуру пакета в кабеле. В пакете CAN фигурируют такие переменные, как ID пакета, 8 байт данных, длина пакета, 15 битная контрольная сумма, биты подтверждения ACK, начало и конец пакета.

Физический уровень

Физика CAN проста. Есть 2 скрученных провода с именами CAN_H и CAN_L. Скрутка позволяет преодолевать электромагнитные помехи. Классический CAN позволяет подключить до 127 устройств. По концам шины нужны терминирующие резисторы. В режиме IDLE пины подтянуты одновременно и к земле и к питанию. Поэтому там как правило 2.5V

Так выгладят классические пакет в натуре.

Шина CAN на минимальной битовой скорости 10 кбит/с может достигать аж 5ти км. На максимальной битовой скорости 1 Мбит/с - 40 метров. На одну шину можно пристегнуть максимум 127 абонентов.

Обработка одного CAN бита

Еще CAN трансиверы каждый бит делит на четыре части (сегмента):

-- the Synchronization Segment (Сегмент синхронизации)
-- the Propagation Segment (Сегмент распространения )
-- the Phase Segment 1 (фазовый сегмент 1)
-- the Phase Segment 2 (фазовый сегмент 2)

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

Сегмент распространения необходим для компенсации задержки в линиях шины.

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

Уровни шины выбираются на границе между фазовым сегментом 1 и фазовым сегментом 2.

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

Большинство CAN-трансиверов также предоставляют возможность делать ADC выборку три раза в течение бита. В этом случае выборка происходит на границах двух квантов, которые предшествуют точке выборки. Финальное значение бита определяется электрическим голосованием внутри цифровых логических цепей CAN-трансивера. Называется это мажорирование сигналов.

Канальный уровень

Биты образуют массив, который формирует пакет CAN. Пакет содержит идентификаторы данные и служебные биты (подтверждение, длина поля данных). CAN пакет передает массив с цифрами (пакет). В пакете самое важное это 8 байт (64 бит) полезных данных. Мы это называем сообщением. Внутри сообщения есть параметры (они же сигналы). У каждого параметра есть номер. Параметры могут быть, как вдавлены друг в друга, так и размазаны по битам поля данных. Максимум в одном сообщении может быть 64 параметра (сигнала) (по одному биту на параметр в предельном случае). В идеологии CAN классического запрос-ответ нет, как в modbus. Обычно ноды просто непрерывно флудят в шину и тот, кому надо выхватывает то, что ему надо.

Главное преимущество интерфейса CAN - это разрешение коллизий без потери битовой скорости. Если два узла начнут передавать пакеты, то продолжит передачу то устройство у которого меньше ID.

CAN интерфейс реализован аппаратно во многих микроконтроллерах, как цифровая электрическая цепь внутри SoC. Это микроконтроллеры от STm, Artery, YTM32(YTM32B1ME05G0MLQ), GigaDevice (GD32C103CB) и проч. Однако есть и отдельные ASIC переходники с SPI на CAN (TJA1145T/FD).

Транспортный уровень

Для классического CAN, чтобы передавать пакеты превышающие 8 байт нужен транспортный протокол. Обычно таким транспортом является протокол ISO-TP. Он же ISO 15765-2.

Уровень приложения

В сетях на основе CAN на уровне приложения обычно гоняют следующие прикладные протоколы: CCP, XCP, CanOpen, UDS или J1939.

Бинарная структура пакета CAN Classic

Бинарную структуру CAN пакета можно изучить тут

Пояснения битовых полей представлены в этой таблице.

Если трансивер передатчика не увидит бит подтверждения ACK, то передатчик будет снова и снова непрерывно передавать этот же CAN пакет, до тех пор пока его кто-нибудь не примет. Таким образом, шина будет занята на 100 %. Однако некоторые микроконтроллеры всё же позволяют настроить MAC на одиночную отправку.

А это структуру пакета с расширенным идентификатором.

Недостатки CAN classic

• Слишком много метаданных. Даже при 11-битных идентификаторах и максимальной длине данных. В лучшем случае на 64 бита полезных данных приходится 47 бит служебной информации, т.е. эффективность менее 58%.

• Объем данных в кадре относительно небольшой - 8 байт. В ранних системах этого было достаточно, но сегодня объем данных значительно увеличился. Узлы должны передавать несколько кадров.

На первый взгляд кажется, что эти две проблемы можно решить, увеличив длину поля данных, но тогда шина будет постоянно перегружена, и устройства с более низким приоритетом могут оказаться недоступными. Кадр с 8 байтами данных (длина кадра 111 бит) обменивается со скоростью 250 кбит/с. Можно подсчитать, что кадр с 8 байтами данных (длина кадра 111 бит) занимает шину в течение 0,4 мс при скорости 250 кбит/с. Если размер данных составляет 64 байта (длина кадра 559 бит или более), то шина будет занята за 5,6 мс. Это означает, что за это время ни одно устройство не сможет ничего передать. Это не очень то вяжется для управления real time процессами для которых и был создан CAN.

Ограничения классического CAN были учтены при разработке его следующей версии CAN FD.

Как CAN борется с помехами ошибками?

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

Bit Monitoring (Наблюдение за битами)
Каждый передатчик на шине CAN считывает уровень передаваемого сигнала. Если фактически считанный уровень бита отличается от переданного, выдается сигнал об ошибке бита. В процессе арбитража ошибка бита не возникает.

Bit Stuffing (Положительное выравнивание)

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

Frame check (Проверка пакета)

Некоторые части сообщения CAN имеют фиксированный формат, т. е. стандарт точно определяет, какие уровни должны происходить и когда. (Этими частями являются разделитель CRC, разделитель ACK, конец кадра). Если контроллер CAN
обнаруживает недопустимое значение в одном из этих фиксированных полей, выдается сигнал об ошибке структуры пакета.

Acknowledgement Check (Проверка подтверждения)

Все узлы на шине, которые правильно получают сообщение (независимо от того, «интересуются» ли они его содержимым или нет), должны отправить доминирующий уровень в так называемом слоте подтверждения в сообщении. Передатчик передаст здесь рецессивный уровень. Если передатчик не обнаружит доминирующий уровень в слоте ACK, выдается сообщение об ошибке подтверждения. Как правило начинается повторная отправка.

Cyclic Redundancy Check (Циклический избыточный код)

Каждое сообщение содержит циклическую контрольную сумму (CRC), и любой узел, который обнаруживает в сообщении CRC, отличную от той, которую он рассчитал сам, сообщит об ошибке CRC.

А теперь внимание, все эти механизмы работают полностью аппаратно на уровне ASIC или MAC! То есть всё это происходит незаметно для программиста микроконтроллера с CAN. Вот так. Вам уже нравится CAN?

Где используется шина CAN?

Я лично своими глазами видел, как интерфейс CAN используют в автомобилях (UDS), RFID считывателях для подсчета шахтёров, грузовозах (J1939), автобусах (J1939), в нано спутниках CubeSat(ах) и космических зондах. Вероятно CAN используют и ещё где-то.

Что такое CAN-FD?

Шина CAN-FD – это следующий этап развития классической шины CAN. CAN с гибкой скоростью передачи данных (CAN-FD) является расширением исходного протокола шины CAN, предназначенного для предоставления более точных данных в реальном времени с увеличенной пропускной способностью для удовлетворения требований сетей транспортных средств следующего поколения.

CAN-FD обеспечивает более высокую скорость передачи данных и больший объем передаваемых данных в одном кадре. Только и всего.

Основные отличия CAN-FD от классической шины CAN:

Между CAN classic и CAN-FD можно выделить 7 фундаментальных отличий. Вот они перед вами:

• В CAN-FD больше нет пакета Remote frame (Кадр удаленного запроса). Это был кадр, запрашивающий передачу определенного идентификатора. Он использовался в случае, когда один узел хочет запросить данные у другого узла.

• В CAN-FD по-другому кодируется 4х битовое поле DLC. Ну это и понятно так как 4мя битами можно досчитать максимум до 16. Даже 6 битов не хватит. А у по стандарту надо 64 байта отмерять. Вот и получилось так, что сначала размер увеличивается линейно, а затем резко подскакивает до значения 64.

  

• В CAN-FD контрольная сумма может достигать 21 бита, в то время, как в классическом CAN CRC составляет всего лишь 15 бит. Если объем данных полезной нагрузки составляет до 16 байт, CRC кодируется в 17 битах. Если объем данных полезной нагрузки превышает 20 байт, CRC кодируется в 21 бите.

• CAN-FD работает одновременно на двух скоростях. Поле арбитража или заголовок кадра передается со скоростью такой же, как и в классическом варианте, например 500 кбит/с. А поле данных передается на скорости кратно превышающую скорость передачи заголовка, и может иметь значение вплоть до 12 Мбит/с! В CAN FD скорость обмена данными на участке передачи байт данных увеличена, между фазой арбитража, куда входит поле ID и DLC, и фазой ожидания подтверждения. Вот так.

• CAN-FD может передать до 64 байт данных в одном пакете! А классический CAN максимум 8 байт. То есть пакет в 8 раз больше!

• Совместимость с сетями CAN 2.0A и CAN2.0B. CAN-FD контроллер способен принимать классические CAN пакеты, а классический CAN контроллер не способен принимать пакеты формата CAN-FD.

• Для шины CAN-FD необходимо применять специальные микросхемы-трансиверы с повышенным быстродействием, например PIC18Q84, TJA1145T/FD, TCAN4550-Q1 и прочие.

  

В кадр CAN-FD, в контрольное поле добавлены биты:

Таким образом на шине CAN FD существуют следующие варианты передачи пакетов:

• 11-битный ID, В классическом CAN формате с количеством байт данных до 8.

• 11-битный ID, В формате CAN-FD с переключением скоростей и количеством байт данных до 64.

• 11-битный ID, В формате CAN-FD без переключения скоростей и количеством байт данных до 64 .

• 29-битный ID, В классическом CAN формате с количеством байт данных до 8.

• 29-битный ID, В формате CAN-FD с переключением скоростей и количеством байт данных до 64.

• 29-битный ID, В формате CAN-FD без переключения скоростей и количеством байт данных до 64 .

 Таким образом из-за различий в базовом формате кадра между CAN-FD и CAN отсутствует совместимость снизу вверх. В переводе на кухонный, модуль CAN classic не может принимать кадры CAN-FD, при этом CAN-FD может принимать пакеты классического CAN. Вот так.

Вообще надо отдать должное разработчика CAN. В далёком 1983 заложив в стандарт всего один зарезервированный бит R0 они смогли через 30 лет в 2012 воспользоваться этим чтобы элегантно встроить новый формат пакетов и при этом полностью сохранить обратную совместимость. Это пример невероятной дальновидности и прозорливости!

Структура пакета CAN FD

Для увеличения максимальной длины данных потребовалось скорректировать формат фрейма CAN FD.

Формат фрейма CAN FD имеет несколько важных отличий от формата фрейма классического CAN:

• после передачи ID вместо бита RTR передается бит RRS, который всегда имеет доминантное состояние. Таким образом, в CAN FD поддерживаются только фреймы данных;

• вместо зарезервированного бита R0, который всегда является доминантным в классическом CAN, передается рецессивный бит EDL (Extend Data Length), сообщающий о том, что это фрейм CAN FD;

• бит BRS (Bit Rate Switching) сообщает приемнику о переключении частоты передачи при передаче данных (подробнее о переключении частот будет рассказано далее);

• бит ESI (Error State Indicator) сообщает, что узел находится в режиме Error-active или Error-passive;

• поле DLC осталось 4-битным и кодирует длину поля данных;

• поле данных может иметь длину до 64 байт;

• защита от потери данных кодируется кодом CRC, который сопровождается полем счетчика бит-стаффинга (поле STC)

Практическая часть

Настало время попробовать CAN-FD на практике. Надо найти какое-нибудь электронное устройство с поддержкой CAN-FD. Таким устройством является учебно-тренировочная электронная плата под названием YTM32B1M-EVB-0144 Rev.B. Вот такая в ней электронная начинка.

Что касается физики CAN, то там есть физика трансивера TJA1044GT/3Z. Это чисто аналоговая микросхема. Сам MAC контроллер обитает внутри SoC-a YTM32B1ME05G0MLQ.

Для самой минималистической отладки CAN-FD надо на своём верстаке собрать такой комплект.

Программная часть

Все исходные коды для запуска CAN-FD присутствуют в свободно распространяемой SDK от производителя микроконтроллера на сайте YunTu. Сам драйвер CAN-FD лежит в папке SDK YTM32B1ME0_1_3_1\YTM32Bx_SDK\platform\drivers\src\flexcan\flexcan_driver.c

вот буквально ключевые функции этого программного компонента.

По ключевому имени этих функций утилитой grep вы найдете даже пример настройки CAN-FD для тестировочного Demo проекта в папке
YTM32B1ME0_1_3_1\YTM32Bx_SDK\YCT_Demos\YTM32B1ME0\Flexcan\YCT\Flexcan_Canfd_Demo\app\main.c

Драйвер позволяет настраивать следующие основные параметры

Помимо запуска самого драйвера CAN надо также настроить значения внутренних мультиплексоров для GPIO (PIN MUX), чтобы подключить к пинам именно CAN периферию, а не что-либо другое.

Значения PIN MUX можно найти в спеке на микроконтроллер под названием YTM32B1ME0x Reference Manual. Искать надо по имени GPIO пина, например пин PTD2 в спеке будет находится по имени PTD_2. То есть через нижнее подчеркивание.

И так для всех остальных пинов, которые вы хотите задействовать в своём микроконтроллере. 

Как настраивать остальной ToolChain для разработки под YTM32x можно почитать в предыдущем тексте.

Отладка

Вот я запрограммировал драйвер CAN-FD, накатил прошивку, как же проверить, что CAN-FD в самом деле работает? Как водится, первым делом смотрим лог начальной загрузки (ЛНЗ).

Видно, что API от SDK везде отработали без осечек.

Типичная ситуация. Есть устройство с CAN. Как проверить, что оно готово к работе? Я подключился к CAN шине щупами осциллографа к проводам CAN_L и CAN_H. В режиме IDLE там будет по 2.5V на каждом пине. Разность CAN_L - CAN_H составит 0V. Когда ничего не передается на проводах CAN_H = 2.3….2.5V, CAN_L = 2,3….2.5V и разность напряжений 0V. Если передается бит, то возникает разность напряжений CAN_H - CAN_L и MAC контроллер CAN это интерпретирует, как сырые биты с данными.

Осциллографом можно убедиться, что битовая скорость в самом деле, как и было установлено в конфиге составляет 2M Bit/s

По хорошему надо конечно же использовать переходник с USB на CAN-FD, соединить электронную плату и LapTop PC через этот переходник и при помощи специализированного DeskTop ПО на PC анализировать испускаемые гаджетом пакеты. Однако трудность в том, что у меня нет ни переходника ни специализированного ПО. В связи с этим надо как-то импровизировать. Как можно заметить, на плате заложено аж 4 порта для физики CAN трансивера. Надо как-то этим воспользоваться.

Можно просто соединить CAN порты между собой самыми обыкновенными проводами-перемычками. Вот по такому правилу.

Эта техника называется словом LoopBack (петля). Микроконтроллер сам отправляет и сам же принимает свои же CAN пакеты. Как говорят в народе: "клин клином вышибают". Одновременно с этим в прошивке реализована UART-CLI, где можно своими глазами увидеть через утилиту TeraTerm вот такой лог.

Как можно заметить, CAN-FD пакеты благополучно отправляются и принимаются со всех четырех доступных портов. Получился своего рода импровизированный WireShark только на MCU и с доступом через UART-CLI.

Обзор профессиональных средств аппаратной отладки

Тут сразу стоит упомянуть, что разработка агрегатов с подчинением по CAN-FD это удовольствие не из дешевых. Сам CAN-FD применяются с 2011 года главным образом в автомобилях премиум класса и гиперкарах за миллионы евро за один автомобиль. Вот так господа... Поэтому и средства аппаратной отладки тут тоже очень дорогие. При этом львиную долю стоимости таких переходников составляет софтвер, цену которого либо закладывают в стоимость розничного прибора, либо и вовсе продают отдельно за ещё большие деньги. При этом без оригинального софтвера эти переходники в FPGA внутри можно использовать в автомобиле только, как утяжелители на бампере.

К слову, в каждом из таких переходников зиждится настоящая FPGA микросхема, которая буквально аппаратно на лету демодулирует CAN-FD пакеты из непрерывного потока десятки мегагерцовых ADC семплов от диф пары! С нулевым latency. Да, господа, а Вы как хотели... Поэтому переходники с USB на CAN-FD - это очень и очень серьезные технологии, доступные далеко не каждому государству на планете...

Идеи проектов

На основе этого микроконтроллера YTM32B1ME0x можно теоретически сделать первый российский переходник с USB на CAN-FD. Спроектировать схемотехнику, развести топологию, написать прошивку, написать клиентское ПО для Windows 10 и Linux и получится полноценное средство для разработки и отладки агрегатов обменивающихся данными по CAN-FD. Альтернатива и эрзац санкционным Vector, Kvaser и Peak-System.

Итоги

Удалось научиться пользоваться CAN-FD на микроконтроллере YTM32. Теперь приблизительно понятно, как отправлять и как принимать CAN-FD пакеты.

Семейство интерфейсов CAN это далеко не единственный и, к слову, не самый дешевый выбор для разворачивания сетей типа общая шина. Есть ещё RS485, LIN, 1-Wire, DALI, MIL-STD-1553, ARINC 429 и прочие. Сравнение интерфейсов можно произвести вот в этом реестре

Словарь

Ссылки

Вопросы

• Каким переходником с USB на CAN-FD можно отлаживать интерфейс CAN-FD? Какое для этого нужно ПО?

• Что такое CAN-матрица?

• Что такое CAN bus-off?

• Как взламывать CAN трафик в иномарках? Какой пакет CAN шины отвечает за скорость автомобиля?

• Как найти в CAN трафике легкового автомобиля пакет, который показывает количество пассажиров в автомобиле?

• Как измерить процент загрузки CAN шины трафиком в реальном времени?