Арбитраж
в CAN.
Сеть
CAN
работает в режиме CSMA
. Это означает, что когда имеются данные
для передачи, узел CAN «слушает» шину (C
S – контроль несущей) и если шина свободна,
переходит к передаче сообщения.
Множественный доступ (M A) заключается
в том, что любой CAN-узел, определив, что
шина свободна, может начать передачу
своего сообщения. При этом два и более
узла, определив, что шина свободна, могут
начать передавать свои кадры. Это ведет
к конфликтной ситуации на шине. В широко
распространенной компьютерной локальной
сети Ethernet при столкновении передающие
узлы обнаруживают такую ситуацию и
прекращают передачу, чтобы позже
попытаться снова передать свои сообщения.
Это ведет к потере времени и уменьшению
пропускной способности сети. CAN такую
ситуацию решает по-другому. Когда
происходит конфликтная ситуация при
обращении к шине, CAN определяет победителя
на основе побитного арбитража содержимого
поля, то есть идентификаторов. Побеждает
узел с наивысшим приоритетом, то есть
имеющий идентификатор с наименьшим
числовым значением. Только победивший
узел продолжает передачу данных,
остальные попытаются передать свои
сообщения позже. Такой метод определения
победителя называется арбитраж
столкновений. Данный метод арбитража
обеспечивается тем, что все CAN-узлы
подключены к шине по схеме «монтажное
И», где узел, выставляющий на шину «0» —
доминантный уровень, подавляет «1» —
рецессивный уровень, выставленный
другим узлом. Кроме того, в процессе
арбитража при передаче идентификатора
узел проверяет действительное состояние
шины и сравнивает его с передаваемым
значением.
Если
при передаче логической 1 с шины
принимается доминантный бит (логический
0), то считается, что другой узел передает
сообщение с более высоким приоритетом
и данный узел прекращает передачу.
Обнаружение
и обработка ошибок. CAN
протокол имеет мощные средства обнаружения
ошибок. В CAN реализовано 5 механизмов
проверки на наличие ошибок. Все они
реализованы аппаратным способом.
Ошибка
контрольной суммы (CRC Error). 15-разрядное
значение кода CRC рассчитывается узлом
передачи во время формирования сообщения.
Все узлы сети принимают это сообщение,
вычисляют CRC и сравнивают его с принятым
значением. При несовпадении контрольных
сумм сообщение считается ошибочным.
Если хотя бы один узел не примет данные
должным образом, будет сформировано
сообщение об ошибке.
Ошибка
подтверждения. В
поле подтверждения ACK Field передающий
узел проверяет наличие доминантного
бита (логического 0). Если хотя бы один
узел принял сообщение правильно, то
доминантный бит будет сформирован в
поле подтверждения. Если был получен
рецессивный бит (логическая 1), значит
ни одно устройство не приняло сообщение,
и передающий узел регистрирует ошибку
подтверждения.
Ошибка
формата (Form Error). Все
CAN узлы проверяют соответствие структуры
принимаемого сообщения его фиксированному
формату и его размеру. Если формат
сообщения нарушен, то узлы генерируют
ошибку формата.
Ошибка
бита (Bit Error). Каждый
узел во время передачи битов в сеть
сравнивает значение передаваемого им
бита со значением бита, которое появляется
на шине. Если эти значения не совпадают,
то узел генерирует ошибку бита.
Естественно, что во время арбитража на
шине этот механизм проверки ошибок
отключается.
Ошибка
битстаффинга. При
передаче сообщения в CAN работает механизм
битстаффинга – вставка дополнительного
бита после пяти подряд идущих бит с
одинаковым значением. Принимающий узел
этот дополнительный бит удаляет. Если
приемник обнаруживает на шине больше
5 последовательных бит с одинаковым
значением, то он генерирует ошибку
битстаффинга.
Каждый
узел CAN имеет два счетчика ошибок:
1)
счетчик ошибок при передаче (TEC);
2)
счетчик ошибок при приеме (REC).
Каждый
узел сети CAN может находиться в одном
из трех состояний:
1)
активной ошибки ; (2) пассивной ошибки;
(3) отключен от шины.
Состояние
активной ошибки. Когда
узел только начинает работу в сети CAN,
он находится в состоянии активной
ошибки. Узел может принимать активное
участие в передаче данных. В случае
обнаружения ошибки на шине он передает
в сеть флаг. Этот флаг состоит из 6
последовательных доминантных бит,
поэтому все узлы его регистрируют. Узел
находится в состоянии активной ошибки,
пока содержимое любого из счетчиков не
превышает предела 127. Состояние активной
ошибки – нормальный режим работы узла
с возможностью принимать и передавать
данные без ограничений.
Состояние
пассивной ошибки. Узел
приходит в это состояние, когда содержимое
одного из счетчиков ошибок превышает
значение 127. Узлу в этом состоянии
запрещается передавать активное
сообщение об ошибке, но вместо этого он
передает в сеть флаг. Этот флаг состоит
из 6-ти рецессивных битов, поэтому
остальные узлы сети его не замечают, а
он производит только увеличение счетчика
ошибок данного узла.
Состояние
– отключение от шины. Узел
переходит в это состояние, когда
содержимое хотя бы одного из двух
счетчиков превышает предел 255. В этом
состоянии узел не может передавать или
принимать сообщения, выдавать подтверждение
или формировать сообщение об ошибке.
Скорость
передачи и длина сети. Спецификация
CAN исходит из предположения, что все
узлы принимают сигналы с шины одновременно,
то есть в одно и то же время один и тот
же бит принимается всеми узлами в сети.
С одной стороны такое положение вещей
делает возможным побитовый арбитраж,
а с другой стороны ограничивает длину
сети. Каждый узел, вовлеченный в арбитраж,
должен быть способен осуществлять
выборку каждого бита в пределах одного
и того же интервала передачи бита. Обычно
выборка производится примерно в середине
интервала передачи бита. При передаче
и приеме сигналов по шине неизбежно
появляется задержка распространения
tDEL, которая определяется как сумма
времени прохождения сигнала по шине
tBUS, выходной задержки передатчика
tTRANSM и входной задержки приемника
tRECEIVE.
Очевидно,
что с увеличением скорости передачи
интервал передачи бита сокращается, а
это может привести к ошибочной выборке
действительного значения бита из-за
влияния задержки распространения.
Стандарт
ISO 11898 определяет, что при максимальной
скорости передачи 1 Мбит/с длина кабеля
шины CAN не должна превышать 40 метров.
При использовании гальванической
развязки максимальная протяженность
сети при скорости передачи 1 Мбит/с
ограничена 9 метрами.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
CAN (Control Area Network) —
последовательная
магистраль,
обеспечивающая
увязку в
сеть «интеллектуальных»
устройств
ввода/вывода,
датчиков и
исполнительных
устройств
некоторого
механизма
или даже
предприятия.
Характеризуется
протоколом,
обеспечивающим
возможность
нахождения
на
магистрали
нескольких
ведущих
устройств,
обеспечивающим
передачу
данных в
реальном
масштабе
времени и
коррекцию
ошибок,
высокой
омехоустойчивостью.
Система CAN
обеспечена
большим
количеством
микросхем,
обеспечивающих
работу
подключенных
к
магистрали
устройств,
разработку
которых
начинала
фирма BOSH для
использования
в
автомобилях,
и в
настоящее
время
широко
используемых
в
автоматизации
промышленности.
Цеколёвка
разема
приведена
на рисунке.
| Стандарт | ISO 11898 |
| Скорость передачи |
1 Мбит/с (максимум) |
| Расстояние передачи |
1000 м (максимум) |
| Характер сигнала, линия передачи |
дифференциальное напряжение, скрученная пара |
| Количество драйверов |
64 |
| Количество приемников |
64 |
| Схема соединения |
полудуплекс, многоточечная |
- Предназначен
для
организации
высоконадежных
недорогих
каналов
связи в
распределенных
системах
управления.
Интерфейс
широко
применяется
в
промышленности,
энергетике
и на
транспорте.
Позволяет
строить
как
дешевые
мультиплексные
каналы, так
и
высокоскоростные
сети. - Скорость
передачи
задается
программно
и может
быть до 1
Мбит/с.
Пользователь
выбирает
скорость,
исходя из
расстояний,
числа
абонентов
и емкости
линий
передачи.
| Расстояние, м |
25 | 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 |
| Скорость, Кбит/с |
1000 | 800 | 500 | 250 | 125 | 50 | 20 | 10 |
- Максимальное
число
абонентов,
подключенных
к данному
интерфейсу
фактически
определяется
нагрузочной
способностью
примененных
приемопередатчиков.
Например,
при
использовании
трансивера
фирмы PHILIPS PCA82C250
она равна 110. - Протокол CAN
использует
оригинальную
систему
адресации
сообщений.
Каждое
сообщение
снабжается
идентификатором,
который
определяет
назначение
передаваемых
данных, но
не адрес
приемника.
Любой
приемник
может
реагировать
как на один
идентификатор,
так и на
несколько.
На один
идентификатор
могут
реагировать
несколько
приемников. - Протокол CAN
обладает
развитой
системой
обнаружения
и
сигнализации
ошибок. Для
этих целей
используется
поразрядный
контроль,
прямое
заполнение
битового
потока,
проверка
пакета
сообщения CRC-полиномом,
контроль
формы
пакета
сообщений,
подтверждение
правильного
приема
пакета
данных.
Хемминговый
интервал d=6.
Общая
вероятность
необнаруженной
ошибки 4.7×10-11. - Система
арбитража
протокола CAN
исключает
потерю
информации
и времени
при «столкновениях»
на шине. - Интерфейс
с
применением
протокола CAN
легко
адаптируется
к
физической
среде
передачи
информации.
Это может
быть
дифференциальный
сигнал,
оптоволокно,
просто
открытый
коллектор
и т.п.
Несложно
делается
гальваническая
развязка. - Элементная
база,
поддерживающая
CAN, широко
выпускается
в
индустриальном
исполнении.
CAN 2.0 А
1.
Введение
CAN (Controller Area Network) —
это
последовательный
протокол
связи с
эффективной
поддержкой
распределения
контроля в
реальном
времени и
очень
высоким
уровнем
безопасности.
Основное
назначение:
организация
передачи
информации
в сложных
условиях,
таких как
среды с
высоким
уровнем
различного
рода помех.
Этот
протокол
передачи
применяется
в
автомобильной
электронике,
машинных
устройствах
управления,
датчиках
при
передаче
информации
со
скоростями
до 1 Мбит/сек.
Протокол
CAN можно
разделить
на
следующие
уровни:
- объектный
уровень - канальный
уровень - физический
уровень
Объектный
и канальный
уровни
включают
весь сервис
и функции
передачи
данных
определяемых
ISO/OSI моделью.
Область
объектного
уровня
включает:
- Поиск
сообщений
для
передачи. - Фильтрация
сообщений,
полученных
от
канального
уровня - Обеспечение
связи
между
прикладным
уровнем и
аппаратными
средствами.
Объектный
уровень
можно
реализовывать
различными
способами.
Область
канального
уровня
главным
образом —
протокол
передачи, т.е.
управление
кадрами,
выполнение
арбитража,
проверка и
сигнализация
ошибок,
типизация
ошибок.
Внутри
канального
уровня
решается,
является ли
шина
свободной
для начала
новой
передачи.
Все что
находится
внутри
канального
уровня, не
имеет ни
какой
свободы к
модификации.
Область
физического
уровня —
фактическая
передача
бит между
различными
узлами.
Внутри
одной сети
физический
уровень
должен быть
одинаков
для всех
узлов.
Физический
уровень
можно
реализовать
различными
способами.
2.
Основные
характеристики
протокола
- каждое
сообщение
имеет
определенный
приоритет - существуют
гарантированные
времена
ожидания - гибкость
конфигурации - групповой
приём с
временной
синхронизацией - система
непротиворечивости
данных - multimaster
- обнаружение
и
сигнализация
ошибок - автоматическая
ретрансляция
разрушенных
сообщений - различие
между
временными
ошибками и
постоянными
отказами
узлов и
автономное
отключение
дефектных
узлов
Сообщения
Информация
по шине
посылается
в
фиксированном
формате
сообщений
различной,
но
фиксированной
длины. Когда
шина
свободна,
любой узел
может
начать
передачу
нового
сообщения.
Информационная
маршрутизация
В CAN
нет ни какой
информации
относительно
конфигурации
сети (например,
адреса узла).
Это имеет
несколько
важных
следствий:
Гибкость
системы:
Узел
может быть
добавлен в CAN —
сеть, без
каких либо
изменений в
программном
или
аппаратном
обеспечении,
какого — либо
узла в сети.
Маршрутизация
сообщений:
Содержание
сообщения
определяется
идентификатором.
Идентификатор
не
указывает
адреса
сообщения, а
описывает
значение
данных так,
чтобы все
узлы сети
были
способны
решить
фильтрацией
сообщений,
нужны им эти
данные или
нет.
Передача
группе:
Как
следует из
фильтрации
сообщений,
любое число
узлов может
одновременно
получать и
реагировать
на одно и
тоже
сообщение.
Непротиворечивость
данных:
Внутри
сети CAN
гарантировано,
что
сообщение
принято
всеми
узлами или
ни одним
узлом.
Скорость
передачи
информации
Скорость
передачи
информации
в CAN — сети
может быть
различной
для каждой
сети. Однако
в каждой
конкретной
сети
скорость
передачи
информации
фиксирована.
Приоритеты
Идентификатор
и RTR — бит
определяют
статический
приоритет
сообщения в
течение
доступа к
шине.
Удаленный
запрос
данных
Посылая
кадр
удаленного
запроса
данных, узел
может
потребовать
данные от
другого
узла. Кадр
данных и
кадр
удаленного
запроса
данных
должны
иметь
одинаковый
идентификатор.
Multimaster
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Доступ к
шине
получает
узел,
передающий
кадр с
наивысшим
приоритетом.
Арбитраж
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Если два или
больше узла
начинают
передавать
сообщения в
одно и тоже
время,
конфликт
при доступе
к шине будет
решен
поразрядным
арбитражем
используя
идентификатор
и RTR — бит.
Механизм
арбитража
гарантирует,
что ни время,
ни
информация
не будут
потеряны.
Если кадр
данных и
кадр
удаленного
запроса
данных
начинают
передаваться
в одно время,
то кадр
данных
имеет более
высокий
приоритет,
чем кадр
удаленного
запроса
данных. В
течение
арбитража
каждый
передатчик
сравнивает
уровень
переданного
бита с
уровнем,
считываемым
с шины. Если
эти уровни
одинаковы,
узел может
продолжать
посылать
данные
дальше. Если
был послан
уровень лог.
‘1’ (recessive), а с шины
считан
уровень лог.
‘0’ (dominant), то узел
теряет
право
дальнейшей
передачи
данных и
должен
прекратить
посылку
данных на
шину.
Безопасность
Чтобы
достичь
высокой
безопасности
передачи
данных,
приняты
мощные меры
нахождения
ошибок,
сигнализации
ошибок и
самотестирование
в каждом CAN —
узле.
Обнаружение
ошибок
Для
обнаружения
ошибок
приняты
следующие
меры:
- текущий
контроль (передатчики
сравнивают
уровни
битов,
которые
переданы, с
уровнями
на шине). - побитовое
заполнение - проверка
кадра
сообщения
Эффективность
обнаружения
ошибок
Механизмы
обнаружения
ошибок
имеют
следующие
возможности:
- обнаружение
всех
глобальных
ошибок - обнаружение
всех
локальных
ошибок
передатчиков - обнаружение
до 5
случайно
распределённых
ошибок в
сообщении - обнаружение
последовательной
группы
ошибок
длиной до 15 - обнаружение
любого
числа
нечетных
ошибок в
сообщении
Общая
остаточная
вероятность
ошибки для
необнаруженных,
разрушенных
сообщений,
меньше чем:
скорость
появления
ошибки * 4.7*10Е-11
Сигнализация
ошибки и
время
восстановления
Разрушенные
сообщения
помечаются
узлом,
обнаружившим
ошибку.
Такие
сообщения
прерываются
и будут
переданы
снова. Время
восстановления
от
обнаружения
ошибки до
начала
следующего
сообщения в
большинстве
случаев = 29 *
время
передачи
одного бита,
если не
имеется
никаких
дальнейших
ошибок.
Типизация
ошибок
Узлы
CAN способны
отличить
временные
ошибки от
постоянных
отказов.
Дефектные
узлы будут
отключены.
Соединения
Линия
связи по
протоколу CAN —
это шина, к
которой
может быть
подключён
ряд узлов.
Количество
узлов не
имеет
никакого
теоретического
предела.
Фактически
количество
узлов будет
ограничено
временами
задержек и/или
электрической
нагрузкой
на линии
шины. Способ,
которым
выполнена
шина, не
установлен
в данной
спецификации.
Например,
это может
быть
одиночный
провод (+земля),
два
дифференциальных
провода,
оптическое
стекловолокно.
Уровни
шины
Шина
может
принимать
одно из
дополняющих
друг друга
значений:
«dominant» и «recessive». В
случае
одновременной
подачи «dominant»
бита и «recessive»
бита,
возникающее
в
результате
значение
шины будет
«dominant».
(Прим.
переводчика:
далее
считается
что «recessive» = лог.
«1», а «dominant» = «0»).
Подтверждение
Все
приёмники
проверяют
непротиворечивость
принимаемого
сообщения и
подтверждают
непротиворечивое
сообщение.
Режим
«сна» /
пробуждения
Чтобы
уменьшить
потребляемую
мощность
системы,
узел CAN может
быть
переведен в
режим «сна».
Режим «сна»
заканчивается
при любом
действии на
шине или
внутреннем
состоянии
системы. При
пробуждении
запускается
внутренняя
синхронизация,
канальный
уровень
ждёт
стабилизации
генератора
системы, а
затем будет
ожидать
самосинхронизации
к действиям
на шине (синхронизация
к действиям
на шине
заканчивается
после
принятия
последовательности
11 битов с лог.
«1»). Для
пробуждения
узла из
режима
покоя может
использоваться
некоторое
сообщение
пробуждения
со
специальным
идентификатором.
3.
Передача
сообщений
При
передаче
информации
с помощью
протокола CAN
используется
четыре типа
кадров. Кадр
данных
содержит
данные,
передаваемые
передатчиком
приёмнику (ам).
Кадр
удаленного
запроса
данных
передается
на шину для
запроса
передачи
кадра
данных с тем
же самым
идентификатором.
Кадр ошибки
передаётся
при
обнаружении
ошибки на
шине. Кадр
перегрузки
используется
для
обеспечения
дополнительной
задержки
между
предшествующим
и
последующим
кадрами
данных или
кадрами
удаленного
запроса
данных.
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
межкадровым
пространством.
3.1
Кадр данных
(DATA FRAME)
Кадр
данных
состоит из 7
различных
полей: «Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
Начало
кадра (Start of Frame)
Отмечает
начало
кадра
данных или
кадра
удаленного
запроса
данных.
Состоит из
бита с лог. ‘0’.
Узлу
разрешено
начинать
передачу
только при
свободной
шине (см.
простой
шины). Все
узлы должны
быть
синхронизированы
по началу
фронта,
вызванного
полем «начало
кадра» (см.
аппаратная
синхронизация)
узла,
начавшего
работу
первым.
Поле
арбитража
(Arbitration Field)
Состоит из
идентификатора
и RTR-бита.
CRC-последовательность
(CRC Sequence):
Для
вычисления CRC
полинома,
полином,
коэффициенты
которого
задаются
потоком,
состоящим
из значений,
бит полей: «начало
кадра «, «поле
арбитража»,
«поле
контроля», «поле
данных» (если
имеется) (самые
младшие 15
коэффициентов
полинома =0),
должен быть
разделён
полином
следующего
вида:
x^15+x^14+x^10+x^8+x^7+x^4+x^3+1
Остаток
этого
полиномиального
деления
есть CRC-последовательность,
передаваемая
по шине.
CRC-разделитель
(CRC Delimiter):
CRC-последовательность
сопровождается
CRC-разделителем,
который
всегда
равен лог. «1».
Поле
подтверждения
(ACK FIELD)
Длина
2 бита.
Содержит
область
подтверждения
(1 бит) и
разделитель
подтверждения
(1 бит). В поле
подтверждения
передающий
узел
посылает
два бита с
лог. «1».
Приемник,
получивший
правильное
сообщение,
информирует
об этом
передатчик,
посылая бит
с лог. «0» (т.е.
перезаписывая
бит в
области
подтверждения
с лог. «1» на
бит с лог. «0»).
Область
подтверждения
(ACK Slot)
Все
узлы,
получившие
соответствующую
CRC-последовательность,
сообщают об
этом внутри
области
подтверждения
перезаписью
бита с лог. «1»
на бит с лог.
«0».
Разделитель
подтверждения
(ACK Delimiter)
Второй
бит области
подтверждения
должен быть —
лог. «1».
Следовательно,
область
подтверждения
окружена
битами с лог.
«1» (CRC-разделитель
и
разделитель
подтверждения).
Конец
кадра (END OF FRAME)
Каждый
кадр данных
и кадр
удаленного
запроса
данных
разграничены
последовательностью
флагов,
состоящей
из семи
битов с лог.
«1».
3.2
Кадр
удаленного
запроса
данных (REMOTE FRAME)
Узел
может
инициализировать
передачу
кадра
данных
другим
узлом,
посылая
кадр
удаленного
запроса
данных.
Этот кадр
состоит из 6
полей:
«Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
В отличие от
кадра
данных , RTR бит =
«1». Здесь нет
поля данных,
зависящего
от значения
«кода длины
данных»,
внутри
этого поля
может быть
записано
любое из
допустимых
значений (0��.8).
Полярность RTR
бита
показывает,
является ли
передаваемый
кадр кадром
данных или
кадром
удаленного
запроса
данных
3.3.
Кадр ошибки
(ERROR FRAME)
Состоит
из двух
различных
полей.
Первое поле
является
суперпозицией
флагов
ошибки
различных
узлов,
второе поле —
поле
разделителя
ошибки.
Для
корректного
завершения
кадра
ошибки, узлу
в состоянии
«пассивной
ошибки»
может быть
необходим
доступ к
шине,
поэтому
шина должна
быть
свободной,
по крайней
мере, три
времени
передачи
бита.
Следовательно,
шина не
должна быть
загружена
на 100%.
Флаг
ошибки (Error Flag):
Существует
2 формы флага
ошибки:
активный и
пассивный
флаг ошибки.
1.
активный
флаг ошибки
состоит из 6
последовательных
бит с лог. «0».
2.
пассивный
флаг ошибки
состоит из 6
последовательных
бит с лог. «1,
если они не
перезаписаны
битами с лог.
«0» других
узлов.
Узел в
состоянии «активной
ошибки» при
обнаружении
ошибки
передает
активный
флаг ошибки.
Форма флага
ошибки
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока»).
Вследствие
этого все
узлы
обнаруживают
условие
ошибки и
начинают
передавать
флаг ошибки.
В
результате,
последовательность
бит с лог. «0»,
контролируемая
на шине
является
суперпозицией
флагов
ошибок
отдельных
узлов. Общая
длина этой
последовательности
— от 6 до 12 бит с
лог. «0».
Узел в
состоянии «пассивной
ошибки» при
обнаружении
ошибки
передает
пассивный
флаг ошибки,
он ждет
последовательности
из 6
одинаковых
бит,
определяющих
начало
флага
пассивной
ошибки.
Когда эта
последовательность
будет
обнаружена,
флаг
пассивной
ошибки
будет
завершен.
Разделитель
ошибки (Error Delimiter)
Разделитель
ошибки
состоит из 8
бит с лог. «1».
После
передачи
флага
ошибки
каждый узел
посылает
биты с лог. «1»
и
контролирует
шину, пока не
обнаружит
бит с лог. «1».
Впоследствии
он начинает
передавать 7
бит с лог. «1».
3.4.
Кадр
перегрузки
(OVERLOAD FRAME)
Кадр
перегрузки
содержит
два битовых
поля: флаг
перегрузки
и
разделитель
перегрузки.
Имеются
два вида
перегрузки,
которые оба
приводят к
передаче
кадра
перегрузки.
1.
Внутреннее
состояние
приёмника,
которое
требует
задержки
следующего
кадра
данных или
кадра
удаленного
запроса
данных.
2.
Обнаружение
бита с лог. «0»
в течение
поля
перерыва (см.
межкадровое
пространство).
Передача
кадра
перегрузки
из-за
состояния 1
возможна
только в
первом
битовом
интервале
перерыва, в
то время как
кадры
перегрузки
по
состоянию 2
начинают
передаваться
на
следующем
битовом
интервале
после
обнаружения
бита с лог. «0».
Для больших
задержек
может быть
послано
несколько
кадров
перегрузки.
Флаг
перегрузки
(Overload flag)
Состоит
из 6 бит с лог.
«0». Формат
соответствует
активному
флагу
ошибки.
Форма флага
перегрузки
нарушает
фиксированную
форму поля
перерыва.
Поэтому,
другие узлы
также
обнаруживают
состояние
перегрузки
и в свою
очередь
начинают
передавать
флаг
перегрузки.
В случае
обнаружения
бита с лог. «0»
в течение
третьего
бита
перерыва,
некоторые
узлы не
будут
корректно
интерпретировать
флаг
перегрузки,
первый (из
шести) бит с
лог. «0» будет
принят за
поле «начало
кадра».
Шестой бит
флага
перегрузки
с лог. «0»
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока
методом
разрядного
заполнения»).
Разделитель
перегрузки
(Overload Delimiter)
Состоит
из 8 бит с лог.
«1».
Разделитель
перегрузки
имеет такую
же форму, как
и
разделитель
ошибки.
После
передачи
флага
перегрузки
узел
контролирует
шину, пока не
обнаружит
бит с лог. «1».
В этой точке
времени все
узлы уже
закончили
передавать
флаг
перегрузки
и начинают
передавать 7
бит с лог. «1».
4.
Межкадровое
пространство
(INTERFRAME SPACE)
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
любого типа (кадра
данных,
кадра
удаленного
запроса
данных,
кадра
ошибки,
кадра
перегрузки).
Это
разделяющее
битовое
поле
называется
межкадровым
пространством.
Кадрам
перегрузки
и кадрам
ошибки не
предшествует
межкадровое
пространство;
несколько
кадров
перегрузки
также не
отделяются
межкадровым
пространством.
Межкадровое
пространство
содержит
поля «перерыв»
и «простой
шины», и для
узла в
состоянии «пассивной
ошибки»,
который был
передатчиком
предыдущего
сообщения,
дополнительное
поле — «приостановка
передачи» (поле
«приостановка
передачи»
находится
между
полями «перерыв»
и «простой
шины»).
Поле
перерыва (Intermission)
Состоит
из 3 бит с лог.
«1». В течение
перерыва
никакому
узлу нельзя
начинать
передачу
кадра
данных или
кадра
удаленного
запроса
данных.
Единственно
возможное
действие —
это
сигнализация
состояния
перегрузки.
Простой
шины (Bus Idle)
Простой
шины может
иметь
произвольную
длину. Если
шина
опознана
как
свободная,
любой узел,
который
имеет что —
либо для
передачи
может
начать
передачу.
Сообщение,
которое
было
задержано
для
передачи
другого
сообщения,
начинает
передаваться
в первом
бите после
поля
перерыва.
Обнаружение
бита с лог. «0»
на шине в
течение
этого поля
интерпретируется
как поле «начало
кадра».
Приостановка
передачи
Узел
в состоянии
«пассивной
ошибки»,
после
передачи
сообщения,
посылает 8
бит с лог. «1»
после поля
перерыва,
перед
началом
передачи
дальнейших
сообщений
или
определением
занятости
шины. Если
тем
временем
началась
передача (вызванная
другим
узлом), узел
станет
приёмником
этого
сообщения.
5.
Определение
передатчика
/ приемника
Передатчик
Узел,
передающий
сообщение
называется
передатчиком
этого
сообщения.
Узел
является
передатчиком
до тех пор,
пока он не
потерял
арбитраж.
Приёмник
Узел
называется
приёмником
сообщения,
если он не
передатчик
сообщения и
шина занята.
6.
Корректность
сообщения
Точка
времени, в
которой
сообщение
является
корректным,
различна
для
передатчиков
и
приёмников
сообщений.
Передатчик
Сообщения
пригодно
для
передатчика,
если нет
ошибок до
конца кадра.
Если
сообщение
разрушено,
ретрансляция
будет
происходить
автоматически
и согласно
приоритетам.
Чтобы
решить
приоритеты
доступа к
шине с
другими
сообщениями,
ретрансляция
должна
начаться,
как только
шина
освободится.
Приёмник
Сообщение
корректно
для
приёмника,
если нет
ошибок до
конца кадра.
7.
Кодирование
битового
потока
Следующие
поля: «начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных» и «поле
CRC»
кодированы
методом
разрядного
заполнения.
Всякий раз,
когда
передатчик
передает
пять
последовательных
бит
идентичной
величины в
битовом
потоке, он
автоматически
вставляет
дополняющий
бит
противоположного
значения в
фактически
передаваемый
битовый
поток.
Оставшиеся
битовые
поля кадра
данных или
кадра
удаленного
запроса
данных («разделитель
CRC», «поле
подтверждения»
и «конец
кадра»)
имеют
фиксированную
форму и не
кодируются.
Кадр ошибки
и кадр
перегрузки
также имеют
фиксированную
длину и не
кодируются
методом
разрядного
заполнения.
8.
Обработка
ошибок
Существует
пять типов
не
взаимоисключающих
ошибок:
- разрядная
ошибкаУзел,
который
посылает
что — либо на
шину также
контролирует
шину.
Разрядная
ошибка
может быть
обнаружена
во время
передачи
бита, если
переданное
значение
отличается
от
значения,
прочитанного
с шины.
Исключение:
При
посылке
бита с лог.
«1» в
течение
поля
арбитража
или
области
подтверждения
разрядная
ошибка не
возникает,
если
контролируется
бит с лог. «0».
Передатчик,
посылающий
флаг
пассивной
ошибки и
обнаруживший
бит с лог. «0»
не
интерпретирует
его как
разрядную
ошибку. - ошибка
заполненияОшибка
заполнения
обнаруживается
во время
приема
последовательности
из шести
бит
одинакового
разрядного
уровня в
поле
сообщения,
которое
должно
быть
кодировано
методом
разрядного
заполнения. - ошибка CRC
Последовательность
CRC состоит из
результата
вычисленного
передатчиком.
Приёмники
вычисляют CRC
таким же
образом,
как и
передатчик.
Ошибка CRC
обнаруживается
при
несовпадении
расчетного
результата
CRC —
последовательности
в
приёмнике
и
присланной
CRC —
последовательности
передатчика. - ошибка
форматаОшибка
формата
обнаруживается,
когда
разрядное
поле
фиксированного
формата
содержит
один или
несколько
лишних бит. - ошибка
подтвержденияОшибка
подтверждения
обнаруживается
передатчиком
всякий раз,
когда нет
контроля
бита с лог.
«0» в
течение
области
подтверждения.9.
Сигнализация
ошибокУзел,
обнаруживший
состояние
ошибки
сигнализирует
об этом
передачей
флага
ошибки. Для
узла в
состоянии «активной
ошибки» это
передача
флага
активной
ошибки, для
узла в
состоянии «пассивной
ошибки» это
передача
флага
пассивной
ошибки.
Всякий раз
при
обнаружении
разрядной
ошибки,
ошибки
заполнения,
ошибки
формата и
ошибки
подтверждения
узел
начинает
передавать
флаг
ошибки в
следующем
бите.
Всякий раз,
когда
обнаружена
ошибка CRC,
передача
флага
ошибки
будет
начата
после
разделителя
подтверждения,
если не
была
начата
передача
флага
ошибки для
другого
состояния.10.
Типизация
ошибокУзел
может быть
в одном из
трех
состояний: - активной
ошибки - пассивной
ошибки - отключения
от шины
В
состоянии «активной
ошибки»
узел может
взаимодействовать
с шиной,
посылая
флаг
активной
ошибки при
обнаружении
ошибки. В
состоянии «пассивной
ошибки»
узел не
должен
слать флаг
активной
ошибки. Он
принимает
участие во
взаимодействии
с шиной, но
при
обнаружении
ошибки
должен
послать
флаг
пассивной
ошибки.
После
передачи
сообщения
об ошибке,
узел в
состоянии «пассивной
ошибки»
будет ждать
инициализации
дальнейшей
передачи (см.
приостановка
передачи).
В состоянии
отключения
от шины узлу
не
разрешено
оказывать
влияние на
шину.
Для
типизации
ошибок у
каждого
узла — CAN есть
два
счетчика:
1.
счетчик
ошибок
передачи
2.
счетчик
ошибок
приема
(Прим.
переводчика:
Правила
модификации
счетчиков
здесь не
приводятся.
Но хочется
обратить
внимание на
то, что при
наличии
ошибок,
счетчики
увеличиваются
быстрей, чем
уменьшаются
при приемах
или
передачах
без ошибок).
Узел
находится в
состоянии «пассивной
ошибки»,
если
счетчик
ошибок
передачи и /
или счетчик
ошибок
приема
больше или
равен 128.
Узел
отключается
от шины, если
счетчик
ошибок
передачи
или приема
больше или
равен 256.
Узел,
находившиеся
в состоянии
«пассивной
ошибки»
переходит в
состояние «активной
ошибки»,
если
счетчик
ошибок
передачи и
счетчик
ошибок
приема
меньше или
равен 127.
Узлу,
который
находится в
состоянии «отключения
от шины»,
разрешается
перейти в
состояние «активной
ошибки», с
установкой
обоих
счетчиков в 0,
после того,
как на шине
будут
проконтролированы
128
прохождений
11
последовательных
битов с лог.
«1».
Обратите
внимание:
1.
Величина
счетчика
ошибки
большая, чем
96 указывает
на
серьезные
нарушения
на шине. Это
можно
использовать
для
проверки
состояния
шины.
2. Запуск /
Пробуждение:
Если в
некоторый
момент
времени
активен
только один
узел, и если
этот узел
передает
некоторое
сообщение,
он не
получит
подтверждения,
обнаруживается
ошибка и
происходит
повтор
сообщения.
Из-за этого
он может
перейти в
состояние «пассивной
ошибки», но
не может
перейти в
состояние «отключения
от шины».
10.
Требования
к
синхронизации
Номинальная
скорость
передачи
информации
в битах
Номинальная
скорость
передачи
информации
в битах —
число битов
за секунду,
передаваемое
в
отсутствии
пересинхронизации
идеальным
передатчиком.
Номинальное
время
передачи
бита
номинальное
время
передачи
бита = 1 /
номинальную
скорость
передачи
информации
Номинальное
время
передачи
бита можно
представить
как время,
разделенное
на
отдельные
не
перекрывающиеся
сегменты
времени. Это
сегменты:
—
Сегмент
синхронизации
(SYNC_SEG)
—
Сегмент
времени
распространения
(PROP_SEG)
—
Сегмент TSEG1 (PHASE_SEG1)
—
Сегмент TSEG2 (PHASE_SEG2)
SYNC SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
синхронизировать
различные
узлы на шине.
Ожидается,
что фронт
сигнала
находится
внутри
этого
сегмента.
PROP SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
компенсировать
физическую
задержку
времён
внутри сети.
Это
удвоенная
сумма
времени
распространения
сигнала по
шине,
входной
задержки
компаратора,
и выходной
задержки
формирователей.
TSEG1 и TSEG2.
Эти
сегменты
используются,
чтобы
компенсировать
ошибки
смещения
фазы
сигнала. Эти
сегменты
могут быть
удлинены
или
укорочены
пересинхронизацией.
Точка
считывания
(Sample point)
Точка
считывания —
точка
времени, в
которой
уровень
шины
читается и
интерпретируется,
как
величина
соответствующего
бита. Ее
место — в
конце TSEG1.
Время
обработки
информации
Время
обработки
информации —
отрезок
времени,
начинающийся
с точки
считывания,
зарезервированный
для
вычисления
уровня бита.
Квант
времени
Квант
времени —
фиксированная
единица
времени,
полученная
из периода
генератора.
Существует
программируемый
делитель,
оперирующий
целочисленными
величинами,
изменяющимися,
по крайней
мере, от 1 до 32.
Начиная с
минимального
кванта
времени,
квант
времени
может иметь
длительность:
квант
времени = m *
минимальный
квант
времени ,где m
— величина
делителя.
минимальный
квант
времени = 1 / f
генератора.
Длительность
отрезков
времени
- SYNC_SEG — 1 квант
времени . - PROP_SEG —
программируем,
1,2, …, 8 квантов. - TSEG1 —
программируем,
1,2, …, 8 квантов. - TSEG2 — максимум
из TSEG1 и
времени
обработки
информации - время
обработки
информации
— меньше или
равно 2
квантам.
12.
Синхронизация
Аппаратная
синхронизация
После
аппаратной
синхронизации
внутреннее
время
передачи
бита
перезапускается
с SYNC_SEG. Таким
образом,
аппаратная
синхронизация
вынуждает
фронт
находиться
внутри
сегмента SYNC_SEG.
Ширина
перехода
пересинхронизации
В
результате
пересинхронизации
TSEG1 может быть
удлинен, или
TSEG2 может быть
сокращен.
Количество
удлинения
или
сокращения
сегментов TSEGx
(x=1,2) имеет
верхний
предел,
связанный с
шириной
перехода
пересинхронизации.
Ширина
перехода
пересинхронизации
должна быть
программируема
между 1 и min(4, TSEG1).
Синхронизация
информации
может быть
получена из
переходов
от одного
бита к
другому.
Максимальная
длина между
двумя
переходами,
которые
могут
использоваться
для
пересинхронизации
— 29 времен
передачи
бита.
Фазовая
ошибка
фронта
Фазовая
ошибка
фронта
определяется
позицией
фронта
относительно
SYNC_SEG,
измеряется
в квантах
времени.
Знак
фазовой
ошибки
определяется
следующим
образом:
- e = 0, если
фронт
сигнала
находится
внутри SYNC_SEG. - e> 0, если
фронт
сигнала
перед
точкой
считывания. - e < 0, если
фронт
сигнала
после
точки
считывания
предыдущего
бита.
Пересинхронизация
Эффект
пересинхронизации
— также как и
от
аппаратной
синхронизации,
когда
величина
фазовой
ошибки
фронта
сигнала,
которая
вызывает
пересинхронизацию
— меньше или
равна
программируемой
величине
ширины
перехода
пересинхронизации.
Когда
величина
ошибки фазы
больше чем
ширина
перехода
пересинхронизации,
- и если
ошибка
фазы
положительна,
то TSEG1
удлиняется
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации. - и если
ошибка
фазы
отрицательна,
то TSEG2 —
сокращается
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации.
Правила
синхронизации
Синхронизация
и
пересинхронизация
— две формы
синхронизации.
На них
действуют
следующие
правила:
1.
Позволяется
только одна
синхронизация
внутри
одного
интервала
передачи
бита.
2. Для
синхронизации
будет
использоваться
фронт
только, если
величина,
полученная
в
предыдущей
точке
считывания (предыдущая
величина на
шине)
отличается
от величины
на шине
сразу после
фронта.
3.
Синхронизация
выполняется
всякий раз,
по фронту «1»
-> «0» в
течение
простоя
шины.
4. Все
другие
фронты «1» ->
«0» (и фронты
«0» -> «1» в
случае
низких
скоростей),
выполняемые
по правилам 1
и 2, будут
использоваться
для
пересинхронизации.
|
CAN 2.0 В |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. CAN — Область Задача
Обратите Область
Область Внутри 2.
Послойная
Сообщения Информация Информационная В Гибкость Маршрутизация Групповая Непротиворечивость Скорость Скорость Приоритеты Идентификатор Удаленный Посылая Multimaster Когда Арбитраж Всякий Безопасность Для Обнаружение Для Эффективность Сигнализация Искаженные Типизация Узлы Подключение Последовательная Канал Шина Уровни Шина Подтверждение Все Режим Для Генератор Требования 3. Форматы
Типы Кадр Кадр Кадр
Начало Начало Поле Формат
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Идентификатор Идентификатор Идентификатор Base ID Base ID Extended ID Extended ID Бит Бит Бит Заменитель Бит Бит Поле Поле
Код Число |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Допустимое Поле Поле Поле Последовательность Последовательность Последовательность Поле Поле Область Все Разделитель Разделитель Конец Каждый Кадр Узел, Кадр Кадр
Для Флаг Имеются Разделитель Разделитель Кадр Кадр Флаг Состоит Замечание: Разделитель Состоит Межкадровое Кадры Межкадровое
Перерыв Состоит Замечание: Если Простой Период Приостановка После Стандартный Стандартный Определение Передатчик: Приемник: 4. Фильтрация Если 5. Момент Передатчик: Приемник: 6. Кодирование 7. Обнаружение
Передача Узел, Всякий Всякий 8. Неисправный
Узел в Для Замечание: Замечание: 9. Для Замечание: 10. Номинальная Номинальная номинальное Номинальное
Сегмент Используется Сегмент Используется, Сегменты Эти Точка Момент Время Время Шаг Шаг шаг Длительность
Общее 11. После Переход В Перехода Ошибка Ошибка
12. Эффект
Правила Аппаратная |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN OSI модель
|
| CANopen | DeviceNet | SDS (V2.0) | |
| Name of Communication Object | Process Data Object | I/O-Message | Multicast Channel APDU |
| Maximal Number of Communication Objects per Device | 512 Transmit PDOs 512 Receive PDOs | 27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to |
32 Embedded Objects per device |
| Maximal length of Data Field | 8 bytes | 8 bytes fragmented: Arbitrary length | 6 bytes fragmented: 64 * 4 bytes |
| Protocol | Unfragmented: No overhead, Notify/Read «Stored-Event»-protocol (CAL/CMS) Unacknowledged |
Unfragmented: No overhead, three «Transport Classes» supported:
|
Unfragmented: 2 byte protocol overhead, Unacknowledged |
| Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame |
Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment |
||
| Message Production Triggering Modes |
|
|
Specified by object model |
| Mapping of Application Objects | Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of «Mapping Parameter Record» (configurable) Dynamic mapping supported |
Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported |
Network Data Descriptor defines size, granularity and data type of I/O data of Embedded |
Вызов (triggering)
сообщений
Все
рассматриваемые
протоколы
поддерживают
различные
способы
вызова
сообщений.
DeviceNet
поддерживает
циклический
(Cyclic), по
состоянию
(Change-of-State) и
программный
(Application) способы
вызова.
Циклический
вызов
осуществляется
по
истечению
времени
таймера и
начинается
передача
сообщения.
Передача
по
состоянию
начинается,
когда
статус
определенного
объекта
изменяется.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени, в
котором не
осуществлялась
передача
сообщения.
Программным
способом
сам объект
решает,
когда
начать
передачу
сообщения.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени
без
передачи
сообщения.
Установление
соответствий
(mapping) для
программных
объектов
Сетевые
устройства
обычно
содержат
более
одного
программного
объекта и
передача I/O
сообщения
более чем
одному
программному
объекту
внутри
одного PDO
является
необходимым
требованием.
В DeviceNet
объединение
прикладных
данных
осуществляется
посредством
трансляционных
(assembly) объектов,
которые
определяют
формат
передаваемых
данных.
Устройство
может
содержать
более
одного I/O
трансляционного
объекта и
выбор
подходящего
(consumed/ produced_connection_path)
может быть
настраиваемой
опцией
устройства.
Прямые
(peer-to-peer)
коммуникационные
каналы
Для
конфигурации
устройств
посредством
конфигурационных
средств
требуются
специальные
функции у
устройств
или
программы,
обеспечивающие
многоцелевые
каналы
связи. Это
не
критичные
по времени
каналы
связи.
Передача
данных в
них
осуществляется
посредством
протокола
с
подтверждениями
и
фрагментацией.
Любой из
протоколов
высокого
уровня,
которые
поддерживают
некоторую
конфигурацию
устройств,
должны
обеспечивать
этот вид
связи.
DeviceNet
обеспечивает
многоцелевые
устройство
ориентированные
каналы и
сервисы.
Запись и
чтение
атрибутов
объектов,
контролирование
объектов (reset,
start, stop etc.),
сохранение/восстановление
атрибутов
объектов
осуществляется
посредством
явных (Explicit)
сообщений.
Намерение
использовать
данное
сообщение
определяется
в поле
данных CANа.
На рис. 7
показан
формат
поля
данных
фрагментированного
Explicit
сообщения.
В запросе
сервиса
указывается
номер
класса,
номер
экземпляра(instance),
номер
атрибута (в
поле Service specific arguments).
Рис. 6. DeviceNet Fragemented
Explicit Message Data Field Format (Request/Response)
Explicit(прямая)
связь
устанавливается
посредством
менеджера
сообщений
(Unconnected Message Manager (UCMM)). UCMM
предоставляет
два
сервиса
для
открывания
и
закрывания
подобных
соединений.
Каждое
устройство,
поддерживающее
UCMM,
резервирует
у себя
идентификаторы
сообщений
для
запросов и
ответов
для UCMM. Для
устройств 2-й
группы,
которые не
поддерживают
UCMM порт, master
устройство
сперва
должно
разместить
Explicit
соединение
в
предопределенном
множестве
соединений.
Запрос к
устройству
группы 2
передается
как Explicit
запрос без
предварительного
установления
соединения
(Unconnected Explicit Request ) с
зарезервированным
идентификатором
сообщения.
Сравнительные
характеристики
протоколов
CANopen, DeviceNet и SDS в
отношении
прямых (peer-to-peer)
коммуникационных
каналов
представлены
в таблице 2.
Таблица
2. Main Characteristics of Peer-to-Peer Communication Channels
| CANopen | DeviceNet | SDS (V2.0) | |
| Name | Service Data Channel | Explicit Message | Peer-to-peer Channel |
| Maximum number of channels | 128 Client SDOs, 128 Server SDOs per device | 27 Explicit Transmit Messages 1701 Explicit Receive messages per device |
4 channels per Embedded Object. 32 Embedded Objects per Logical Device |
| Protocol | < 5 byte: Acknowledged unfragmented 4 byte: Fragmented transmission (7 bytes per fragment) Each frame acknowledged Any length (CAL Multiplexed Domain protocol) |
< 7 byte: Acknowledged unfragmented 6 byte: Fragmented transmission. (6 bytes per fragment) Each frame acknowledged Any length |
< 6 bytes Acknowledged unfragmented 5 byte Fragmented transmission (3 bytes per fragment) Acknowledgement of complete data block. Max. 255 byte |
| Establishing of Connections |
|
|
|
| Connection Services and Arguments | Initiate, Abort Upload/Download Segment/Domain | Open/Close Creation, Configuration, Start, Stop, Reset etc. of Objects |
Open/Close Read, Write, Event, Action |
| Index and Subindex of addressed | Object Directory Entry Object attribute access path, Service arguments |
Channel Number, Attribute/Action/Event Identifier |
Установление
связей для
обмена
данных
процесса
Распределение
идентификаторов
для
передаваемых
сообщений
и ,
соответственно,
получаемых
сообщений
устанавливает
коммуникационные
пути в CAN
сети.
Установление
взаимодействия
возможно
через
использование
предопределенного
множества
сообщений
с уже
размещенными
идентификаторами
сообщений
или через
переменное
распределение
идентификаторов
для
сообщений.
В
системе с
предопределенным
множеством
сообщений
«функции»
и
идентификаторы
сообщений
уже
определены.
DeviceNet также
использует
предопределенное
множество
сообщений
для
системы со
структурой
1:n. Master
устройство,
предварительно
разместив
у себя
множество
связей со Slave
устройствами,
«знает» ID
сообщений
для
передачи
запроса и ID
сообщений
для
получения
ответа,
который
включает Slave
MAC-ID в
соответствии
с
предопределенным
множеством
связей.
Также
возможно
не
предопределять
идентификаторы
сообщений.
Сетевое
управление
Так
как в CAN-сети
мы имеем
дело с
распределенными
приложениями,
должны
отслеживаться
определенные
события(отказы
различных
частей
приложения
или отказ
устройств).
Поэтому
главными
задачами
сетевого
управления
становятся
обнаружение
и вывод
ошибок в
сети и
предоставление
сервисов,
позволяющих
контролировать
статусы
устройств
и вести
координацию
устройств.
В
зависимости
от
системных
решений
сетевое
управление
может
вестись
явным или
косвенным
путем.
В DeviceNet
каждое
соединение
контролируется.
Поэтому
каждая
ожидающая
сообщение
конечная
точка
имеет «Inactivity/Watchdog»
таймер,
чтобы
контролировать
прибытие
сообщения
согласно
предопределенному
времени
ожидания.
Если время
истекает,
соединение
выполняет
действие
«Timeout». На рис. 7
показана
диаграмма
изменения
состояний
у объекта I/O.
Рис. 7. Device Net I/O
Connection Object State Transition Diagram
После
получения
вызова CREAT ( Explicit
сообщение)
соединение
настраивается
при помощи
подходящей
последовательности
вызовов
явных
сообщений
и после
этого
устанавливается.
Перед
получением
доступа к
сети
каждое
устройство
должно
совершить
проверку
на
дубликат
своего MAC-ID.
Определенные
алгоритмы
выбора
гарантируют
уникальность
MAC-ID.
Контроль
может
осуществляться
также
посредством
Heartbeat
сообщения,
которое
может
посылаться
устройствам
посредством
UCMM в форме
сообщения.
В поле
данных
этого
сообщения
передается
состояние
устройства.
Heartbeat
сообщение
вызывается
объектом Idendity.
Профайлы
устройств
Для
открытых
автоматических
систем
помимо
обеспечения
связи от
входящих в
их состав
устройств
требуется
также
обеспечение
возможности
взаимодействия
и
взаимозаменяемости.
Поэтому
протоколы
высокого
уровня (такие
как DeviceNet)
описывают
функциональные
возможности
устройств
в виде
модели
устройства
(«Device Model»).
Помимо
описания
функциональности
устройств
модель
устройства
должна
также
содержать
ряд важных
параметров
(статус,
диагностическую
информацию,
коммуникационные
возможности,
конфигурационные
параметры
и т.д.). На рис. 8
показана
модель
устройства
DeviceNet.
Рис. 8. DeviceNet Object Model
DeviceNet
профайл
должен
содержать
следующую
информацию:
- модель
объекта
для
устройства - формат
данных I/O
для
устройства - конфигурационные
данные и
внешние
интерфейсы
для этих
данных
В
таблице 3
показаны
главные
функции
объектов в
DeviceNet.
Таблица
3. Objects of a DeviceNet node
| Object | Function |
| Connection | Instantiates connections (I/O or Explicit Messaging) |
| DeviceNet | Maintains configuration and status of physical attachments to DeviceNet. |
| Message Router | Routes received Explicit Messages to appropriate target objects |
| Assembly | Groups attributes of multiple objects into a single block of data, which can be sent and received over a single connection |
| Parameter | Provides a standard means for device configuration and attribute access |
| Identity | Provides general information about the identity of a device |
| Application | Supplies application-specific behaviour and data |
Заключение
Протокол
CAN
применяется
в real-time
системах
для
решения
различных
задач. В
настоящий
момент
развиваются
несколько
видов CAN
протоколов
высокого
уровня,
таких как CAL
,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в
основе
которых
лежит
канальный
протокол CAN2.0
(Bosch) , и на
основе
этих
протоколов
можно
решать
проблемы,
возникающие
в real-time
системах,
которые
невозможно
разрешить
при помощи
других
известных
протоколов,
скажем, TCP/IP.
Всех приветствую, сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…
CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.
Основные характеристики протокола CAN:
- очень высокая надежность и защищенность
- каждое сообщение имеет свой собственный приоритет
- реализован механизм обнаружения ошибок
- автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
- уже упомянутый широковещательный характер передачи данных
- возможность присутствия нескольких ведущих (master) устройств в одной сети
- широкий диапазон скоростей работы
- высокая устойчивость интерфейса к помехам
- кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.
Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь. С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».
Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна ) Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:
| Скорость | Длина линии |
|---|---|
| 1 Мбит/с | 50 м |
| 500 кбит/с | 100 м |
| 125 кбит/с | 500 м |
| 10 кбит/с | 5 км |
Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:
В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.
Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» ) Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный.
Вспоминаем про важнейшее свойство передачи данных в сети. Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети:
При использовании электрического сигнала устройство, желающее передать в линию доминантный бит, может подтянуть линию к земле. Это и приведет к тому, что на линии будет доминантный бит независимо от того, что выдают на линию другие участники коммуникации.
Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.
Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде )
Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).
С этим вроде бы разобрались, давайте двигаться дальше! Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:
- Кадр данных (data frame)
- Кадр удаленного запроса (remote frame)
- Кадр перегрузки (overload frame)
- Кадр ошибки (error frame)
Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор (ID) | 11 бит | Идентификатор сообщения |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для базового формата — доминантный бит |
| Зарезервированный бит | 1 бит | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
А это структура расширенного:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор A (ID A) | 11 бит | Первая часть идентификатора |
| Подмена запроса на передачу (SRR) | 1 бит | Рецессивный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для расширенного формата — рецессивный бит |
| Идентификатор B (ID B) | 18 бит | Вторая часть идентификатора |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Зарезервированные биты | 2 бита | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.
Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.
Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.
Кадр перегрузки (overload frame) используется очень редко. Его идея и назначение заключаются в том, что с его помощью устройство, которое в данный момент не может принять данные, запрашивает повторную передачу этих же данных.
Давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике. Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет. Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.
Первые два типа кадров — кадр данных и кадр удаленного запроса — отделяются от других кадров специальным межкадровым промежутком (паузой). А для фреймов ошибки и перегрузки предусмотрена передача без пауз, чтобы обеспечить их скорейшую обработку узлами сети.
Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN. Стандарт предусматривает несколько механизмов:
- Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
- Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
- Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
- Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.
Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 👍
Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.
И на этом еще не все! Каждый узел может находиться в одном из трех состояний:
- Error Active
- Error Passive
- Bus Off
Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:
- Счетчик ошибок передачи
- Счетчик ошибок приема
Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.
Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.
Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:
- Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
- Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
- И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, ни какие-либо другие.
Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании. И на этой позитивной ноте на сегодня заканчиваем, скоро займемся практической реализацией протокола, также поговорим о микросхемах и устройствах, обеспечивающих работу с CAN. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте 🤝
27 октября 2020
По материалам компании Kvaser
Эта статья не претендует на полноту и абсолютную точность сведений, указанных в ней, и предназначена для ознакомления с протоколом CAN.
Содержание статьи
• Шина CAN – Введение.
• Сообщения CAN.
• Физические уровни CAN.
• Разъемы CAN.
• Тактовая синхронизация CAN.
• Обработка ошибок CAN.
Шина CAN – Введение
Протокол CAN является стандартом ISO (ISO 11898) в области последовательной передачи данных. Протокол был разработан с прицелом на использование в транспортных приложениях. Сегодня CAN получил широкое распространение и используется в системах автоматизации промышленного производства, а также на транспорте.
Стандарт CAN состоит из физического уровня и уровня передачи данных, определяющего несколько различных типов сообщений, правила разрешения конфликтов при доступе к шине и защиту от сбоев.
Протокол CAN
Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:
• физический уровень использует дифференциальную передачу данных по витой паре;
• для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;
• сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;
• в сообщениях отсутствуют явные адреса, вместо этого каждое сообщение содержит числовое значение, которое управляет его очередностью на шине, а также может служить идентификатором содержимого сообщения;
• продуманная схема обработки ошибок, обеспечивающая повторную передачу сообщений, если они не были получены должным образом;
• имеются эффективные средства для изоляции сбоев и удаления сбойных узлов с шины.
Протоколы более высоких уровней
Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.
Протоколы более высокого уровня используются для:
• стандартизации процедуры запуска, включая выбор скорости передачи данных;
• распределения адресов среди взаимодействующих узлов или типов сообщений;
• определения разметки сообщений;
• обеспечения порядка обработки ошибок на уровне системы.
Пользовательские группы и т.п.
Одним из наиболее эффективных способов повышения вашей компетентности в области CAN является участие в работе, осуществляемой в рамках существующих пользовательских групп. Даже если вы не планируете активно участвовать в работе, пользовательские группы могут являться хорошим источником информации. Посещение конференций является ещё одним хорошим способом получения исчерпывающей и точной информации.
• Пользовательские группы и прочее из области CAN >>
Продукты CAN
На низком уровне принципиально различают два типа продуктов CAN, доступных на открытом рынке – микросхемы CAN и инструменты разработки CAN. На более высоком уровне – другие два типа продуктов: модули CAN и инструменты проектирования CAN. Широкий спектр данных продуктов доступен на открытом рынке в настоящее время.
• Ознакомьтесь с нашим перечнем продуктов CAN >>
Патенты в области CAN
Патенты, относящиеся к приложениям CAN, могут быть различных типов: реализация синхронизации и частот, передача больших наборов данных (в протоколе CAN используются кадры данных длиной всего лишь 8 байт) и т.п.
Системы распределённого управления
Протокол CAN является хорошей основой для разработки систем распределённого управления. Метод разрешения конфликтов, используемый CAN, обеспечивает то, что каждый узел CAN будет взаимодействовать с теми сообщениями, которые относятся к данному узлу.
Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.
Сообщения CAN
Шина CAN относится к широковещательным шинам. Это означает, что все узлы могут «слушать» все передачи. Не существует возможности послать сообщение конкретному узлу, все без исключения узлы будут принимать все сообщения. Оборудование CAN, однако, обеспечивает возможность локальной фильтрации, так что каждый модуль может реагировать только на интересующее его сообщение.
Адресация сообщений CAN
CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.
Типы сообщений
Существует 4 типа сообщений (или кадров), передающихся по шине CAN:
• кадр данных (Data Frame);
• удаленный кадр (Remote Frame);
• кадр ошибки (Error Frame);
• кадр перегрузки (Overload Frame).
Кадр данных
Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):
• Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:
• В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.
• В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.
• Поле данных (Data Field), которое содержит от 0 до 8 байт данных.
• Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.
• Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.
Примечание 1: Присутствие на шине бита распознавания не значит ничего, кроме того, что каждый запланированный адресат получил сообщение. Единственное, что становится известно, это факт корректного получения сообщения одним или несколькими узлами шины.
Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.
Кадр данных CAN 2.0B («cтандартный CAN»).
Кадр данных CAN 2.0B («расширенный CAN»).
Удаленный кадр
Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:
• он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и
• отсутствует поле данных.
Основной задачей удаленного кадра является запрос на передачу надлежащего кадра данных. Если, скажем, узел A пересылает удаленный кадр с параметром поля арбитража равным 234, то узел B, если он должным образом инициализирован, должен выслать в ответ кадр данных с параметром поля арбитража также равным 234.
Удаленные кадры можно использовать для реализации управления трафиком шины типа «запрос–ответ». На практике, однако, удаленный кадр используется мало. Это не так важно, поскольку стандарт CAN не предписывает действовать именно так, как здесь обозначено. Большинство контроллеров CAN можно запрограммировать так, что они будут автоматически отвечать на удаленный кадр, или же вместо этого извещать локальный процессор.
Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.
Иногда требуется чтобы узел, отвечающий на удаленный кадр, начинал свою передачу как только распознавал идентификатор, таким образом «заполняя» пустой удаленный кадр. Это другой случай.
Кадр ошибки (Error Frame)
Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.
Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.
Вот флаг ошибки:
Кадр перегрузки (Overload Frame)
Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.
Стандартный и расширенный CAN
Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.
Формально стандарты именуются следующим образом –
• 2.0A – только с 11–битными идентификаторами;
• 2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть
• 2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или
• 2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).
• 1.x – относится к оргинальной спецификации и её ревизиям.
В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.
Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.
Иногда люди заявляют, что стандартный CAN «лучше» расширенного CAN, потому что в сообщениях расширенного CAN больше служебных данных. Это необязательно так. Если вы используете поле арбитража для передачи данных, то кадр расширенного CAN может содержать меньше служебных данных, чем кадр стандартного CAN.
Основной CAN (Basic CAN) и полный CAN (Full CAN)
Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.
В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.
Разрешение конфликтов на шине и приоритет сообщения
Разрешение конфликтов сообщений (процесс, в результате которого два или более контроллера CAN решают, кто будет пользоваться шиной) очень важно для определения реальной доступности полосы пропускания для передачи данных.
Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.
Важным условием для благополучного разрешения конфликта является невозможность ситуации, при которой два узла могут передать одинаковое поле арбитража. Из этого правила есть одно исключение: если сообщение не содержит данных, то любой узел может передавать это сообщение.
Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.
Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?
Ответ: Узел, разумеется, выиграет в разрешении конфликта и успешно проведет передачу сообщения. Но когда наступит время распознавания… ни один узел не отправит доминантный бит области распознавания, поэтому передатчик определит ошибку распознавания, пошлет флаг ошибки, повысит значение своего счетчика ошибок передачи на 8 и начнет повторную передачу. Этот цикл повторится 16 раз, затем передатчик перейдет в статус пассивной ошибки. В соответствии со специальным правилом в алгоритме ограничения ошибок, значение счетчика ошибок передачи не будет более повышаться, если узел имеет статус пассивной ошибки и ошибка является ошибкой распознавания. Поэтому узел будет осуществлять передачу вечно, до тех пор, пока кто–нибудь не распознает сообщение.
Адресация и идентификация сообщения
Повторимся, нет ничего страшного в том, что в сообщениях CAN нет точных адресов. Каждый контроллер CAN будет получать весь траффик шины, и при помощи комбинации аппаратных фильтров и ПО, определять – «интересует» его это сообщение, или нет.
Фактически, в протоколе CAN отсутствует понятие адреса сообщения. Вместо этого содержимое сообщения определяется идентификатором, который находится где–то в сообщении. Сообщения CAN можно назвать «контентно–адрессовнными».
Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.
Содержимое поле арбитража используется, в соответствии со стандартом, для определения очередности сообщения на шине. Все контроллеры CAN будут также использовать всё (некоторые – только часть) поле арбитража в качестве ключа в процессе аппаратной фильтрации.
Стандарт не говорит, что поле арбитража непременно должно использоваться в качестве идентификатора сообщения. Тем не менее, это очень распространенный вариант использования.
Примечание о значениях идентификатора
Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.
Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.
Физические уровни CAN
Шина CAN
Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.
Различные физические уровни
Физический уровень определяет электрические уровни и схему передачи сигналов по шине, полное сопротивление кабеля и т.п.
Существует несколько различных версий физических уровней: • Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.
• Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.
• SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.
• Существуют несколько проприетарных физических уровней.
• В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.
• Несколько изображений с осциллографа поясняющие сообщения в деталях >>.
Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.
Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.
Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.
Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.
Максимальная скорость передачи данных по шине
Максимальная скорость передачи данных по шине CAN, в соответствии со стандартом, равна 1 Мбит/с. Однако некоторые контроллеры CAN поддерживают скорости выше 1 Мбит/с и могут быть использованы в специализированных приложениях.
Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.
Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.
Минимальная скорость передачи данных по шине
Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.
Максимальная длина кабеля
При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.
Другие максимальные длины кабеля (значения приблизительные):
• 100 метров при 500 кбит/с;
• 200 метров при 250 кбит/с;
• 500 метров при 125 кбит/с;
• 6 километров при 10 кбит/с.
Если для обеспечения гальванической изоляции используются оптопары, максимальная длина шины соответственно сокращается. Совет: используйте быстрые оптопары, и смотрите на задержку сигнала в устройстве, а не на максимальную скорость передачи данных в спецификации.
Оконечное прерывание шины
Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:
1. Убрать отражения сигнала на конце шины.
2. Убедиться, что получает корректные уровни постоянного тока (DC).
Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.
Заметьте, что другие физические уровни, такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.
Кабель
Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления [108..132] Ом.
Немногие, из присутствующих сегодня на рынке, кабели удовлетворяют этим требованиям. Есть большая вероятность, что интервал значений сопротивления будет расширен в будущем.
ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.
Продолжение статьи читать во II части .
Один из немаловажных аспектов работы CAN шины является обработка прерываний bxCan. Их не так уж и много, но при правильной их настройке и обработке мы сможем обеспечить максимальную работоспособность и высокую отказоустойчивость нашего устройства. Поэтому следует обратить наше внимание на то, как это сделать правильно — создать необходимый минимум.
Теория
Начнем опять с теории и обратимся к Reference Maanual от ST Microelectronics.
Для начала мы попытаемся разобраться с механизмом прерываний микроконтроллера STM32F103C6, затем пройдемся по регистрам контроллера и, затем, выстроим некий шаблон, который мы сможем использовать в своих проектах.
Прерывания
Для bxCan может быть назначено четыре прерывания. Каждый из источников прерываний может быть включен или выключен независимо друг от друга в регистре CAN_IER (CAN Interrupt Enable Register).
Вот схема отработки прерываний приведенная в мануале:
Рис. 1. Флаги событий и формирование прерываний
Как видим на рисунке 1, прерывания сгруппированы в четыре группы:
• Transmit interrupt (Прерывание при передаче сообщения) — может быть вызвано следующими событиями:
— Выполнена передача и освобожден mailbox 0. Бит RQCP0 в регистре CAN_TSR установлен;
— Выполнена передача и освобожден mailbox 1. Бит RQCP1 в регистре CAN_TSR установлен;
— Выполнена передача и освобожден mailbox 2. Бит RQCP2 в регистре CAN_TSR установлен.
• FIFO0 interrupt (Прерывание связанное с входящим буфером FIFO0) — вызывается по следующим событиям:
— Прием нового сообщения, биты FMP0 в регистре CAN_RF0R не равны «00». В принципе значение этого регистра говорит нем о том, сколько сообщений в буфере FIFO еще не обработано программой;
— Буфер FIFO0 заполнен. Бит FULL0 в регистре CAN_RF0R установлен — сообщает нам о том, что в буфере FIFO0 больше нет свободного места;
— Переполнение буфера FIFO0. Бит FOVR0 в регистре CAN_RF0R установлен — возникает в случае когда буфер FIFO0 заполнен и по шине принято еще одно сообщение. Что с этим сообщением произойдет, мы указываем в настройках инициализации CAN (параметр CAN_RFLM).
• FIFO1 interrupt (Прерывание связанное с входящим буфером FIFO1) — вызывается по следующим событиям:
— Прием нового сообщения, биты FMP1 в регистре CAN_RF1R не равны «00». В принципе значение этого регистра говорит нем о том, сколько сообщений в буфере FIFO еще не обработано программой;
— Буфер FIFO1 заполнен. Бит FULL1 в регистре CAN_RF0R установлен — сообщает нам о том, что в буфере FIFO1 больше нет свободного места;
— Переполнение буфера FIFO1. Бит FOVR1 в регистре CAN_RF0R установлен — возникает в случае когда буфер FIFO1 заполнен и по шине принято еще одно сообщение. Что с этим сообщением произойдет, мы указываем в настройках инициализации CAN (параметр CAN_RFLM).
• Error and Status change Interrupt (Прерывание по возникновению ошибок и изменению состояния bxCAN) — вызывается по следующим событиям:
— Возникновение ошибки. Информация об ошибке хранится в регистре CAN Error (CAN_ESR);
— «Просыпание» контроллера — выход из режима сна, когда на Rx появился сигнал CAN шины;
— Переход в спящий режим.
Четвертая группа отвечает за прерывания не только ошибок, но, как видно из названия, и за изменения статуса (режима) bxCan.
Регистры
Полное описание регистров bxCan я приведу в отдельной статье, здесь же мы коснемся лишь некоторых из них, которые непосредственно рассматриваются в рамках данной статьи.
Для того, чтобы мы смогли программно обработать прерывания bxCan, необходимо изучить регистры микроконтроллера, которые непосредственно связаны с этими прерываниями. Разработчики ST Microelectronix постарались для нас и большинство функционала для работы CAN шины возложили на аппаратную часть микроконтроллера, но все же нам придется выполнить некоторые действия самостоятельно.
За обработку ошибок, включение/выключение прерываний CAN шины, а также за информацию о текущем статусе шины и ошибок в bxCan отвечают шесть регистров, которые мы сейчас и изучим:
CAN master status register (CAN_MSR)
Один из основных регистров bxCAN. Он отображает текущее состояние CAN устройства и позволяет программному обеспечению контролировать более детально работу bxCan.
В большинстве случаев нет необходимости досконально контролировать аппаратную часть, сама bxCan превосходно с этим справляется, но в некоторых случаях будет полезно понимать предоставленные нам возможности и инструменты.
CAN Master Status Register предоставляет нам информацию о том, в каком состоянии находится bxCan и сообщает нам о прерываниях, если они установлены.
Рис. 2. CAN master status register.
Address offset: 0x04
Reset value: 0x0000 0C02
| Биты | Название | Описание |
|---|---|---|
| 31:12 | Зарезервировано | |
| 11 | RX — CAN Rx signal | CAN Rx сигнал. Контролирует фактическое состояние пина CAN_Rx |
| 10 | SAMP — Last sample point | Последнее принятое значение. Значение RX на последней точки выборки (фактически значение последнего принятого бита). |
| 9 | RXM — Receive mode | Режим передачи. Сообщает, что bxCan находится в режиме передачи сообщения. |
| 8 | TXM — Transmit mode | Режим приема. Сообщает, что bxCan находится в режиме приема сообщения. |
| 7:5 | Зарезервировано | |
| 4 | SLAKI — Sleep acknowledge interrupt | Бит прерывания при переходе в спящий режим. Когда SLKI = 1, то этот бит устанавливается аппаратно и сигнализирует о том, что bxCan вошел в режим «спячки». После установки этого бита генерируется прерывание по переходу в спящий режим (если установлен бит SLKIE в регистре CAN_IER). SLAKI может сбрасываться программно или аппаратно, когда сбрасывается бит SLAK. Примечание: когда бит SLKIE = 0, то нельзя выполнить опрос бита SLAKI. В этом случае необходимо читать значение бита SLAK. |
| 3 | WKUI — Wakeup interrupt | Бит прерывания при возврате из «спящего» режима. Этот бит аппаратно устанавливает сигнал о том, что бит SOF был обнаружен, в то время, как bxCan находился в спящем режиме. Установка этого бита генерирует изменение статуса прерывания, если бит WKUIE регистра CAN_IER был установлен. Сбрасывается этот бит с помощью программного обеспечения. |
| 2 | ERRI — Error interrupt | Бит прерывание по ошибке. Этот бит устанавливается аппаратно, когда бит в регистре CAN_ESR был установлен на обнаружение ошибок и при этом включено соответствующее прерывание в регистре CAN_IER. Установка этого бита генерирует прерывание, если установлен бит ERRIE в регистре CAN_IER. Очищается с помощью программного обеспечения. |
| 1 | SLAK — Sleep acknowledge | Режим сна. Этот бит устанавливается аппаратно и указывает на то, что bxCan находится в режиме сна. Этот бит подтверждает запрос о переходе в «спящий» режим из программного обеспечения (установка бита Sleep в регистре CAN_MCR). Сбрасывается аппаратно, когда bxCan переходит в спящий режим (для синхронизации по CAN — шине). Для синхронизации устройств на шине необходимо контролировать последовательность 11-ти рецессивных бит подряд на сигнале CAN_RX. Процесс выхода из сна запускается, когда сбрасывается бит SLEEP в регистре CAN_MCR. Автоматическое пробуждение из режима сна происходит при установке бита AWUM регистра CAN_MCR. |
| 0 | INAK — Initialization acknowledge | Режим инициализации. Этот бит устанавливается аппаратно и указывает программному обеспечению на то, что bxCan находится в режиме инициализации. Этот бит подтверждает запрос инициализации из программного обеспечения (установлен бит INRQ в регистре CAN_MCR). Бит INAK сбрасывается автоматически, когда bxCan выходит из режима инициализации. Для того чтобы синхронизировать устройства с шиной, необходимо контролировать последовательность 11 рецессивных бит подряд на CAN_RX. |
CAN transmit status register (CAN_TSR)
Этот регистр позволяет нам узнать текущее состояние передачи данных в шину. Из него мы можем получить информацию о количестве исходящих сообщений, заполненности почтовых ящиков, узнать о том, отправлено ли нами сообщение или произошла ошибка, а также позволяет нам прервать отправку пакета, если мы почему-то передумали это делать.
Рис. 3. CAN transmit status register.
Address offset: 0x08
Reset value: 0x1C00 0000
| Биты | Название | Описание |
|---|---|---|
| 31 | LOW2 — Lowest priority flag for mailbox 2 | Наименьший приоритет для почтового ящика №2. Этот бит устанавливается аппаратно, когда более чем один почтовый ящик находится в обработке, а сообщение в почтовом ящике №2 имеет наименьший приоритет. |
| 30 | LOW1 — Lowest priority flag for mailbox 1 | Наименьший приоритет для почтового ящика №1. Этот бит устанавливается аппаратно, когда более чем один почтовый ящик находится в обработке, а сообщение в почтовом ящике №1 имеет наименьший приоритет. |
| 29 | LOW0 — Lowest priority flag for mailbox 0 | Наименьший приоритет для почтового ящика №0. Этот бит устанавливается аппаратно, когда более чем один почтовый ящик находится в обработке, а сообщение в почтовом ящике №0 имеет наименьший приоритет. Примечание: Биты LOW[2:0] устанавливаются в ноль, когда только один почтовый ящик находится на обработке. |
| 28 | TME2 — Transmit mailbox 2 empty | Почтовый ящик №2 пуст. Этот бит устанавливается аппаратно, когда нет запроса на обработку почтового ящика №2. |
| 27 | TME1 — Transmit mailbox 1 empty | Почтовый ящик №1 пуст. Этот бит устанавливается аппаратно, когда нет запроса на обработку почтового ящика №1. |
| 26 | TME0 — Transmit mailbox 0 empty | Почтовый ящик №0 пуст. Этот бит устанавливается аппаратно, когда нет запроса на обработку почтового ящика №0. |
| 25:24 | CODE[1:0] — Mailbox code | Код почтового ящика. В случае, когда по меньшей мере освобождается один почтовый ящик, значение CODE содержит номер следующего почтового ящика в очереди с наименьшим приоритетом. |
| 23 | ABRQ2 — Abort request for mailbox 2 | Прервать запрос на обработку почтового ящика №2. Устанавливается программно с целью прервать передачу из почтового ящика №2. Сбрасывается автоматически после того, как bxCan очищает почтовый ящик. Установка этого бита не имеет никакого значения, если почтовый ящик не задерживается для передачи. |
| 22:20 | Зарезервировано | |
| 19 | TERR2 — Transmission error of mailbox 2 | Ошибка передачи для почтового ящика №2. Устанавливается, когда произошла ошибка при передаче сообщения из этого почтового ящика. |
| 18 | ALST2 — Arbitration lost for mailbox 2 | Потеря арбитража для почтового ящика №2. Бит устанавливается, если при передачи сообщения устройство проиграла арбитраж. |
| 17 | TXOK2 — Transmission OK of mailbox 2 | Завершение передачи для почтового ящика №2. bxCan обновляет этот бит после каждой попытки передачи из почтового ящика и устанавливает следующие значения: 0 — передача не удалась; 1 — передача была успешной. Этот бит устанавливается аппаратно, когда успешно завершен запрос передачи для почтового ящика №2. |
| 16 | RQCP2 — Request completed mailbox2 | Завершен запрос на передачу для почтового ящика №2. Устанавливается аппаратно, когда был выполнен последний запрос (передан или прерван). Очищается программно путем установки бита в «1» или аппаратно по факту завершения передачи (установка бита TXRQ2 в регистре CAN_TI2R). Очистка этого бита сбрасывает все виды состояния для почтового ящика №2 (TXOK2, ALST2 и TERR2). |
| 15 | ABRQ1 — Abort request for mailbox 1 | Прервать запрос на обработку почтового ящика №1. Устанавливается программно с целью прервать передачу из почтового ящика №1. Сбрасывается автоматически после того, как bxCan очищает почтовый ящик. Установка этого бита не имеет никакого значения, если почтовый ящик не задерживается для передачи. |
| 14:12 | Зарезервировано | |
| 11 | TERR1 — Transmission error of mailbox1 | Ошибка передачи для почтового ящика №2. Устанавливается, когда произошла ошибка при передаче сообщения из этого почтового ящика. |
| 10 | ALST1 — Arbitration lost for mailbox1 | Потеря арбитража для почтового ящика №1. Бит устанавливается, если при передачи сообщения устройство проиграла арбитраж. |
| 9 | TXOK1 — Transmission OK of mailbox1 | Завершение передачи для почтового ящика №1. bxCan обновляет этот бит после каждой попытки передачи из почтового ящика и устанавливает следующие значения: 0 — передача не удалась; 1 — передача была успешной. Этот бит устанавливается аппаратно, когда успешно завершен запрос передачи для почтового ящика №1. |
| 8 | RQCP1 — Request completed mailbox1 | Завершен запрос на передачу для почтового ящика №1. Устанавливается аппаратно, когда был выполнен последний запрос (передан или прерван). Очищается программно путем установки бита в «1» или аппаратно по факту завершения передачи (установка бита TXRQ1 в регистре CAN_TI1R). Очистка этого бита сбрасывает все виды состояния для почтового ящика №1 (TXOK1, ALST1 и TERR1). |
| 7 | ABRQ0 — Abort request for mailbox0 | Прервать запрос на обработку почтового ящика №0. Устанавливается программно с целью прервать передачу из почтового ящика №0. Сбрасывается программно после того, как bxCan очищает почтовый ящик. Установка этого бита не имеет никакого значения, если почтовый ящик не задерживается для передачи. |
| 6:4 | Зарезервировано | |
| 3 | TERR0 — Transmission error of mailbox0 | Ошибка передачи для почтового ящика №0. Устанавливается, когда произошла ошибка при передаче сообщения из этого почтового ящика. |
| 2 | ALST0 — Arbitration lost for mailbox0 | Потеря арбитража для почтового ящика №0. Бит устанавливается, если при передачи сообщения устройство проиграла арбитраж. |
| 1 | TXOK0 — Transmission OK of mailbox0 | Завершение передачи для почтового ящика №0. bxCan обновляет этот бит после каждой попытки передачи из почтового ящика и устанавливает следующие значения: 0 — передача не удалась; 1 — передача была успешной. Этот бит устанавливается аппаратно, когда успешно завершен запрос передачи для почтового ящика №0. |
| 0 | RQCP0 — Request completed mailbox0 | Завершен запрос на передачу для почтового ящика №0. Устанавливается аппаратно, когда был выполнен последний запрос (передан или прерван). Очищается программно путем установки бита в «1» или аппаратно по факту завершения передачи (установка бита TXRQ0 в регистре CAN_TI0R). Очистка этого бита сбрасывает все виды состояния для почтового ящика №0 (TXOK0, ALST0 и TERR0). |
Как правило необходимости напрямую обращаться к этому регистру у нас не будет — можно полностью доверится bxCan. Я вижу потребность в его чтении только в очень сложных проектах, где часть функционала ложится не только на аппаратную часть, но и на программную. Также может потребоваться в случаях, когда необходимо использовать парсер CAN-шины — необходимо более детальное изучение ошибок передачи данных, логирование всего и вся.
Для обработки прерываний передачи сообщений необходимо разрешить прерывание при отправке почтового сообщения (CAN_IT_TME) и, соответственно, добавить это обработчик этого прерывания в тело программы (USB_HP_CAN1_TX_IRQHandler()).
CAN receive FIFO 0 register (CAN_RF0R)
Первый из двух регистров, отвечающих за буфер входящих сообщений FIFO 0.
Из этого регистра мы можем узнать количество почтовых сообщений, а также текущее состояние буфера FIFO 0.
Рис. 4. CAN receive FIFO 0 register.
Address offset: 0x0C
Reset value: 0x0000 0000
| Биты | Название | Описание |
|---|---|---|
| 31:6 | Зарезервировано | |
| 5 | RFOM0 — Release FIFO 0 output mailbox | Буфер FIFO0 освобожден. Устанавливается программно, чтобы освободить (очистить) почтовые ящики буфера FIFO0. Выходной почтовый ящик буфера может быть освобожден только в том случае, если на обработке FIFO0 имеется хотя бы одно сообщение. Устанавливать этот бит, когда FIFO0 пуст — не имеет никакого смысла. Очищается автоматически с помощью аппаратных средств, когда обработаны все сообщения, находящиеся в почтовых ящиках буфера FIFO0. |
| 4 | FOVR0 — FIFO 0 overrun | Буфер FIFO0 переполнен. Этот бит устанавливается аппаратными средствами, когда получено новое сообщение, но буфер FIFO0 уже заполнен. Этот бит необходимо сбрасывать программно. |
| 3 | FULL0 — FIFO 0 full | Буфер FIFO0 заполнен. Устанавливается аппаратно, когда заполнены все три почтовых ящика буфера FIFO0 Этот бит необходимо сбрасывать программно. |
| 2 | Зарезервировано | |
| 1:0 | FMP0[1:0] — FIFO 0 message pending | Количество сообщений в буфере FIFO0. Эти биты указывают, сколько сообщений находится на обработке в буфере FIFO0. FMP увеличивается каждый раз, когда поступает новое сообщение и уменьшается, после обработки каждого сообщения буфера. |
Обработка прерываний для буфера FIFO 0 происходит в функции USB_LP_CAN1_RX0_IRQHandler(). В ней необходимо обработать получение почтовых сообщений, а также проверить состояние ошибок (заполнение или переполнение буфера FIFO 0). Естественно, необходимо включить эти прерывания при настройке bxCan.
Необходимо помнить, что биты FOVR0 и FULL0 сбрасываются вручную.
CAN receive FIFO 1 register (CAN_RF1R)
А это второй регистр, предназначенный для чтения состояния буфера входящих сообщений, но уже для FIFO 1.
Из него мы также можем почерпнуть информацию о том, сколько сообщений у нас хранится и текущий статус самого буфера FIFO 1.
Рис. 5. CAN receive FIFO 1 register.
Address offset: 0x10
Reset value: 0x0000 0000
| Биты | Название | Описание |
|---|---|---|
| 31:6 | Зарезервировано | |
| 5 | RFOM1 — Release FIFO 1 output mailbox | Буфер FIFO1 освобожден. Устанавливается программно, чтобы освободить (очистить) почтовые ящики буфера FIFO1. Выходной почтовый ящик буфера может быть освобожден только в том случае, если на обработке FIFO1 имеется хотя бы одно сообщение. Устанавливать этот бит, когда FIFO1 пуст — не имеет никакого смысла. Очищается автоматически с помощью аппаратных средств, когда обработаны все сообщения, находящиеся в почтовых ящиках буфера FIFO1. |
| 4 | FOVR1 — FIFO 1 overrun | Буфер FIFO1 переполнен. Этот бит устанавливается аппаратными средствами, когда получено новое сообщение, но буфер FIFO1 уже заполнен. Этот бит необходимо сбрасывать программно. |
| 3 | FULL1 — FIFO 1 full | Буфер FIFO1 заполнен. Устанавливается аппаратно, когда заполнены все три почтовых ящика буфера FIFO1 Этот бит необходимо сбрасывать программно. |
| 2 | Зарезервировано | |
| 1:0 | FMP1[1:0] — FIFO 1 message pending | Количество сообщений в буфере FIFO1. Эти биты указывают, сколько сообщений находится на обработке в буфере FIFO1. FMP увеличивается каждый раз, когда поступает новое сообщение и уменьшается, после обработки каждого сообщения буфера. |
Для обработки прерываний для буфера FIFO 1 необходимо включить обработку этих прерываний при настройке bxCan и вставить в модуль функцию CAN1_RX1_IRQHandler(). Также как и с буфером FIFO 0, мы можем в обработчике прерываний выполнить обработку получения почтового сообщения в буфер FIFO 1, а также проверить состояние ошибок буфера и сбросить их после обработки.
Также напомню о необходимости сбрасывать биты FOVR1 и FULL1 вручную.
CAN interrupt enable register (CAN_IER)
Мы добрались до регистра, который непосредственно отвечает за включение прерываний bxCAN. Установив необходимые нам биты, мы сможем выполнить обработку прерываний. Напомню, что включение прерываний само по себе недостаточно, необходимо еще и включить сами прерывания и добавить их обработчики в тело программы, иначе наша программа при возникновении прерывания перейдет в прерывание по умолчанию и просто «зависнет». Но об этом поговорим чуть ниже, где я приведу несколько примеров.
Итак, нам необходимо включить прерывания. Сделать это мы можем установив соответствующие биты в регистре CAN interrupt enable register (CAN_IER).
Рис. 6. CAN interrupt enable register.
Address offset: 0x14
Reset value: 0x0000 0000
| Биты | Название | Описание |
|---|---|---|
| 31:18 | Зарезервировано | |
| 17 | SLKIE — Sleep interrupt enable | Прерывание при переходе в спящий режим. Вызывается, когда bxCan переходит в «спящий» режим при установленном бите SLAKI регистра CAN_MSR. 0: Прерывание не генерируется 1: Прерывание генерируется |
| 16 | WKUIE — Wakeup interrupt enable | Прерывание при выходе из спящего режима. Вызывается, когда bxCan выходит из спящего режима при установленном бите WKUI регистра CAN_MSR. 0: Прерывание не генерируется 1: Прерывание генерируется |
| 15 | ERRIE — Error interrupt enable | Прерывание при возникновении ошибки. 0: Прерывание не генерируется 1: Генерируется прерывание когда есть описание ошибки в регистре CAN_ESR. |
| 14:12 | Зарезервировано | |
| 11 | LECIE — Last error code interrupt enable | Прерывание при возникновении ошибки приема-передачи. Вызывается, когда установлены биты LEC[2:0] (регистр CAN_ESR) аппаратной частью bxCan. 0: Бит ERRI не будет установлен 1: Бит ERRI будет установлен при обнаружении ошибки на шине. |
| 10 | BOFIE — Bus-off interrupt enable | Прерывание при переходе в режим Bus-Off. Вызывается при переходе bxCan в режим Bus-Off при установленном бите BOFF регистра CAN_ESR. 0: Бит ERRI не будет установлен 1: Бит ERRI будет установлен |
| 9 | EPVIE — Error passive interrupt enable | Прерывание при достижении пассивного уровня ошибок. Вызывается когда счетчики ошибок приема или передачи превышают значение 127 при установленном бите EPVF регистра CAN_ESR. 0: Бит ERRI не будет установлен 1: Бит ERRI будет установлен |
| 8 | EWGIE — Error warning interrupt enable | Прерывание при достижении предупреждающего уровня ошибок. Вызывается когда счетчики ошибок приема или передачи превышают либо равны значению 96 при установленном бите EWGF. 0: Бит ERRI не будет установлен 1: Бит ERRI будет установлен |
| 7 | Зарезервировано | |
| 6 | FOVIE1 — FIFO overrun interrupt enable | Прерывание при переполнении буфера FIFO1. Вызывается, когда буфер FIFO1 заполнен и получено еще один пакет данных при установленном бите FOVR регистра CAN_RF1R. 0: Прерывание не генерируется 1: Генерируется прерывание |
| 5 | FFIE1 — FIFO full interrupt enable | Прерывание при заполнении буфера FIFO1. Вызывается когда в буфере FIFO1 заполнены все три почтовых ящика при установленном бите FULL регистра CAN_RF1R. 0: Прерывание не генерируется 1: Генерируется прерывание |
| 4 | FMPIE1 — FIFO message pending interrupt enable | Прерывание при получении пакета из шины. Вызывается когда в буфер FIFO1 получено очередное сообщение (при значении бита FMP[1:0] регистра CAN_RF1R не равном 00b). 0: Прерывание не генерируется 1: Генерируется прерывание |
| 3 | FOVIE0 — FIFO overrun interrupt enable | Прерывание при переполнении буфера FIFO0. Вызывается, когда буфер FIFO0 заполнен и получено еще один пакет данных при установленном бите FOVR регистра CAN_RF0R. 0: Прерывание не генерируется 1: Генерируется прерывание |
| 2 | FFIE0 — FIFO full interrupt enable | Прерывание при заполнении буфера FIFO0. Вызывается когда в буфере FIFO0 заполнены все три почтовых ящика при установленном бите FULL регистра CAN_RF0R. 0: Прерывание не генерируется 1: Генерируется прерывание |
| 1 | FMPIE0 — FIFO message pending interrupt enable | Прерывание при получении пакета из шины. Вызывается когда в буфер FIFO0 получено очередное сообщение (при значении бита FMP[1:0] регистра CAN_RF0R не равном 00b). 0: Прерывание не генерируется 1: Генерируется прерывание |
| 0 | TMEIE — Transmit mailbox empty interrupt enable | Прерывание при освобождении исходящего почтового ящика. Вызывается при окончании передачи сообщения при установленном бите RQCPx регистра CAN_TSR. 0: Прерывание не генерируется 1: Генерируется прерывание |
Если Вы новичок и только начинаете изучать протокол CAN и его использование на микроконтроллерах семейства STM32, то можно ограничиться одним прерыванием FMPIE0 (FIFO 0 message pending interrupt) и TMEIE (Transmit mailbox empty interrupt), которые отвечает за обработку получения входящего пакета в буфер FIFO 0, а также за обработку окончания отправки пакета в шину соответственно. Для первоначального изучения и тестирования этого вполне хватит, а дальше уже требуется более глубокое понимание физики процессов и специфики работы CAN шины.
CAN error status register (CAN_ESR)
Регистр отвечает за состояние ошибок при работе с bxCan.
Управление ошибками, как описано в протоколе CAN, обрабатывается полностью аппаратными средствами с помощью счетчиков ошибок передачи (TEC — Transmit error counter) и счетчиков ошибок приема сообщений (REC — Receive error counter), которые увеличивают или уменьшают свое значение в соответствии с состоянием ошибки.
Оба счетчика могут быть прочитаны с помощью программного обеспечения, чтобы определить стабильность сети.
Кроме того, аппаратное обеспечение может предоставлять более подробную информацию о текущем состоянии ошибок (LEC — Last error code).
Рис. 7. CAN error status register.
Address offset: 0x18
Reset value: 0x0000 0000
| Биты | Название | Описание |
|---|---|---|
| 31:24 | REC[7:0] — Receive error counter | Счетчик ошибок приема пакетов. Исполняющая часть механизма контроля состояния протокола CAN. В случае возникновения ошибки во время приема пакета, этот счетчик увеличивается на 1 или на 8 в зависимости от состояния ошибки (по определению стандарта CAN). После каждого успешного приема счетчик уменьшается на единицу или сбрасывается до 120, если его значение было выше, чем 128. Если значение счетчика превышает 127, то контроллер bxCan переходит в пассивное состояние ошибки (устанавливается бит EPVF). |
| 23:16 | TEC[7:0] — Transmit error counter | Счетчик ошибок передачи пакетов. Аналогично REC, только для ошибок передачи. |
| 15:17 | Зарезервировано | |
| 6:4 | LEC[2:0] — Last error code | Код последней ошибки. Это поле устанавливается аппаратно и содержит значение, которое указывает на вид последней ошибки, обнаруженной на CAN шине. Если сообщение было передано или получено без ошибок, то значение этих битов будет сброшено в ноль. Также программно можно установить эти биты в значение 0b111, что указывает, что ошибка установлена с помощью программного обеспечения. Коды ошибок: 000 — Нет ошибок 001 — Stuff error 010 — Form error 011 — Acknowledgment Error 100 — Bit recessive Error 101 — Bit dominant Error 110 — CRC Error 111 — Set by software Описание ошибок приведено ниже в таблице №4. |
| 3 | Зарезервировано | |
| 2 | BOFF — Bus-off flag | Bus-off флаг. Этот бит устанавливается, когда bxCan переходит в режим Bus-off. Режим Bus-off вводится, когда счетчик ошибок передачи (TEC) становится больше чем 255. |
| 1 | EPVF — Error passive flag | Флаг пассивной ошибки. Этот бит устанавливается аппаратно, когда достигнут пассивный предел счетчиков ошибок (Счетчик приема и/или передачи больше 127). |
| 0 | EWGF — Error warning flag | Флаг предупреждения об ошибках. Бит устанавливается аппаратно, когда достигнут предел предупреждения (Счетчик ошибок приема и/или передачи ≥ 96). |
Согласно описанию протокола CAN принято увеличивать счетчик ошибок REC (Receive error counter) на одну единицу при каждой обнаруженной ошибке приема на шине, а счетчик ошибок TEC (Transmit error counter) увеличивать на 8 при каждой ошибке передачи пакетов. Это связано стем, что существует предположение о том, что с наибольшей вероятностью источником ошибок на шине является передающий узел.
Уменьшение счетчика ошибок происходит автоматически на единицу при каждом успешном приеме или передаче сообщений по шине для счетчиков REC и TEC соответственно.
Восстановление BUS-OFF
Состояние шины Bus-Off устанавливается, когда счетчик ошибок передачи превышает 255, при этом устанавливается бит BOFF регистра CAN_ESR. В этом режиме bxCan фактически перестает принимать и передавать пакеты по шине.
При настройке bxCAN можно установить бит ABOM, который отвечает за то, что если шина перейдет в режим Bus-off, то bxCan автоматически начнет проверять сигнал CAN_RX для восстановления шины. Если бит ABOM не установлен, то разработчику необходимо контролировать этот процесс самостоятельно и в случае возникновения ошибки и перехода в режим Bus-off необходимо заново проинициализировать bxCan.
Обратите внимание, что bxCan слушает порт CAN_RX только в нормальном режиме работы. Если bxCan находится в режиме инициализации, то автоматического восстановления шины не произойдет.
Долгое время не мог понять, что это за 11 рецессивных бит 128 раз подряд и где их необходимо взять и куда подать. Путем гугления и раскурки мануалов понял, что это указывается время, через которое контроллер CAN шины автоматически выйдет из режима Bus-Off и оно равно времени, которое потребуется для передачи 11 рецессивных бит 128 раз подряд.
Другими словами, контроллер автоматически выйдет из режима Bus-Off, когда на CAN шине будет «тишина» в течении времени, равному времени передачи 11 бит * 128 раз. Естественно, если в настройках контроллера мы ему указали, что он может автоматически выходить из этого режима (установлен бит ABOM регистра CAN_MCR).
Практика
Вроде все моменты, которые касаются обработки прерываний bxCan мы рассмотрели. Текста очень много, но как это применить на практике?
Давайте разбираться.
Для начала нам необходимо определится с тем, какие прерывания bxCan мы будем использовать. Конечно можно ограничиться прерыванием на получение сообщения в буфер FIFO, но мы же не ищем легких путей, поэтому проинициализируем сразу все.
За включение/отключение прерываний bxCan отвечает функция CAN_ITConfig, эти действия выполняются в модуле инициализации can шины совместно с настройкой прерываний NVIC:
Листинг №1. Включение прерываний bxCan
// CAN Transmit mailbox empty Interrupt enable
// Обрабатывается в прерывании USB_HP_CAN1_TX_IRQHandler
CAN_ITConfig(CAN1, CAN_IT_TME, ENABLE); // Прерывание при освобождении исходящего почтового ящика
// CAN Receive Interrupt enable
// Обрабатывается в прерывании USB_LP_CAN1_RX0_IRQHandler
CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE); // Прерывание получения пакета в буфер FIFO 0
CAN_ITConfig(CAN1, CAN_IT_FF0, ENABLE); // Прерывание при заполнении буфера FIFO 0
CAN_ITConfig(CAN1, CAN_IT_FOV0, ENABLE); // Прерывание при переполнении буфера FIFO 0
// Обрабатывается в прерывании CAN1_RX1_IRQHandler
CAN_ITConfig(CAN1, CAN_IT_FMP1, ENABLE); // Прерывание получения пакета в буфер FIFO 1
CAN_ITConfig(CAN1, CAN_IT_FF1, ENABLE); // Прерывание при заполнении буфера FIFO 1
CAN_ITConfig(CAN1, CAN_IT_FOV1, ENABLE); // Прерывание при переполнении буфера FIFO 1
// CAN Operating Mode Interrupt enable
// Обрабатывается в прерывании CAN1_SCE_IRQHandler
CAN_ITConfig(CAN1, CAN_IT_WKU, ENABLE); // Прерывание при "пробуждении" - выход из "спящего" режима
CAN_ITConfig(CAN1, CAN_IT_SLK, ENABLE); // Прерывание при переходе в "спящий" режим
// CAN Error Interrupts
// Обрабатывается в прерывании CAN1_SCE_IRQHandler
CAN_ITConfig(CAN1, CAN_IT_EWG, ENABLE); // Error warning Interrupt (error counter >= 96)
CAN_ITConfig(CAN1, CAN_IT_EPV, ENABLE); // Error passive Interrupt (error counter > 127)
CAN_ITConfig(CAN1, CAN_IT_BOF, ENABLE); // Bus-off Interrupt (error counter > 255)
CAN_ITConfig(CAN1, CAN_IT_LEC, ENABLE); // Last error code - при возникновении ошибок приема-передачи
CAN_ITConfig(CAN1, CAN_IT_ERR, ENABLE); // Прерывание при возникновении ошибок bxCan
// NVIC Configuration
NVIC_InitTypeDef NVIC_InitStructure;
// Enable CAN1 TX0 interrupt IRQ channel
NVIC_InitStructure.NVIC_IRQChannel = USB_HP_CAN1_TX_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
// Enable CAN1 RX0 interrupt IRQ channel
NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
// Enable CAN1 RX1 interrupt IRQ channel
NVIC_InitStructure.NVIC_IRQChannel = CAN1_RX1_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
// Enable CAN1 SCE (Status Change Error) interrupt IRQ channel
NVIC_InitStructure.NVIC_IRQChannel = CAN1_SCE_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
После того, как с помощью функции CAN_ITConfig() мы проинициализировали необходимые нам прерывания, необходимо включить обработчики этих прерываний. Делается это через NVIC. Если мы забудем хотя бы одно из них включить, то микроконтроллер при возникновении прерывания, которое мы забыли обработать, выкинет нас в стандартный обработчик прерываний и просто зависнет. Поможет только перезагрузка процессора, так как он будет сидеть в «вечном» цикле и ни на что больше реагировать не будет.
А теперь, чтобы этого не произошло, нам необходимо вставить в наш программный код функции обработки прерываний. Всего их четыре: прерывание при освобождении исходящего почтового ящика, два прерывания для буферов FIFO 1 и 2, а также прерывание по обработке ошибок и входа/выхода в «режим сна».
Обработка прерываний при освобождении исходящего почтового ящика
За обработку прерывания при освобождении исходящего почтового ящика отвечает функция USB_HP_CAN1_TX_IRQHandler(). Нам необходимо проверить флаг прерывания и, если он установлен, сбросить его и выполнить код обработки прерывания:
Листинг №2. Обработка прерываний bxCan для исходящего почтового ящика
void USB_HP_CAN1_TX_IRQHandler(void)
{
// CAN Transmit mailbox empty Interrupt enable
// Обработаем прерывания при освобождении исходящего почтового ящика
if (CAN_GetITStatus(CAN1, CAN_IT_TME)==SET) { // Прерывание при освобождении исходящего почтового ящика
CAN_ClearITPendingBit(CAN1, CAN_IT_TME);
// Вставляем свой код по обработке прерывания
}
}
Функция CAN_GetITStatus() возвращает текущее состояние флага прерывания, значение может быть равным SET или RESET («Установлен» или «сброшен» соответственно). Значение SET говорит нам о том, что бит установлен и нам необходимо обработать это прерывание и не забыть сбросить его флаг.
Следует помнить о том, что необходимо всегда производить сброс флага прерывания, иначе оно будет вызываться постоянно. Исключение составляют только флаги прерываний ошибок, они почти все сбрасываются аппаратно, подробнее можно посмотреть в описании функции CAN_ClearITPendingBit().
Проверять освобождение исходящего почтового ящика имеет смысл, если Вы пересылаете большой объем данных по Can-шине: при обработке отправки сообщения выставляется флаг отправки сообщения, а в прерывании проверяется была выполнена отправка данных или нет. Если отправка была завершена без ошибок, то устанавливаем в флаг значение без ошибок и отправляем следующий пакет данных, иначе устанавливаем в флаг код ошибки и обрабатываем ее в модуле программы.
Несмотря на то, что исходящих почтовых ящиков у нас три, проверять отправку сообщений я все же рекомендую, иначе вполне вероятны ситуации, когда в результате проигрыша арбитража или возникновении ошибок на линии bxCan не сможет отправить сообщения, а мы в этот момент, не проверив статус отправки, будем давать ему новые на отправку. Возникнет сбой, который нам не нужен.
Проверить статус отправки сообщения можно не только с помощью прерываний, но и в момент отправки сообщения (это наверное самый оптимальный вариант):
Листинг №3. Отправка сообщения с проверкой статуса отправки
uint32_t i = 0;
uint8_t TransmitMailbox = 0;
...
TransmitMailbox = CAN_Transmit(CAN1, &TxMessage);
i = 0;
while ((CAN_TransmitStatus(CAN1, TransmitMailbox) != CANTXOK) && (i != 0xFF)) {
i++;
}
При передаче сообщения через функцию CAN_Transmit, она нам возвращает номер исходящего почтового ящика, в который помещено сообщение. Затем мы в цикле проверяем, отправил ли bxCan наше сообщение или нет. Если отправка прошла успешно, то статус отправки сообщения из почтового ящика будет равен CANTXOK.
По окончанию цикла while() проверяем значение переменной «i». Если оно у нас равно 0xFF, значит отправка не удалась и тут мы уже думаем что сделать: то ли сбросить отправку сообщения, то ли обработать ошибку.
Вообщем все на усмотрение разработчика.
Обработка прерываний входящего буфера сообщений FIFO 0
За прерывания для входящего буфера сообщений FIFO 0 отвечают флаги CAN_IT_FMP0, CAN_IT_FF0 и CAN_IT_FOV0.
| Наименование | Описание |
|---|---|
| CAN_IT_FMP0 | Прерывание срабатывает при получении очередного сообщения в буфер FIFO 0. |
| CAN_IT_FF0 | Прерывание возникает при заполнении всех трех почтовых ящиков буфера FIFO 0. |
| CAN_IT_FOV0 | А это прерывание возникает если у нас все три почтовых ящика буфера FIFO 0 заполнены и мы получаем четвертое сообщение по шине. У нас происходит переполнение буфера. |
Таб. 1. Прерывания буфера FIFO 0
Заполнение, а тем более переполнение буфера входящих сообщений говорит о том, что Ваша программа не успевает их обрабатывать. Здесь уже необходимо искать причину в организации работы CAN шины и поиграться с установкой фильтров сообщений.
Фильтры помогут на аппаратном уровне отсеивать пакеты с ненужными нам данными, чтобы не тратить время и ресурсы процессора на обработку ненужной информации. Подробнее работу с фильтрами я описал в статье STM32. Почтовые ящики. Фильтры пакетов CAN.
Действия по обработке данных прерываний возлагаются на разработчика и описываются в функции USB_LP_CAN1_RX0_IRQHandler().
Листинг №4. Обработка прерываний bxCan для буфера FIFO 0
void USB_LP_CAN1_RX0_IRQHandler(void)
{
CanRxMsg RxMessage;
// CAN Receive Interrupt enable FIFO 0
// Обработаем прерывания приемного буфера FIFO 0
if (CAN_GetITStatus(CAN1, CAN_IT_FMP0) == SET) { // Прерывание получения пакета в буфер FIFO 0
// Флаг сбрасывается автоматически после прочтения последнего сообщения
// Обнулим данные пакета
RxMessage.DLC = 0x00;
RxMessage.ExtId = 0x00;
RxMessage.FMI = 0x00;
RxMessage.IDE = 0x00;
RxMessage.RTR = 0x00;
RxMessage.StdId = 0x00;
RxMessage.Data [0] = 0x00;
RxMessage.Data [1] = 0x00;
RxMessage.Data [2] = 0x00;
RxMessage.Data [3] = 0x00;
RxMessage.Data [4] = 0x00;
RxMessage.Data [5] = 0x00;
RxMessage.Data [6] = 0x00;
RxMessage.Data [7] = 0x00;
CAN_Receive(CAN1, CAN_FIFO0, &RxMessage); // Получим сообщение
// Вставляем любой свой код обработки входящего пакета
}
if (CAN_GetITStatus(CAN1, CAN_IT_FF0)==SET) { // Прерывание при заполнении буфера FIFO 0
CAN_ClearITPendingBit(CAN1, CAN_IT_FF0);
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_FF0);
}
if (CAN_GetITStatus(CAN1, CAN_IT_FOV0)==SET) { // Прерывание при переполнении буфера FIFO 0
CAN_ClearITPendingBit(CAN1, CAN_IT_FOV0);
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_FOV0);
}
}
Следует обратить внимание на то, что функция USB_LP_CAN1_RX0_IRQHandler() предназначена как для обработки прерываний bxCan так и для обработки прерываний USB. Если Вы будете использовать USB в своем проекте, то нужно внимательно подойти к этому моменту, чтобы правильно обрабатывать сообщения для каждого устройства.
Обратите внимание, что в обработчике прерываний мы сбрасываем не только флаг прерывания, но также сбрасываем флаг ошибки bxCan. Это немного (точнее очень много) разные вещи: флаг прерывания отвечает за то, что мы попадем в обработчик прерывания при его установке и если его не сбросить, то мы можем сидеть вечно в этом обработчике. А флаг ошибки сигнализирует нам о том, что есть ошибка и его нужно снять после того, как мы обработали эту ошибку. Соответственно, если по какой-либо причине мы ее не обработали — этот флаг снимать не следует.
Напомню, что часть флагов прерываний (и ошибок) снимаются автоматически, здесь нужно внимательно изучать руководство.
Обработка прерываний входящего буфера сообщений FIFO 1
За прерывания для входящего буфера сообщений FIFO 1 отвечают флаги CAN_IT_FMP1, CAN_IT_FF1 и CAN_IT_FOV1. Описание и действие аналогично с обработкой прерывания для буфера FIFO 0.
| Наименование | Описание |
|---|---|
| CAN_IT_FMP1 | Прерывание срабатывает при получении очередного сообщения в буфер FIFO 1. |
| CAN_IT_FF1 | Прерывание возникает при заполнении всех трех почтовых ящиков буфера FIFO 1. |
| CAN_IT_FOV1 | А это прерывание возникает если у нас все три почтовых ящика буфера FIFO 1 заполнены и мы получаем четвертое сообщение по шине. У нас происходит переполнение буфера. |
Таб. 2. Прерывания буфера FIFO 1
В отличии от буфера FIFO 0, обработка этих прерываний происходит в функции CAN1_RX1_IRQHandler().
Листинг №5. Обработка прерываний bxCan для буфера FIFO 1
void CAN1_RX1_IRQHandler(void)
{
CanRxMsg RxMessage;
// CAN Receive Interrupt enable FIFO 1
// Обработаем прерывания приеного буфера FIFO 1
if (CAN_GetITStatus(CAN1, CAN_IT_FMP1) == SET) { // Прерывание получения пакета в буфер FIFO 1
// Флаг сбрасывается автоматически после прочтения последнего сообщения
// Обнулим данные пакета
RxMessage.DLC = 0x00;
RxMessage.ExtId = 0x00;
RxMessage.FMI = 0x00;
RxMessage.IDE = 0x00;
RxMessage.RTR = 0x00;
RxMessage.StdId = 0x00;
RxMessage.Data [0] = 0x00;
RxMessage.Data [1] = 0x00;
RxMessage.Data [2] = 0x00;
RxMessage.Data [3] = 0x00;
RxMessage.Data [4] = 0x00;
RxMessage.Data [5] = 0x00;
RxMessage.Data [6] = 0x00;
RxMessage.Data [7] = 0x00;
CAN_Receive(CAN1, CAN_FIFO1, &RxMessage); // Получим сообщение
// Вставляем любой свой код обработки входящего пакета
}
if (CAN_GetITStatus(CAN1, CAN_IT_FF1)==SET) { // Прерывание при заполнении буфера FIFO 1
CAN_ClearITPendingBit(CAN1, CAN_IT_FF1);
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_FF1);
}
if (CAN_GetITStatus(CAN1, CAN_IT_FOV1)==SET) { // Прерывание при переполнении буфера FIFO 1
CAN_ClearITPendingBit(CAN1, CAN_IT_FOV1);
/ Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_FF1);
}
}
Обработчик для буфера FIFO 1 ничем не отличается от обработчика для буфера FIFO 0, разница есть только в наименовании функции обработчика и флагов, которые мы проверяем. Наполнение буфера FIFO 1 (как и FIFO 0) зависит исключительно от настроек фильтрации пакетов и в них же указывается какие сообщения в какой буфер будут попадать.
Подробно я о фильтрах рассказывал в статье STM32. Почтовые ящики. Фильтры пакетов CAN.
В своем проекте управления умным домом я с помощью фильтрации разделяю управляющие пакеты и пакеты с данными по разным буферам: сообщения данных попадают исключительно в буфер FIFO 0, а системные и приоритетные сообщения я помещаю в буфер FIFO 1.
Если у Вас нет задачи такой фильтрации сообщений, то можно вполне обойтись одним буфером FIFO 0 и в принципе не использовать буфер FIFO 1 (или наоборот, роли никакой не играет). Для большинства задач это будет вполне достаточно и сэкономит Вам несколько сотен байт прошивки.
Обработка прерываний по ошибкам и «спящему» режиму
Обработчик прерываний ошибок bxCan позволяет нам определить насколько стабильно работает наше устройство с протоколом CAN и вовремя принять меры для достижения максимально стабильного режима работы.
За обработку ошибок отвечают следующие флаги:
| Наименование | Описание |
|---|---|
| CAN_IT_ERR | Error Interrupt — устанавливается при возникновении любой ошибки |
| CAN_IT_EWG | Error warning Interrupt — предупреждение о том, что один из счетчиков ошибок достиг 96 или более ошибок |
| CAN_IT_EPV | Error passive Interrupt — предупреждение о том, что один из счетчиков ошибок достиг более 127 ошибок |
| CAN_IT_BOF | Bus-off Interrupt — Возникает при переходе шины в режим Bus-Off, когда любой из счетчиков ошибок превысил значение 255 |
| CAN_IT_LEC | Last error code Interrupt — активируется при возникновении ошибок приема передачи |
| CAN_IT_WKU | Wake-up Interrupt — возникает при «пробуждении» bxCan, когда шина выходит из спящего режима. |
| CAN_IT_SLK | Sleep acknowledge Interrupt — возникает при уходе шины в «спящий» режим. |
Таб. 3. Прерывания ошибок и режима шины
Прерывание по флагам CAN_IT_WKU и CAN_IT_SLK срабатывают при входе или выходе в/из спящего режима. При этом флаг CAN_IT_ERR не устанавливается. А если же срабатывает прерывание по флагам CAN_IT_EWG, CAN_IT_EPV, CAN_IT_BOF или CAN_IT_LEC, то одновременно с ними устанавливается и флаг CAN_IT_ERR.
Флаги CAN_IT_EWG, CAN_IT_EPV и CAN_IT_BOF предназначены для контроля количества ошибок приема передачи по шине. Механизм bxxCan не только увеличивает счетчик ошибок, например когда на линии возникает помеха и счетчик ошибок увеличивается, но и уменьшает его, когда работа шины нормализуется. Флаги CAN_IT_EWG и CAN_IT_EPV являются предупреждающими о том, что идет рост ошибок и необходимо выявить причину их возникновения, а вот флаг CAN_IT_BOF нам сообщает, что счетчик ошибок достиг своего максимума и шина перешла в режим Bus-off. Выход из этого режима может произойти автоматически (при получении 128 раз 11 рецессивных бит подряд по шине) или принудительно — заново проинициализировав bxCan.
Напомню, что за автоматический выход из режима Bus-Off отвечает бит ABOM в регистре CAN_MCR. Рекомендую его устанавливать в Ваших проектах, тогда bxCan этот функционал возьмет на себя.
Флаг CAN_IT_LEC срабатывает, когда происходит ошибка приема или передачи пакета, при его обработке мы можем узнать последнюю ошибку шины или устройства.
С тем что обрабатывать — мы определились, теперь необходимо вставить в программный модуль и саму функцию обработки прерываний ошибок CAN1_SCE_IRQHandler().
В ней мы сформируем шаблон обработки исключений, возникающих при работе bxCan:
Листинг №6. Обработка прерываний засыпания/пробуждения и ошибок bxCan
void CAN1_SCE_IRQHandler(void)
{
uint8_t errorcode = 0;
if (CAN_GetITStatus(CAN1, CAN_IT_ERR)==SET) { // Прерывание при возникновении ошибки
CAN_ClearITPendingBit(CAN1, CAN_IT_ERR);
// CAN Error Interrupts
// Обработка прерываний по ошибке
if (CAN_GetITStatus(CAN1, CAN_IT_EWG)==SET) { // Error warning Interrupt (счетчик ошибок >= 96)
CAN_ClearITPendingBit(CAN1, CAN_IT_EWG);
// Вставляем свой код по обработке прерывания
}
if (CAN_GetITStatus(CAN1, CAN_IT_EPV)==SET) { // Error passive Interrupt (счетчик ошибок > 127)
CAN_ClearITPendingBit(CAN1, CAN_IT_EPV);
// Вставляем свой код по обработке прерывания
}
if (CAN_GetITStatus(CAN1, CAN_IT_BOF)==SET) { // Bus-off. Прерывание при переполнении счетчика ошибок (>255)
CAN_ClearITPendingBit(CAN1, CAN_IT_BOF); // bxCan уходит в режим Bus-OFF
// Вставляем свой код по обработке прерывания
}
if (CAN_GetITStatus(CAN1, CAN_IT_LEC)==SET) { // Прерывание при ошибке приема передачи сообщения
CAN_ClearITPendingBit(CAN1, CAN_IT_LEC);
errorcode = CAN_GetLastErrorCode(CAN1); // Получим код ошибки
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_LEC);
}
} else {
// CAN Operating Mode Interrupt
// Обработка прерываний по режимам сна/пробуждения
if (CAN_GetITStatus(CAN1, CAN_IT_WKU)==SET) { // Прерывание при "пробуждении" - выход из "спящего" режима
CAN_ClearITPendingBit(CAN1, CAN_IT_WKU);
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_WKU);
}
if (CAN_GetITStatus(CAN1, CAN_IT_SLK)==SET) { // Прерывание при переходе в "спящий" режим
CAN_ClearITPendingBit(CAN1, CAN_IT_SLK);
// Вставляем свой код по обработке прерывания
// Не забываем после обработки сбросить флаг ошибки
CAN_ClearFlag(CAN1, CAN_FLAG_SLAK);
}
}
}
Также как мы сбрасываем флаги прерываний, нам необходимо сбрасывать и флаги ошибок после их обработки. Но если обратить внимание на описание регистров, то мы видим, что часть флагов ошибок сбрасываются автоматически аппаратными средствами bxCan, а часть мы должны очищать вручную. Вот и сейчас при обработке ошибок мы можем сбросить только флаги CAN_IT_LEC, CAN_IT_WKU и CAN_IT_SLK, а остальные флаги ошибок в данном обработчике прерываний сбрасываются автоматически.
Не стоит забывать и о том, что перед сбросом флага ошибки мы должны ее (ошибку) обработать и уже потом менять флаг.
Еще стоит обратить внимание на обработку прерывания CAN_IT_LEC (Last Error Code), которая появляется при возникновении ошибок ввода-вывода.
В обработчике с помощью функции CAN_GetLastErrorCode() мы заполняем переменную errorcode данными о последней ошибке. Она может принимать следующие значения:
| Вид | Определение | Описание |
|---|---|---|
| 0x00 | CAN_ErrorCode_NoErr | Нет ошибок |
| 0x10 | CAN_ErrorCode_StuffErr | Когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error. |
| 0x20 | CAN_ErrorCode_FormErr | Некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error. |
| 0x30 | CAN_ErrorCode_ACKErr | Каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error. |
| 0x40 | CAN_ErrorCode_BitRecessiveErr | Ошибка установки рецессивного бита. Каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается. |
| 0x50 | CAN_ErrorCode_BitDominantErr | Ошибка установки доминантного бита. Каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается. |
| 0x60 | CAN_ErrorCode_CRCErr | Каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error. |
| 0x70 | CAN_ErrorCode_SoftwareSetErr | Установлено программно. Можно заполнить единицами данные битов LEC[2:0] регистра CAN_ESR. |
Таб. 4. Виды ошибок, возвращаемые при вызове функции CAN_GetLastErrorCode()
Таким образом, обрабатывая флаг CAN_IT_LEC и изучая ошибки, которые происходят при работе с CAN, мы можем заблаговременно выявить причину и предпринять некоторые действия для того, что бы предотвратить рост ошибок и сваливание CAN контроллера в режим Bus-Off.
Заключение
В этой статье я постарался подробно описать механизмы обработки прерываний bxCan, а также механизмы связанные с обработкой ошибок и методы по их сокращению. Напомню, что все тестирование кода производилось на базе микроконтроллера STM32F103C6.
Вполне вероятно, что я что-то упустил, где то наоборот ошибся и был не точен. Поэтому если есть какие-либо замечания и/или предложения к статье — добро пожаловать в комменты и я исправлюсь.
Как обычно, во вложениях весь исходный код, который рассматривается в рамках данной статьи. Но в отличие от предыдущих постов, исходный код для этой статьи представляет собой некий шаблон, который предполагается использовать в разных проектах.
З.Ы. Простите за много букафф )))