3.25. Основы шины CAN

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

В отличие от SPI и I2C, в CAN нет единого «контроллера» и набора «периферийных устройств». Каждый узел на шине является равноправным, и любой узел может передавать данные в любой момент, когда шина свободна. Масштабируемость обеспечивается архитектурой широковещания с арбитражем.

3.25.1. Широковещание с приоритетным арбитражем

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

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

Секрет в двух электрических состояниях шины: доминантном (логический 0) и рецессивном (логическая 1). Провода CAN удерживаются на высоком уровне (рецессивное состояние) согласующими резисторами, когда ни один узел не передаёт; любой узел может притянуть провода вниз (доминантное состояние), пропуская ток через свой трансивер. Получается монтажное И (wired-AND): если хотя бы один узел переводит шину в доминантное состояние, линия читается как доминантная, и читается как рецессивная только тогда, когда все узлы её отпустили. Доминантное состояние всегда побеждает. (Некоторые источники называют ту же схему монтажным ИЛИ (wired-OR), трактуя «доминантное» как активный сигнал, а не как И от рецессивных битов — физическое поведение в любом случае идентично.)

Одна линия шины, удерживаемая на высоком уровне согласующим резистором к Vcc. К шине подключены три узла (A, B, C). Выходной каскад каждого узла представляет собой диод, включённый последовательно с ключом на землю — диод направлен от шины вниз к ключу, поэтому замыкание ключа притягивает шину к низкому уровню через диод, но ни один узел не может перевести шину на высокий уровень.

Монтажное И в концептуальном виде. Реальная CAN реализует ту же логику на дифференциальной паре (CAN_H / CAN_L) с трансиверами и согласующими резисторами, распределёнными по обоим проводам, но правило на шине то же самое: любой узел может притянуть шину в доминантное состояние, и только когда все узлы её отпустили, она читается как рецессивная.

Арбитраж напрямую использует эту асимметрию. Каждый передающий узел отправляет свой ID по одному биту за раз, начиная со старшего бита, и наблюдает за шиной во время передачи. Узел, который выставляет на провод рецессивный бит, но считывает обратно доминантный, понимает, что другой узел с меньшим ID передаёт в этот же момент и выиграл данную битовую позицию. Он немедленно прекращает управлять шиной и переходит в режим прослушивания. Победивший узел тем временем видит, что его собственные биты выходят без изменений — с его точки зрения ничего необычного не произошло. ID с меньшим номером побеждает, потому что его доминантные биты подавляют рецессивные биты, которые ID с большими номерами иначе передали бы в тех же позициях.

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

Это стиль публикации/подписки (publish/subscribe), который позволяет CAN работать в больших масштабах: любой может передавать, любой может слушать, а ID делают диспетчеризацию неявной.

3.25.2. Физическая шина

Контроллер CAN в микроконтроллере не управляет шиной напрямую. Он предоставляет лишь два вывода 3,3 В уровня CMOS — TX (бит, который он хочет отправить) и RX (бит, который он видит на шине), — и эти выводы идут к отдельной микросхеме, называемой трансивером CAN или PHY. Трансивер находится между контроллером и реальными проводами CAN; именно он умеет общаться с шиной.

Сама шина представляет собой дифференциальную пару 5 В:

  • CAN_H — «высокий» провод пары.

  • CAN_L — «низкий» провод.

В рецессивном состоянии оба провода находятся примерно на уровне 2,5 В (середина 5-вольтового питания шины). В доминантном состоянии трансивер подтягивает CAN_H примерно до 3,5 В, а CAN_L опускает примерно до 1,5 В, создавая дифференциал около 2 В между проводами пары. Приёмники измеряют разность между двумя проводами, что делает сигнал невосприимчивым к синфазным помехам, наводимым на длинных кабельных трассах.

Двусторонняя работа трансивера:

  • На стороне TX он считывает несимметричный вывод TX контроллера с уровнем 3,3 В и либо разводит CAN_H и CAN_L для доминантного состояния, либо отпускает оба для рецессивного.

  • На стороне RX он считывает дифференциальную пару CAN_H / CAN_L и выдаёт несимметричный уровень 3,3 В на своём выводе RX обратно контроллеру.

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

3.25.3. Кадр данных

Стандартный кадр данных CAN выглядит на проводе так:

Восемь полей, изображённых последовательно: SOF (1 бит), ID (11 бит), RTR (1 бит), управление (6 бит), данные (0–8 байт), CRC (16 бит), ACK (2 бита) и EOF (7 бит).

Стандартный кадр данных CAN: поля SOF, ID, RTR, управления, данных, CRC, ACK и EOF.

У каждого поля своя конкретная задача:

  • SOF (начало кадра). Один доминантный бит, который сообщает о начале нового кадра и синхронизирует битовый такт каждого узла.

  • ID (идентификатор). 11-битный идентификатор, по которому шина проводит арбитраж. Меньшее число = более высокий приоритет.

  • RTR (запрос удалённой передачи). Устанавливается при запросе данных, а не при их доставке; приёмники с совпадающим ID отвечают, передавая данные сами.

  • Управление. 6-битное поле, кодирующее длину данных (DLC) и несколько служебных битов.

  • Данные. От 0 до 8 байт полезной нагрузки (CAN Classic; CAN FD расширяет это до 64 байт).

  • CRC. Всего 16 бит: 15-битная CRC по предшествующим полям плюс 1-битный разделитель CRC.

  • ACK. Всего 2 бита. В первом бите — слоте ACK — передатчик отпускает линию, и любой узел, корректно принявший кадр, притягивает её вниз; второй бит — это рецессивный разделитель. Отсутствие ACK сообщает передатчику, что ни один узел не услышал кадр и его следует передать заново.

  • EOF (конец кадра). Семь рецессивных битов, закрывающих кадр.

Всё это генерируется и декодируется контроллером CAN аппаратно; программное обеспечение видит только ID, данные и несколько флагов.

3.25.4. Где применяется CAN

Конструктивные решения CAN определяют её нишу:

  • Надёжность. Дифференциальная передача по витой паре, встроенное обнаружение ошибок, детерминированный приоритетный арбитраж и автоматические повторы позволяют CAN выживать в электрически зашумлённых средах, где UART и SPI исказили бы данные.

  • Многомастерность. Любой узел может передавать в любое время. Центральный контроллер не требуется, и ни один узел не является единой точкой отказа.

  • Ограниченная полоса пропускания. Классическая CAN достигает потолка около 1 Mbit/s; CAN FD расширяет это. CAN — правильный выбор, когда канал проходит между платами или модулями, часто на расстоянии в метры кабеля, и приоритетом является надёжность.

  • Протоколы верхнего уровня. Голая шина CAN не определяет, что означает тот или иной ID и как разбить длинное сообщение на фрагменты. Эти правила добавляют сверху протоколы прикладного уровня — CANopen, J1939, ISO-TP/UDS, NMEA 2000. Отдельно стоит знать о файле DBC: это специфичный для производителя текстовый формат, в котором записано, какие ID несут какие сигналы на битовом уровне в конкретном транспортном средстве или системе. Файлы DBC — это формат метаданных, описывающий компоновку сообщений одной шины, а не самостоятельный протокол.

Драйвер в Шина CAN в коде обрабатывает CAN-кадр на уровне провода; сопоставление ID со значениями — задача приложения.