Модуль CAN в микроконтроллерах PIC18

Views: 5720

Введение

  CAN последовательный интерфейс связи, который эффективно поддерживает распределенное управление в реальном масштабе времени с высокой помехозащищенностью. Протокол связи полностью определен Robert Bosch GmbH, в спецификации требований CAN 2.0B от 1991 года.

  Область применения CAN протокола: от высокоскоростных сетей связи до замены жгутов электропроводов в автомобиле. Высокая скорость передачи данных (до 1Мбит/с), хорошая помехозащищенность протокола, защита от неисправности узлов – делают шину CAN, подходящей для индустриальных приложений управления типа DeviceNet.

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

 Логика шины работает по механизму «монтажное И», в котором ‘recessive’ бит соответствует логической единицы, а ‘dominant’ логическому нулю. Пока ни один узел не формирует ‘dominant’ бит, шина находится в ‘recessive’ состоянии, но ‘dominant’ бит от любого узла создает ‘dominant’ состояние шины. Поэтому при выборе среды передачи данных, необходимо определить какое состояние будет ‘dominant’, а какое – ‘recessive’. Одним из наиболее распространенных и дешевых вариантов является пара скрученных проводов. Линии шины тогда называются CANH и CANL и могут быть подключены непосредственно к устройствам. Не существует никакого дополнительного стандарта на среду передачи данных.

При использовании, в качестве линии связи, пары скрученных проводов с нагрузочными резисторами на концах, можно получить максимальную скорость передачи данных 1Мбит/с, при длине линии около 40м. Для линий связи протяженностью более 40 метров необходимо снизить скорость передачи данных (для линии 1000м скорость шины должна быть не более 40кбит/с). Из-за дифференциального характера линии связи, шина CAN мало чувствительна к электромагнитным помехам. Экранирование шины значительно снизит воздействие внешнего электромагнитного поля, что особенно важно для высокоскоростных режимов работы.

Двоичная информация кодируется NRZ кодом (низкий уровень – ‘dominant’, высокий уровень ‘recessive’). Для гарантированной синхронизации данных всеми узлами шины используется наполняющий бит. При последовательной передаче пяти бит одинаковой полярности, передатчик вставляет один дополнительный бит противоположной полярности перед передачей остальных битов. Приемник также проверяет полярность и удаляет дополнительные биты.

В CAN протоколе при передаче данных приемные узлы не адресуются, а указывается идентификатор передатчика. С помощью идентификатора указывается содержание сообщения (например – обороты, температура двигателя и т.д.). Идентификатор дополнительно указывает приоритет сообщения. Меньшее бинарное значение идентификатора – более высокий приоритет.

При коллективном доступе к шине используется неразрушающий арбитраж с опросом состояния шины. Перед началом передачи данных узел проверяет состояние шины (отсутствие активности на шине). При начале передаче сообщения узел становится управляющим шины, все остальные узлы переходят в режим приема. Каждый узел выдает подтверждение приема, проверяет идентификатор сообщения, обрабатывает или удаляет принятые данные. Если два или более узлов начинают передачу данных одновременно, поразрядный арбитраж позволяет избежать конфликта на шине. Каждый узел выдает на шину свой идентификатор ( старший бит формируется первым) и контролирует ее состояние. Если узел посылает ‘recessive’ бит, а читает ‘dominant’, значит арбитраж потерян и узел переключается в режим приема. Это происходит тогда, когда идентификатор конкурирующего узла имеет меньшее бинарное значение. Таким образом, узел с высоким приоритетом выигрывает арбитраж, без необходимости повторять сообщение. Все остальные узлы будут пытаться передать сообщение после освобождения шины. Данный механизм не позволяет передавать одновременно сообщения с одинаковым идентификатором, поскольку ошибки могут возникнуть позже.

Оригинальная спецификация CAN (Версии 1.0, 1.2 и 2.0А) определяет длину идентификатора 11 бит (2048 возможных вариантов). Затем, технические требования были изменены, чтобы уйти от указанного ограничения, и в версии CAN 2.0B длина идентификатора может быть 11 или 29 бит (536 миллионов вариантов). Версия CAN 2.0B, в других документах может называться расширенная версия CAN.

