Существует три версии CAN протокола:
•2.0A – Считает 29-ти битный идентификатор как ошибка
•2.0B Пассивный - игнорирует сообщения с 29-ти битным идентификатором
•2.0B Активный – может работать как с идентификаторами на 29 бит, так и с 11-ти битными идентификаторами
Модуль ECAN в dsPIC33F поддерживает версию протокола CAN 2.0B Active при этом обеспечивает увеличение способностей фильтрования сообщений.
Обратите внимание: Для более подробной информации о протоколе CAN смотрите Bosch CAN bus specification.
2.1 Стандартный фрейм данных
Стандартный фрейм данных начинается с бита Start-of-Frame, который сопровоздается 12-ти битовым полем Arbitration, как показано на рисунке 4. Поле Arbitration содержит 11-ти битный идентификатор, и бит Remote Transmit Request (RTR). Идентификатор определяет тип информации, содержащейся в сообщении и используется каждым узлом приёмника, чтобы определить, представляет ли данное сообщение для него интерес. Бит RTR отделяет поле Arbitration от поля Control. Для стандартного фрейма данных бит RTR=0.
После поля Arbitration следует поле Control, состоящая из 6 бит, которое обеспечивает дополнительную информацию о содержании сообщения. Первый бит в области Control – бит Identifier Extension (IDE), который указывает какой формат у фрейма или стандартный или расширенный. Стандартный фрейм данных определяется доминантным состоянием (логический уровень ‘0’) в течение передачи бита IDE. Второй бит в поле Control – бит Reserved (RB0), который находится в доминантном состоянии (логический ‘0’). Последние 4 бита в поле Control определяют длину данных Data Length Code (DLC), которая указывает на количество байт, которое будет содержать сообщение.
Поле Data следует за полем Control. Это поле несёт данные сообщения – фактически полезные данные всего фрейма. Это поле является переменной длины, в пределах от 0 до 8 байтов. Количество байт выбирается пользователем.
Поле Data сопровождается полем Cyclic Redundancy Check (CRC), которое является 15-ти битным CRC кодом с одним разделительным битом.
Поле подтверждения (ACK) отправляется с установленным битом (recessive, логическая «1»), и переписывается как dominant бит любым приемником, который правильно получил данные. Сообщение подтверждается независимо от фильтра, т.е. модуль принимает все сообщения, а лишь затем их для себя фильтрует.
Последнее поле – это поле End-of-Frame, которое состоит из 7 recessive бита которые обозначают конец сообщения.
Рисунок 4. Структура стандартного фрейма данных
2.2 Расширенный фрейм данных
Расширенный фрейм данных начинается с бита SOF, сопровождаемый 31 битным полем Arbitration, как показано на рисунке 5. Поле Arbitration для расширенного фрейма данных содержит 29-ти битный идентификатор в двух полях, отделённых битом Substitute Remote Request (SRR) бит и битом IDE. Бит SRR определяет, является ли сообщение удалённым запросом данных. SRR = 0 для расширенного фрейма данных. IDE бит указывает тип фрейма данных. Для расширенного фрейма данных IDE = 1.
В расширенном фрейме данных поле Control состоит из 7 битов. Первый бит - RTR. Для расширенного фрейма данных RTR = 0. Следующие два бита, RB1 и RB0, являются резервными битами, которые находятся в состоянии dominant (логический ‘0’). Последние 4 бита в поле Control – длина данных, которая определяет количество байт, которые далее будут переданы в данном фрейме.
Остальные поля в расширенном фрейме данных идентичны стандартному фрейму данных.
Рисунок 5. Структура расширенного фрейма данных.
2.3 Удалённый запрос данных
Узел который желает получить от другого узла какие-нибудь данные может данный запросом запросить нужные данные. Удалённый запрос может быть в стандартном (рисунок 6) или в расширенном фрейме (рисунок 7).
Удалённый запрос подобен фрейму данных со следующими исключениями:
• RTR бит имеет состояние recessive (RTR = 1)
• Поле данных отсутствует (DLC = 0)
Рисунок 6. Формат стандартного удалённого запроса
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.