Шина Controller Area Network (CAN Bus)

Введение

Controller Area Network (CAN) — это надёжный и универсальный протокол связи, с помощью которого Arduino может обмениваться данными с другими устройствами в сети без участия главного компьютера. Протокол изначально разработан компанией Bosch для автомобильной промышленности, однако сегодня он широко применяется везде, где нужна помехоустойчивая передача данных с проверкой ошибок: в промышленной автоматике, робототехнике и встраиваемых системах.

Работа с CAN на Arduino возможна через разные библиотеки — выбор зависит от используемого железа. В этом уроке основное внимание уделено библиотеке Arduino_CAN, её методам и совместимому оборудованию.

Класс CAN

Класс CAN предоставляет инструменты для отправки и получения данных по шине Controller Area Network, обеспечивая связь между Arduino и другими устройствами в сети.

• Класс CAN рассчитан на платы Arduino со встроенной поддержкой CAN — например, Arduino UNO R4 — или на платы расширения, такие как MKR CAN Shield.

Основные методы класса:

• begin(CanBitRate rate) — инициализирует шину CAN с заданной скоростью передачи (например, CanBitRate::BR_250k для 250 кбит/с).

• available() — проверяет, есть ли входящие CAN-сообщения, готовые к чтению.

• read() — считывает сообщение с шины и возвращает его в виде объекта CanMsg.

• write(const CanMsg& msg) — отправляет CAN-сообщение на шину. Сообщение передаётся как объект CanMsg, содержащий идентификатор CAN, длину данных и полезную нагрузку.

Эти методы формируют базовый набор для работы с CAN-шиной и позволяют организовать надёжный обмен данными между несколькими устройствами. Типичные сценарии использования — считывание показаний датчиков автомобиля или управление промышленным оборудованием.

Выводы CAN на платах Arduino

В зависимости от используемой платы Arduino вам может потребоваться внешний приёмопередатчик (трансивер) для корректной работы с дифференциальным сигналом. Уточните это на странице продукта или в шпаргалке по вашей плате.

Технические характеристики

История CAN

Шина CAN (Controller Area Network) была разработана немецкой компанией Bosch в 1980-х годах. Главная задача — упростить обмен данными внутри автомобиля: дать микроконтроллерам и устройствам возможность общаться напрямую, без центрального компьютера. Это решение резко повысило надёжность и эффективность бортовых систем, обеспечив обмен данными в реальном времени между различными узлами автомобиля. Высокая помехоустойчивость CAN сделала протокол идеальным выбором для жёстких условий эксплуатации.

Хронология стандартов

1986: CAN 1.0

Первая версия протокола CAN вышла в 1986 году. Она поддерживала скорость передачи до 125 кбит/с и применялась преимущественно для диагностики в автомобилях.

1991: CAN 2.0

Вышел стандарт CAN 2.0, ставший поворотным моментом в истории протокола. Скорость передачи выросла до 1 Мбит/с, появились два формата кадра: стандартный с 11-битным идентификатором и расширенный с 29-битным. CAN 2.0 быстро вышел за пределы автомобильной отрасли и стал широко использоваться в промышленных и встраиваемых системах. Именно эту версию поддерживает библиотека Arduino_CAN на дату написания урока (15.08.2024).

2003: Стандартизация ISO

Технология CAN была стандартизирована Международной организацией по стандартизации (ISO) как ISO 11898-1, что обеспечило совместимость и предсказуемость реализаций разных производителей.

2011: CAN FD (Flexible Data Rate)

Для удовлетворения растущих требований к скорости и объёму данных появился стандарт CAN FD. В фазе арбитража он поддерживает до 1 Мбит/с, а в фазе данных — до 8 Мбит/с. Максимальный размер полезной нагрузки вырос с 8 до 64 байт.

2015: ISO 11898-1:2015

Обновлённая редакция стандарта ISO включила CAN FD в качестве официальной части международного стандарта.

В разработке: CAN XL (Extra Large)

Стандарт CAN XL находится в стадии разработки и нацелен на ещё более высокие скорости и большие объёмы данных. Его развитие обусловлено необходимостью конкурировать с Ethernet и другими высокоскоростными протоколами в автомобильных и промышленных приложениях.

Как работает CAN

CAN передаёт данные в виде структурированных последовательностей битов, называемых кадрами. Каждый кадр содержит поля с конкретными функциями: идентификация сообщения, передача данных, обнаружение ошибок.

Общая шина и отсутствие центрального мастера

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

Дифференциальная передача сигнала

Диаграмма дифференциального сигнала CAN: ось Y — напряжение, ось X — данные (биты 0 и 1)

CAN использует дифференциальную схему передачи сигнала: биты данных кодируются разностью напряжений на двух проводах — CAN_H (CAN High) и CAN_L (CAN Low). Именно дифференциальная природа сигнала обеспечивает высокую устойчивость к электромагнитным помехам и позволяет передавать данные на большие расстояния в зашумлённых условиях.

Практический пример: CAN в автомобиле

Представьте современный автомобиль, где множество датчиков и исполнительных устройств разбросаны по всему кузову: система ABS, блок управления двигателем (ECU), датчики температуры и давления. Провода от всех этих устройств проходят рядом с мощными электрическими системами — системой зажигания, генератором — и подвержены значительным электромагнитным помехам.