1.1 Стандартная и расширенная версия CAN

Сообщения, содержащие 11-разрядный идентификатор, называются стандартными и соответствуют спецификации технических требований к CAN 2.0A. Возможно использовать всего 2048 различных идентификаторов (0 – 2047), из которых 16 идентификаторов с наименьшим приоритетом зарезервированы (2032 – 2047).

 В расширенной версии структура сообщения, согласно техническим требованиям CAN 2.0B, может иметь 29 разрядный идентификатор. 29 разрядный идентификатор состоит из 11 бит стандартного и дополнительных 18 бит расширенного идентификатора.

CAN модули версии 2.0А могут только передавать или принимать данные. Версия 2.0B позволяет активным узлам сделать удаленный запрос и получить данные от нужного устройства, используя расширенное сообщение.

1.2 Модуль CAN с основными функциями и полнофункциональный CAN модуль

Есть еще одна характеристика CAN модуля, которая характеризует интерфейс между CAN и MCU.
В CAN модуле с основными функциями аппаратно реализуются функции приема передачи и поразрядная проверка потока данных. На программном уровне выполняется фильтрация и проверка сообщений, управление передачей данных и многое другое. Нагрузка на MCU в таких устройствах значительна, они могут использоваться при низких скоростях передачи данных и малой информационной нагрузки (присутствуют несколько типов сообщений в сети). Преимуществами устройств с основными функциями CAN модуля является низкая стоимость.

Полнофункциональный модуль CAN аппаратно поддерживает протокол шины, включая фильтрацию принятия и управление передачей сообщений. CAN модули данного типа при работе имеют несколько целей по приему/передаче данных в стандартном или расширенном формате. На этапе инициализации определяются цели работы CAN модуля, таким образом, нагрузка на MCU сокращена. Полнофункциональные модули CAN могут использоваться при высоких скоростях передачи данных и большом информационном потоке.

1.3 ISO модель

ISO/OSI эталонная модель используется для того, чтобы определить уровни протокола системы связи. На самом верхнем уровне модели находятся приложения, которые должны связываться друг с другом. На самом низком уровне модели, расположена физическая среда, обеспечивающая электрическую сигнализацию связи.

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

Полнофункциональный CAN модуль поддерживает два нижних уровня эталонной модели сети:

• – Управление приемом/передачей данных
• – управление логической связью (LCC подуровень);
• – среднее управление доступом (MAC подуровень).
• – Физический уровень
• – физическая сигнализация (PLS подуровень).

LCC подуровень обеспечивает:

• фильтрацию сообщений;
• уведомление о перегрузке;
• управление обнаружением ошибок.

MAC подуровень обеспечивает управление средой передачи:

• получение сообщений;
• выполнение арбитража;
• проверка ошибок;
• передача сообщений и сигналов ошибки;
• выдает заключение о неисправности.

MAC подуровень получает сообщения от LCC для передачи по шине и передает сообщения, принятые с шины в LCC подуровень. В пределах подуровня MAC определяется отсутствие активности на шине CAN для начала передачи сообщения. Заключение о неисправности является механизмом самоконтроля при постоянном возникновении кратковременных ошибок.

Физический уровень определяет фактическую передачу бит между различными устройствами с выполнением всех электрических требований. PLS подуровень определяет физическую структуру сигнала и контролирует:

• синхронизацию бит;
• кодирование бит;
• общую синхронизацию.

Низшие уровни протокола определяют фактический тип интерфейса связи: витая пара, волоконный световод и т.д. В пределах одной сети физический уровень должен быть одинаков для всех узлов. Характеристики драйвера физического уровня не определены в спецификации на CAN протокол, чтобы позволить оптимизировать среду передачи для конкретных приложений.

ISO/OSI эталонная модель CAN шины

1.4 Характеристики CAN модуля

