[i] Базовые сведения о протоколе CAN и реализация работы с разбором кадра данных в микроконтроллере К1986BE92У

ID статьи: 24452

Дата последнего изменения: 19.12.2025 13:55:50

Материал из настоящей статьи, относящийся к микросхемам К1986ВЕ92У распространяется в том числе на микроконтроллеры К1986ВЕ91Т, К1986ВЕ92У1, К1986ВЕ93У, К1986ВЕ94Т, К1986ВЕ92QI, К1986ВЕ92FI, К1986ВЕ92F1I, К1986ВЕ94GI. Здесь же важно отметить, что поскольку контроллер CAN в микроконтроллерах компании "Миландр" одинаков, статья может быть полезна и при работе с другими микросхемами.

Подробную информацию о Controller Area Network (CAN) можно прочесть в Википедии.

В статье будут приведены лишь базовые сведения, и рассмотрена программа, которая позволяет отправить с микроконтроллера К1986ВЕ92У стандартный кадр CAN со скоростью 500 Кбит/с. Для отслеживания и анализа кадра используется осциллограф. Проект прост в реализации и адаптивен под работу с протоколом CAN на других микроконтроллерах производства компании Миландр.

Базовые сведения

CAN (англ. Controller Area Network – локальная сеть контроллеров) – стандарт промышленной сети, ориентированный на объединение блоков управления, исполнительных устройств и датчиков в систему.
CAN определяет только протокол передачи данных в отрыве от физического уровня. На практике, однако, под CAN обычно понимается сеть с топологией типа «шина», организованная на базе дифференциальной пары, имеющей сигналы CAN_H (can-high) и CAN_L (can-low)
Для абстрагирования от среды передачи, стандарт CAN не использует такие понятия, как логические «0» и «1» при определении сигналов. Вместо этого применяются термины «доминантный» и «рецессивный», смысл которых состоит в том, что при одновременной передаче двумя источниками доминантного и рецессивного сигналов, принят будет только доминантный. Стандарт сети требует от физического уровня, фактически, единственного условия: подавление доминантным сигналом рецессивного (но не наоборот).
Все устройства должны работать на одной скорости.
Шина CAN обязательно должна терминироваться не зависимо от ее скорости. Это достигается путем установки резисторов на концах шины.
Информация в сети CAN передается кадрами (англ. frame), имеющими определенную структуру. Кадры бывают следующие:
1. Data Frame (Наиболее частый тип сообщений. Состоит из поля арбитража, поля данных, поля CRC и слота подтверждения)
2. Remote Frame (То же, что и Data Frame, но без поля данных и с выставленным RTR в “1”. Производит инициацию одним из узлов сети передачи в сеть данных другим узлом).
3. Error Frame (Это сообщение, которое явно нарушает формат сообщения CAN).
4. Overload Frame (То же, что и Error Frame, но используется перегруженным узлом).
Протокол CAN имеет пять механизмов обнаружения ошибок в сети:
1. Контроль передаваемых значений.
2. Вставка битов.
3. Проверка формы кадра.
4. Подтверждение приема.
5. Контрольная сумма.
Использование арбитража. Поле арбитража используется в CAN для разрешения коллизий доступа к шине методом не деструктивного арбитража. Суть метода не деструктивного арбитража заключается в следующем: в случае, когда несколько контроллеров начинают одновременную передачу данных в сеть, каждый из них сравнивает бит конкурирующего контроллера со своим. Если значения этих битов равны, оба контроллера передают следующий бит. И так происходит до тех пор, пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал), будет продолжать передачу, а другой (другие) - прервёт свою передачу до того времени, пока шина вновь не освободится. Конечно, если шина в данный момент занята, то устройство не начнет передачу до момента её освобождения. На рисунке 1 наглядно показана работа арбитража в протоколе CAN.

Рисунок 1 - Пример процесса арбитража в протоколе CAN

Проект для передачи стандартного кадра CAN с его последующим разбором

Поскольку работа с проектом ведётся на отладочной плате производства компании Миландр, важно около разъема CAN на отладочной плате поставить перемычку XP15 в положение, указывающем на 500 Кбит/с, что отвечает за скорость работы протокола CAN.

Код для стандартных настроек портов ввода/вывода не рассматривается, все данные доступны для рассмотрения в стандартных примерах из пака для Keil. Особое внимание уделено настройке CAN-блока.

CAN-контроллер использует две линии обмена данными, и они обе должны быть сконфигурированы (CAN_RX - для приёма и CAN_TX - для передачи). На микроконтроллере 1986BE92 за CAN1 отвечают линии PA6 и PA7 соответственно. Стоит отметить, что функция порта альтернативная. После выполненных действий можно приступить к настройке CAN.

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

1. Включить тактирование модуля.

2. Сконфигурировать структуру CAN:

// Структура для инициализации модуля 

	 CAN CAN_InitTypeDef CANInitStruct; 

	 // Конфигурация модуля 

	 CAN1 CANInitStruct.CAN_ROP = DISABLE; // Прием собственных пакетов отключено 

	 CANInitStruct.CAN_SAP = DISABLE; // Подтверждение приема отключено 

	 CANInitStruct.CAN_STM = DISABLE; // Режим самотестирования отключен 

	 CANInitStruct.CAN_ROM = DISABLE; // Режим "только чтение" отключен 

	 CANInitStruct.CAN_PSEG = CAN_PSEG_Mul_2TQ; // Битовый сегмент. Длительность PS 

	 CANInitStruct.CAN_SEG1 = CAN_SEG1_Mul_4TQ; // Битовый сегмент. Длительность PBS1

	 CANInitStruct.CAN_SEG2 = CAN_SEG2_Mul_3TQ; // Битовый сегмент. Длительность PBS2 CANInitStruct.CAN_SJW = CAN_SJW_Mul_2TQ; // Интервал перестройки сегментов 

	 CANInitStruct.CAN_SB = CAN_SB_1_SAMPLE; // Режим выборки 

	 CANInitStruct.CAN_BRP = 15; // Предделитель тактовой частоты 

	 CANInitStruct.CAN_OVER_ERROR_MAX = 255; // Максимальное значение счетчика ошибок до установки флага

Фрагмент кода 1

3. Настроить аппаратные прерывания. В приведённом проекте они использованы не будут.

4. Активировать модуль:

// Включение модуля 

	 CAN1 CAN_Cmd(MDR_CAN1, ENABLE);

Фрагмент кода 2

Для передачи данных в стандартной библиотеке SPL предусмотрена специальная структура CAN_TxMsgTypeDef, которая настраивает кадр (фрейм) передающих данных:

 // Формирование кадра данных 

	 CAN_TxMsgTypeDef tx_frame; 

	 tx_frame.ID = 0x19ABFFFF; // Идентификатор кадра данных 

	 tx_frame.PRIOR_0 = 1; // Приоритет кадра данных 

	 tx_frame.IDE = CAN_ID_STD; // Формат кадра данных - стандартный 

	 tx_frame.DLC = 1; // Длина поля данных (в байтах) 

	 tx_frame.Data[0] = 0x000000AA; // Первые четыре байта данных 

	 tx_frame.Data[1] = 0x00000000; // Вторые четыре байта данных

Фрагмент кода 3

При настройке стандартного идентификатора (содержит 11 бит) кадра данных следует помнить, что, согласно спецификации, для правильной настройки нужно задействовать биты с 18-го по 28-й. В рассматриваемой программе для стандартного идентификатора было взято число 0x19ABFFFF, и старшие 11 бит двоичного представления будут являться стандартным идентификатором.

Для передачи сформированного кадра необходимо воспользоваться следующую функцию:

// Передача кадра 

	 CAN_Transmit(MDR_CAN1, TX_BUFFER_NUMBER, &tx_frame);

Фрагмент кода 4

Основной код готов. Однако, если в проекте необходимо принимать данные по CAN, то для этого используется буфер:

// Настройка буфера на прием кадров 

	 CAN_Receive(MDR_CAN1, RX_BUFFER_NUMBER, DISABLE); // Третий аргумент отвечает за возможность перезаписи принятых данных

Фрагмент кода 5

И настройка структуры CAN_RxMsgTypeDef для приёма данных описывается следующим образом:

// Структура для приема кадра 

	 CAN_RxMsgTypeDef rx_frame; 

	 // Извлечение данных из буфера 

	 CAN_GetRawReceivedData(MDR_CAN1, RX_BUFFER_NUMBER, &rx_frame);

Фрагмент кода 6

Приём кадра данных осциллографом. Разбор кадра

Для подключения осциллографа при анализе обмена используются линии CAN_H и CAN_L. На рисунке 2 показано расположение этих линий на стандартном разъеме DB9F:

Рисунок 2 - Расположение линий CAN на разъеме DB9F

При подключении осциллографа к микроконтроллеру, он будет отображать непрерывный сигнал с кадром данных, который был сформирован в программе. Примерный вид и разбор кадра приведены на рисунке 3:

Рисунок 3 - Осциллограмма кадра данных CAN и его разбор

Пояснения:

Бит sof указывает на начало передачи кадра.

Бит RTR определяет тип кадра.

Бит IDE определяет формат кадра.

Бит R0 зарезервированный, и согласно протоколу должен иметь доминантное значение, то есть логический “0”.

Объем кадра в приведенном проекте равен одному байту, это значение задавалось в поле DLС при формировании кадра в коде.

На основании выбранного объема кадра как раз-таки виден один байт информации, который был задан программно.

При увеличении объема кадра DLC, который может быть в диапазоне от одного до восьми, будет наблюдаться расширение кадра пропорционально введенному количеству байт, а сами байты информации могут задаваться в конфигурационных полях tx_frame.Data[0] и tx_frame.Data[1]

Frame Format

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

Рисунок 4 - Структура стандартного и расширенного кадров данных CAN

Прерывания

Запрос на прерывание передачи (флаг CAN_TX[x] в регистре MDR_CANx→TX) происходит, когда разрешенный буфер на передачу НЕ имеет запроса на отправку сообщения (TX_REQ = 0, регистр MDR_CANx→BUF_CON[x])