Традиционные протоколы с одноточечной передачей сигнала (измерение напряжения относительно общей земли) в таких условиях дают сбои: помехи искажают сигнал и приводят к ошибкам данных. CAN решает эту проблему, измеряя не абсолютное напряжение, а разность между CAN_H и CAN_L. Даже если общий уровень сигнала изменится из-за наводок, разность между CAN_H и CAN_L останется прежней — данные дойдут без искажений.

Анимация дифференциального сигнала в шине CAN с иллюстрацией помехоустойчивости

Заземление Wire: практические соображения

Теоретически CAN не нуждается в проводе заземления для передачи данных, поскольку информация закодирована в разности напряжений между CAN_H и CAN_L. Однако на практике провод земли всё же рекомендуется по двум причинам:

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

• Безопасность и надёжность: В автомобиле кузов обычно служит общей землёй, обеспечивая совместимые уровни напряжения для всех устройств и повышая стабильность системы в целом.

Коллизии и арбитраж шины CAN

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

Пример:

• Узел 1 отправляет сообщение с ID 0x100, узел 2 — с ID 0x101. Поскольку 0x100 имеет более высокий приоритет (меньшее числовое значение), узел 1 продолжает передачу, а узел 2 останавливается и повторяет попытку после завершения передачи узла 1.

Структура кадра CAN

Каждое CAN-сообщение упаковывается в кадр, состоящий из нескольких полей:

Формат кадра

Формат стандартного кадра CAN: поля арбитража, управления, данных, CRC и подтверждения

Стандартные и расширенные идентификаторы IDs

CAN-кадры бывают двух форматов: стандартного и расширенного. Главное отличие — длина поля идентификатора.

• Стандартный CAN ID: 11-битный идентификатор, 2048 уникальных IDs.

• Расширенный CAN ID: 29-битный идентификатор, 536 870 912 уникальных IDs.

Типичный кадр CAN содержит следующие поля:

1. Start of Frame (SOF): Маркер начала кадра — доминантный бит, синхронизирующий все узлы.

1. Поле арбитража (Arbitration Field):

• Identifier: Уникальное значение, идентифицирующее сообщение и определяющее его приоритет при арбитраже.
• RTR (Remote Transmission Request): Различает кадры данных и удалённые кадры (запрос данных).

1. Поле управления (Control Field):

• IDE (Identifier Extension): Указывает формат идентификатора — стандартный (11 бит) или расширенный (29 бит).
• r (Reserved bit): Зарезервированный бит, всегда доминантный.
• DLC (Data Length Code): Число байт данных (от 0 до 8).

1. Поле данных (Data Field): Полезная нагрузка — от 0 до 8 байт.

1. Поле CRC (CRC Field):

• CRC Sequence: Значение циклического избыточного кода для обнаружения ошибок.
• CRC Delimiter (DEL): Один рецессивный бит, отделяющий поле CRC от поля подтверждения.

1. Поле подтверждения (ACK Field):

• ACK Slot: Доминантный бит, подтверждающий успешный приём сообщения.
• ACK Delimiter (DEL): Рецессивный бит после бита подтверждения.

1. End of Frame (EOF): Семь рецессивных битов, обозначающих конец кадра.

1. Межкадровое пространство (ITM / Interframe Space): Период бездействия шины между кадрами — гарантирует, что шина свободна перед следующей передачей.

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

Тайминг и синхронизация

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

Фазы тайминга бита

Несмотря на асинхронность, CAN обеспечивает точную синхронизацию узлов через механизм bit timing, состоящий из следующих фаз:

• Sync Segment: Синхронизирующий сегмент. Все узлы определяют начало сообщения по переходу от рецессивного к доминантному биту.

• Propagation Segment: Компенсирует физические задержки распространения сигнала в сети.

• Phase Segment 1 (PS1): Компенсирует ошибки фазовых переходов.

• Phase Segment 2 (PS2): Дополнительная компенсация фазовых ошибок.

Тайминг бита разбивается на кванты времени (Time Quanta, TQ) — минимальные единицы времени в CAN. Общее количество TQ в одном бите определяет тайминг и настраивается для обеспечения максимальной надёжности.

В коде скорость передачи задаётся следующим образом:

CAN.begin(CanBitRate::BR_250k);

Оконечные резисторы (терминаторы)

Оконечные резисторы необходимы для корректной работы шины CAN. Они предотвращают отражения сигнала, которые могут приводить к ошибкам передачи. Как правило, резистор сопротивлением 120 Ом устанавливается между CAN_H и CAN_L на каждом конце шины.

Подключение оконечных резисторов

Подключите резистор 120 Ом между линиями CAN_H и CAN_L на обоих концах шины CAN. Это обеспечит правильное согласование линии, исключит отражения и сохранит целостность сигнала.

Типичные ошибки при работе с CAN

• Отсутствие терминаторов. Без резисторов 120 Ом на концах шины сигнал отражается и вызывает ошибки. Это одна из самых частых причин нестабильной работы.
• Неверная скорость передачи. Все устройства на шине должны работать на одинаковом CanBitRate. Даже небольшое расхождение приводит к постоянным ошибкам CRC.
• Отсутствие трансивера. Многие платы Arduino не имеют встроенного CAN-трансивера. Без него подключение к физической шине CAN невозможно — нужен внешний чип (например, MCP2551 или TJA1050).
• Разность потенциалов земли. Если узлы питаются от разных источников без общего провода GND, трансиверы могут работать некорректно или выйти из строя.

Примеры

Ниже приведены ссылки на практические уроки для различных продуктов Arduino.

• Arduino UNO R4 WiFi CAN Bus

• Sending Data Between Two MKR CAN Shields