CAN модуль – контроллер связи, поддерживающий протокол CAN 2.0A/B, описанный в технической спецификации фирмы BOSCH. Полнофункциональный модуль CAN аппаратно поддерживает протоколы CAN 1.2, CAN 2.0A активную и пассивную версию CAN 2.0B.
Дополнительные характеристики CAN модуля:

• стандартный и расширенный тип сообщений;
• длина данных в сообщении от 0 до 8 байт;
• программируемая скорость передачи информации до 1Мбит/с;
• поддержка удаленного запроса данных;
• два буфера приемника с двойной буферизацией данных;
• 6 полных приемных фильтров (стандартный/расширенный идентификатор), 2 фильтра связаны с сообщениями высокого приоритета, 4 с сообщениями низкого приоритета;
• 2 полных маски принимаемых сообщений;
• 3 передающих буфера, с возможностью указания приоритета и аварийного прекращения передачи;
• программируемая возможность пробуждения из SLEEP режима со встроенным НЧ фильтром;
• программируемый генератор тактовых импульсов;
• программируемый контроль шлейфа, синхронизирующий функцию самоконтроля;
• гибкая система прерываний от CAN модуля;
• низкое энергопотребление в SLEEP режиме.

2. Работа CAN модуля

В этом разделе будет рассмотрена работа CAN модуля и поддерживаемые форматы сообщений.

2.1 Краткий обзор CAN модуля

CAN модуль укрупнено состоит из:

• контроллера протокола;
• буфера сообщений.

Типовое подключение к CAN шине узлов и терминаторов

 2.2 Контроллер CAN протокола

Контроллер протокола состоит из нескольких функциональных блоков, показанных на рисунке.
Основной частью контроллера является управляющий блок (FSM). Это последовательный конечный автомат, малого разрешения, с изменением управляющих сигналов при различных типах сообщений и состояния передачи/приема данных. FSM имеет следующие функции:

• управление последовательным потоком данных между TX/RX и сдвиговым регистром;
• вычисление и контроль CRC;
• управление состоянием шины;
• обработка ошибок (EML);
• управление параллельным потоком данных между сдвиговым регистром и буфером;
• выполнение арбитража;
• сигнализация об ошибках согласно CAN протоколу;
• автоматическая повторная передача сообщений.

Интерфейс передачи данных от контроллера к буферу – параллельный 8-разрядный. Сообщение разбивается на байты и побайтно загружается/читается в/из сдвиговый регистр для передачи/приема данных. FSM контролирует какая часть сообщения принята/передана.
Регистр циклического контроля избыточности (CRC) формирует CRC код, который побайтно будет передан при передаче данных, и проверяет код CRC при получении сообщения.
Логика управления обработкой ошибок (EML) формирует сигнал о неисправности CAN устройства. Принимающий и передающий счетчики ошибок увеличиваются и уменьшаются от разрядного процессора потока.
Согласно значениям счетчиков ошибок CAN модуль может находиться в состоянии:

• активной ошибки
• пассивной ошибки
• отключен от шины

С помощью BTL осуществляется контроль линейного входа шины, обрабатывается состояние шины и выполняется синхронизация бита согласно CAN протоколу. BTL синхронизируется при переходе от ‘recessive’ к ‘dominant’ биту. BTL также обеспечивает программируемые сегменты времени выборки элемента для компенсации задержки времени распространения и смещения фазы. Программирование BTL зависит от скорости передачи данных и внешнего физического времени запаздывания.

2.2.1 Функциональные возможности контроллера CAN модуля

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

• стандартное сообщение;
• расширенное сообщение;
• удаленный запрос данных;
• ошибка;
• перезагрузка;
• простой шины.

В следующем разделе будет описана структура всех типов сообщений.

3. Структура сообщений

3.1 Стандартное сообщение

Стандартное сообщение формируется, когда узел желает передать данные. На рисунке представлена структура стандартного сообщения.

ПРОДОЛЖЕНИЕ СЛЕДУЕТ….

Это может быть интересно