Здесь приведен раздел даташита Atmel [1], посвященный контроллеру CAN в микроконтроллерах ARM7 на ядре ARM7TDMI. Пример практического использования интерфейса CAN в этих микроконтроллерах см. в статье [2].

Контроллер CAN предоставляет все возможности, требуемые для последовательного обмена данными по протоколу CAN, как он был определен Robert Bosch GmbH, стандарт CAN ISO/11898A (2.0 Part A и 2.0 Part B) для высоких скоростей и ISO/11519-2 для низких скоростей. Контроллер CAN может обработать все типы фреймов (Data, Remote, Error и Overload), и достичь скоростей обмена до 1 Mbit/sec.

К контроллеру CAN осуществляется доступ через регистры конфигурации. Реализовано 8 независимых объектов сообщений (так называемые почтовые ящики, mailbox).

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

Любой mailbox может быть запрограммирован для передачи. Одновременно может быть разрешено несколько передающих mailbox-ов. Приоритет может быть задан для каждого mailbox независимо.

Внутренний 16-битный таймер используется для привязки метки времени к каждому принятому и отправленному сообщению. Этот таймер начинает счет с момента разрешения работы контроллера CAN. Этот счетчик может быть сброшен приложением или автоматически после приема в последний mailbox, когда установлен Time Triggered Mode.

Контроллер CAN предоставляет оптимизированные возможности для поддержки протокола Time Triggered Communication (TTC).

Рис. 36-1. Блок-схема контроллера CAN.

Рис. 36-2. Блок-диаграмма приложения CAN.

[От чего зависит работа CAN]

Порты ввода/вывода. Выводы, которыми контроллер CAN обменивается данными с внешним миром (см. таблицу 36-1), могут быть мультиплексированы с портами (выводами) микроконтроллера (ножки GPIO). Программист должен сначала запрограммировать контроллер PIO, чтобы присвоить нужные выводы CAN к своей функции как периферийного устройства CAN. Если сигналы CAN не используются приложением, то они могут быть запрограммированы контроллером PIO для других целей.

Таблица 36-1. Выводы сигналов CAN у процессоров AT91SAM7X (AT91SAM7X128, AT91SAM7X256, AT91SAM7X512).

Управление питанием. Перед использованием CAN программист должен сначала разрешить тактирование контроллера CAN с помощью контроллера управления питанием (Power Management Controller, PMC). Для контроллера CAN имеется режим пониженного энергопотребления (Low-power Mode): если приложению не нужно работать через интерфейс CAN, то тактирование CAN может быть остановлено, и впоследствии запущено снова, когда CAN опять потребуется. Перед остановкой тактирования контроллер CAN должен быть переведен в режим Low-power для завершения текущей передачи. Для выхода из режима пониженного энергопотребления сначала запускается тактирование, и потом приложение должно запретить Low-power Mode контроллера CAN.

Прерывания. Сигнал прерывания CAN может быть соединен с одним из внутренних источников продвинутого контроллера прерывания (Advanced Interrupt Controller, AIC). Использование прерывания CAN требует предварительного программирования AIC. Имейте в виду, что не рекомендуется использовать линию прерывания CAN в режиме чувствительности к перепаду.

Практический пример программирования см. в статье [2].

[Обзор протокола CAN]

Controller Area Network (CAN) является последовательным протоколом обмена данными с нескольким главными устройствами на шине (multi-master), который эффективно поддерживает управление в реальном времени с очень высоким уровнем безопасности на скоростях до 1 Mbit/s включительно.

Протокол CAN поддерживает 4 различные типа фрейма:

Data: эти фреймы переносят данные между узлами передатчика и приемника. Полная длина фрейма составляет 108 для стандартного фрейма и 128 бит для расширенного фрейма.
Remote: узел назначения может запросить данных из источника путем отправки фрейма remote с идентификатором, который совпадает с идентификатором требуемого фрейма данных. Затем соответствующий узел данных источника отправляет фрейм data как ответ на запрос этого узла.
Error: фрейм error генерируется любым узлом, когда он детектирует ошибку шины.
Overload: этот фрейм предоставляет дополнительную задержку между предыдущим и последующим фреймами data или remote.

Контроллер Atmel CAN предоставляет для CPU полный функционал протокола CAN V2.0 Part A и V2.0 Part B. Это минимизирует нагрузку CPU при осуществлении обмена по шине. Слой связи уровня данных (Data Link Layer) и часть физического слоя обрабатываются автоматически самим контроллером CAN.

CPU читает или записывает данные или сообщения через mailbox-ы. Для каждого mailbox назначается идентификатор. Контроллер CAN создает или декодирует сообщения данных, чтобы построить или обработать фреймы data шины. Фреймы remote, error и overload автоматически обрабатываются контроллером CAN под общим управлением программы приложения.

Организация mailbox. Модуль CAN имеет 8 буферов, которые называются mailbox-ами. Для каждого активного mailbox-а определяется идентификатор, который соответствует идентификатору CAN. Идентификаторы сообщения могут совпадать со стандартным идентификатором фрейма или расширенным идентификатором фрейма. Эти идентификаторы определяются первый раз при инициализации CAN, но могут быть динамически реконфигурироваться позже, так что mailbox может обслуживать новое семейство сообщений. Несколько mailbox-ов могут быть сконфигурированы с одинаковым ID.

Каждый mailbox может быть сконфигурирован в режиме приема или передачи независимо от других mailbox-ов. Тип mailbox-а определяется полем MOT в регистре CAN_MMRx.

Процедура приема или отбрасывания сообщения. Если установлено поле MIDE в регистре CAN_MIDx, то mailbox может обработать расширенный формат идентификатора; иначе mailbox поддерживает стандартный формат идентификатора. Как только принято новое сообщение, его идентификатор (ID) маскируется значением регистра CAN_MAMx и сравнивается со значением CAN_MIDx. Если сообщение принято (в том смысле, что не отфильтровано идентификатором), этот ID сообщения копируется в регистр CAN_MIDx.

Рис. 36-3. Процедура фильтрации приема сообщения.

Если mailbox предназначен для приема нескольких сообщений (семейства сообщений) с разными ID, то маска в регистре CAN_MAMx должна маскировать нулями переменную часть в семействе идентификаторов ID. Как только сообщение принято, приложение должно декодировать маскированные биты в CAN_MIDx. Чтобы ускорить декодирование, маскированные биты группируются в регистре идентификатора семейства (family ID register, CAN_MFIDx).

Например, если следующие идентификаторы обрабатываются одним и тем же mailbox-ом

ID0 101000100100010010000100 0 11 00b
ID1 101000100100010010000100 0 11 01b
ID2 101000100100010010000100 0 11 10b
ID3 101000100100010010000100 0 11 11b
ID4 101000100100010010000100 1 11 00b
ID5 101000100100010010000100 1 11 01b
ID6 101000100100010010000100 1 11 10b
ID7 101000100100010010000100 1 11 11b

то CAN_MIDx и CAN_MAMx этого mailbox-а должны быть инициализированы следующими значениями (напомню, что x соответствует номеру mailbox-а от 0 до 7):

CAN_MIDx = 001 101000100100010010000100 x 11 xxb
CAN_MAMx = 001 111111111111111111111111 0 11 00b

Если mailbox примет сообщение с ID6, то CAN_MIDx и CAN_MFIDx установятся следующим образом:

CAN_MIDx  = 001 101000100100010010000100 1 11 10b
CAN_MFIDx = 000 000000000000000000000000 0 01 10b

Таким образом, в регистре CAN_MFIDx находится номер сообщения в группе, в данном примере это будет число от 0 до 7, поскольку замаскировано 3 бита адреса.

Эту возможность удобно использовать для быстрого декодирования адреса сообщения. Если приложение свяжет обработчик с каждым ID сообщения, то обработчики можно поместить в массив указателей на функцию:

void (*pHandler[8])(void);

Когда сообщение принимается, то соответствующий обработчик может быть вызван с использованием регистра CAN_MFIDx, и здесь уже не нужно проверять маскированные биты:

unsigned int MFID0_register;

// Get_CAN_MFID0_Register() вернет значение из регистра CAN_MFID0:
MFID0_register = Get_CAN_MFID0_Register();
pHandler[MFID0_register]();

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

Можно также сконфигурировать mailbox в потребительском режиме (Consumer Mode). В этом режиме после каждого запроса передачи будет автоматически отправлен фрейм remote. Первый принятый ответ сохраняется в соответствующих регистрах данных.

Несколько mailbox-ов могут быть соединены в цепочку для буфера приема. Они должны быть сконфигурированы с одинаковым ID в режиме приема, кроме последнего mailbox, который может быть сконфигурирован в режиме приема с перезаписью (Receive with Overwrite Mode). Этот последний mailbox может использоваться для детектирования переполнения буфера.

Mailbox передачи. Когда передается сообщение, длина сообщения и его данные записываются в передающий mailbox с корректным идентификатором. Для каждого передающего mailbox назначается приоритет. Контроллер автоматически отправляет в первую очередь сообщение с самым высоким приоритетом (приоритет настраивается в поле PRIOR регистра CAN_MMRx).

Также есть возможность сконфигурировать mailbox в режиме продюсера (Producer Mode). В этом режиме когда принят фрейм remote, то данные mailbox-а будут отправлены автоматически. Путем разрешения этого режима продюсер может использовать только один mailbox вместо двух: один для детектирования фрейма, и один для отправки ответа.

Блок обработки времени. В контроллер CAN интегрирован автоматически инкрементирующийся 16-битный таймер. Счетчик в нем управляется по тактам бит шины CAN. Таймер разрешается вместе с разрешением контроллера CAN (когда устанавливается бит CANEN в регистре CAN_MR). Счетчик таймера автоматически очищается в следующих случаях:

• После сброса.
• Когда контроллер CAN находится в режиме низкого энергопотребления (Low-power Mode, установлен бит LPM в регистре CAN_MR и установлен бит SLEEP в регистре CAN_SR).
• После сброса контроллера CAN (с помощью бита CANEN в регистре CAN_MR).
• В режиме срабатывания по таймеру (Time-triggered Mode), когда сообщение принято последним mailbox (фронт нарастания сигнала MRDY в регистре CAN_MSR_{последний_номер_mailbox}).

Приложение может также сбросить внутренний таймер установкой бита TIMRST в регистре CAN_TCR. Текущее значение внутреннего таймера всегда доступно путем чтения регистра CAN_TIM.

Когда таймер при свободном счете переходит от значения FFFFh к 0000h, то в регистре CAN_SR устанавливается флаг переполнения таймера TOVF (Timer Overflow). Бит TOVF в регистре CAN_SR очищается при чтении регистра CAN_SR. В зависимости от соответствующей маски прерывания в регистре CAN_IMR, может быть сгенерировано прерывание при установке бита TOVF.

В сети CAN некоторые устройства CAN могут иметь счетчик, у которого разрядность больше. В этом случае приложение может также решить заморозить внутренний счетчик таймера, когда он достигнет FFFFh, и ждать условия перезапуска от другого устройства. Эта возможность разрешается установкой бита TIMFRZ в регистре CAN_MR. Регистр CAN_TIM заморозится на значении FFFFh. Ранее описанные условия очистки счетчика перезапустят таймер. Сработает прерывание переполнения таймера (TOVF).

Чтобы отслеживать активность шины CAN, регистр CAN_TIM копируется в регистр CAN_TIMESTP после каждого начала фрейма или окончания фрейма, и когда сработает прерывание TSTP. Если установлен бит TEOF в регистре CAN_MR, то значение счетчика захватывается по каждому окончанию фрейма, иначе значение будет захватываться в начале фрейма (Start Of Frame). В зависимости от соответствующей маски в регистре CAN_IMR, генерируется прерывание, когда установлен бит TSTP в регистре CAN_SR. Бит TSTP очищается чтением регистра CAN_SR.

Блок обработки времени может работать в одном из двух следующих режимов:

• Timestamping: значение внутреннего счетчика таймера захватывается на каждом начале фрейма или на каждом конце фрейма.
• Time Triggered: операция mailbox transfer срабатывает, когда внутренний таймер достигает триггера mailbox.

Режим Timestamping разрешается очисткой поля TTM в регистре CAN_MR. Режим Time Triggered разрешается установкой поля TTM в регистре CAN_MR.

[Стандартные функции CAN 2.0]

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

Параметры интервалов времени формирования бита. Стандарт протокола CAN делит номинальное время бита на 4 разных сегмента:

Рис. 36-4. Разделение времени бит шины CAN.

TIME QUANTUM: квант времени (TIME QUANTUM, TQ) это фиксированная единица времени, вычисленная от периода MCK. Общее количество TIME QUANTA во времени бита программируется от 8 до 25.

SYNC SEG: сегмент синхронизации. Эта часть бит времени используется для синхронизации различных узлов шины. Ожидается, что перепад сигнала появится в этом сегменте времени. Его длина равна 1 TQ.

PROP SEG: сегмент распространения. Эта часть времени бита используется для компенсации физической задержки в пределах сети. Это двойная сумма времени распространения сигнала по шине, задержки входного компаратора и задержки выходного драйвера. Программируется от 1 до 8 TQ.

Этот параметр определяется в поле PROPAG регистра настройки скорости CAN (CAN Baudrate Register, CAN_BR).

PHASE SEG1, PHASE SEG2: сегменты фазы 1 и 2. Это сегменты фазы буфера, используемые для компенсации ошибок фазы перепадов. Эти сегменты могут быть продлены (PHASE SEG1) или укорочены (PHASE SEG2) при ресинхронизации. PHASE SEG1 программируется в пределах от 1 до 8 TQ. PHASE SEG2 будет длиной как минимум времени обработки информации (Information Processing Time, IPT), и не может быть больше чем длина PHASE SEG1.

Эти параметры определены в полях PHASE1 и PHASE2 регистра настройки скорости CAN (CAN_BR).

IPT: время обработки информации. Время обработки информации (Information Processing Time, IPT) это время, требуемое для логики, чтобы определить уровень бита во время выборки сигнала на шине данных. Интервал IPT начинается на точке выборки, измеряется в TQ и зафиксирован на величине 2 TQ для Atmel CAN. Поскольку PHASE SEG2 также начинается в точке выборки и в последнем сегменте времени бита, то PHASE SEG2 не должен быть меньше IPT.

SAMPLE POINT: точка выборки. Точка выборки это момент во времени, когда уровень сигнала на шине считывается и интерпретируется как значение соответствующего бита. Место этого момента по окончании PHASE_SEG1.

SJW: ширина прыжка ресинхронизации. Этот параметр определяет предел удлинения или укорачивания сегментов фазы.

SJW программируется до минимума PHASE SEG1 и 4 TQ.

Если поле SMP в регистре CAN_BR установлено, то приходящий поток бит оцифровывается три раза за половину периода тактовой частоты CAN, центрируясь на точке выборки.

В контроллере CAN длина бита на шине CAN определяется параметрами BRP, PROPAG, PHASE1 и PHASE2.

t_BIT = t_CSC + t_PRS + t_PHS1 + t_PHS2

Квант времени (TQ) вычисляется по следующей формуле:

t_CSC = (BRP + 1) / MCK

Примечание: поле BRP должно быть в диапазоне field [1, 0x7F], например значение BRP = 0 не допустимо.

t_PRS = t_CSC * (PROPAG + 1)
t_PHS1 = t_CSC * (PHASE1 + 1)
t_PHS2 = t_CSC * (PHASE2 + 1)

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

t_SJW = t_CSC * (SJW + 1)

Рис. 36-5. Временные диаграммы бит шины CAN.

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

Эффект ресинхронизации тот же, что и у жесткой синхронизации, когда величина ошибки фазы на перепаде дает ресинхронизацию меньше или равной запрограммированной величине ширины прыжка ресинхронизации (t_SJW).

Когда величина ошибки фазы больше, чем ширина прыжка ресинхронизации, и

• ошибка фазы положительна, тогда PHASE_SEG1 удлиняется на величину, равную ширине прыжка ресинхронизации.
• ошибка фазы отрицательна, тогда  PHASE_SEG2 укорачивается на величину, равную ширине прыжка ресинхронизации.

Рис. 36-6. Ресинхронизация CAN.

Режим Autobaud. Функция автоопределения скорости (autobaud) разрешается путем установки поля ABM в регистре CAN_MR. В этом режиме контроллер CAN только слушает сигналы на шине без подтверждения принятых сообщений. При этом обновляются флаги ошибок. Параметры времени бита могут быть подстроены, пока ошибки не исчезнут (т. е. пока не найдена хорошая конфигурация). В этом режиме счетчик ошибок замораживается. Чтобы перейти обратно в стандартный режим, бит ABM в регистре CAN_MR должен быть очищен.

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

• Ошибка CRC (бит CERR в регистре CAN_SR): с применением CRC передатчик вычисляет контрольную сумму для последовательности бит от бита начала фрейма (Start of Frame bit) до окончания поля данных. Последовательность бит CRC передается в поле CRC фрейма Data или Remote.
• Ошибка вставки неинформационных бит, ошибка Bit-stuffing (бит SERR в регистре CAN_SR): если узел детектирует шестой последовательно одинаковый бит в течение области бит-стаффинга фрейма, то будет сгенерирован фрейм ошибки (Error Frame), начиная со следующего времени бита.
• Ошибка бита (бит BERR в регистре CAN_SR): происходит, если передатчик посылает доминантный бит, но детектирует рецессивный бит на шине, или если он посылает рецессивный бит, но детектирует доминантный бит на шине. Генерируется фрейм ошибки в момент следующего времени бита.
• Ошибка формы, Form Error (бит FERR  в регистре CAN_SR): если передатчик детектирует доминантный бит в одном из фиксировано форматированных сегментов разделителя контрольной суммы (CRC Delimiter), разделителя подтверждения (ACK Delimiter) или маркера конца фрейма (End of Frame), то происходит ошибка формы, и генерируется фрейм ошибки.
• Ошибка подтверждения, Acknowledgment error (бит AERR в регистре CAN_SR): передатчик проверяет слот подтверждения (Acknowledge Slot), который отправляется передающим узлом как рецессивный бит - в нем содержится доминантный бит. Если такое произошло, то как минимум один другой узел корректно принял фрейм. Если нет, то происходит Acknowledge Error, и передатчик начнет передачу фрейма ошибки со следующего времени бита.

Ограничение ошибок (Fault Confinement). Чтобы отделить друг от друга временные и постоянные отказы, контроллер CAN имеет два счетчика ошибок: REC (Receive Error Counter, счетчик ошибок приема) и TEC (Transmit Error Counter, счетчик ошибок передачи). Эти два счетчика инкрементируются при детектировании ошибок, и декрементируются при корректных передачах или приемах соответственно. В зависимости от значений счетчиков меняется состояние узла: начальное состояние контроллера CAN будет Error Active, это означает, что контроллер может отправить флаги Error Active. Контроллер меняет состояние на Error Passive, если есть накопление ошибок. Если контроллер CAN терпит отказ, или если есть экстремальное накопление ошибок, то состояние переходит в выключение шины, Bus Off.

Рис. 36-7. Режим ошибки линии (Line Error Mode).

Узел Error Active принимает участие в обмене по шине, и посылает фрейм активной ошибки, когда контроллер CAN детектирует ошибку.

Узел Error Passive не может отправлять фрейм активной ошибки. Он принимает участие в обмене по шине, но когда произошла ошибка, будет отправлен фрейм пассивной ошибки. Также, после передачи, блок Error Passive ждет перед началом будущей передачи.

Блоку Bus Off не позволено никак влиять на шину.

Для ограничения ошибок реализовано два счетчика ошибок (TEC и REC). Эти счетчики доступны через регистр CAN_ECR. Состояние контроллера CAN автоматически обновляется в соответствии со значением этих счетчиков. Если контроллер CAN находится в состоянии Error Active, то устанавливается бит ERRA в регистре CAN_SR. Будет заказан запуск соответствующего прерывания, если оно не замаскировано в регистре CAN_IMR. Если контроллер CAN в режиме Error Passive, то устанавливается бит ERRP в регистре CAN_SR, и остается заказанным прерывание, если в регистре CAN_IMR установлен бит ERRP. Если CAN находится в режиме Bus Off, то устанавливается бит BOFF в регистре CAN_SR. Как и для битов ERRP и ERRA, ожидается обработка прерывания, пока бит BOFF установлен в регистре CAN_IMR.

Когда один из счетчиков ошибок превысит значение 96, увеличивающаяся скорость возникновения ошибок показывается битом WARN в регистре CAN_SR, но узел остается в состоянии Error Active. Соответствующее прерывание ожидает обработки, когда это прерывание установлено в регистре CAN_IMR.

Про ограничение ошибок (fault confinement) подробнее см. спецификацию стандарта Bosch CAN v2.0.

Обработчик прерывания ошибки. Биты WARN, BOFF, ERRA и ERRP (в регистре CAN_SR) представляют текущее состояние шины represent CAN, и эти биты не работают по принципу защелки. Эти биты напрямую отражают текущие значения счетчиков TEC и REC (находящихся в регистре CAN_ECR), как это описано в предыдущей секции "Ограничение ошибок (Fault Confinement)".

На базе этого, если эти биты используются как прерывание, пользовательский код может войти в прерывание и не увидеть соответствующее состояние в регистре статуса, если счетчики TEC и REC поменяли свое значение. Когда произошел вход в режим Bus Off, единственный способ выйти из этого состояния - 128 возникновений 11 последовательных рецессивных бит, или сброс контроллера CAN.

В режиме Error Active пользователь прочитает:

ERRA = 1
ERRP = 0
BOFF = 0

В режиме Error Passive пользователь прочитает:

ERRA = 0
ERRP = 1
BOFF = 0

В режиме Bus Off пользователь прочитает:

ERRA = 0
ERRP = 1
BOFF = 1

Пользовательский код с целью обработки прерывания CAN должен сделать следующее:

• В каждый момент времени разрешать прерывание только одного режима.
• Прочитать и проверить значения счетчиков REC и TEC в обработчике прерывания, чтобы определить текущее состояние.

Перегрузка (Overload). Перегрузка фрейма предоставляется для запроса узлом приемника задержки следующего фрейма Data или Remote ("Request overload frame", запрос перегрузки фрейма) или для сигнализации об определенных условиях ошибки ("Reactive overload frame", реактивная перегрузка фрейма), что соответственно связано с полем перерыва (intermission).

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

• Детектирование доминантного бита во время первых двух бит поля перерыва (intermission).
• Детектирование приемником доминантного бита в последнем бите EOF, или детектирование доминантного бита приемником или передатчиком на последнем бите ошибки или разграничителе перегрузки фрейма (overload frame delimiter).

Контроллер CAN может автоматически генерировать запрос фрейма перегрузки (overload frame) после каждого сообщения, отправленного в один из почтовых ящиков (mailbox) контроллера CAN. Эта функция разрешена установкой бита OVL в регистре CAN_MR.

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

[Режим пониженного энергопотребления (Low-power Mode)]

В режиме Low-power контроллер CAN не может передавать или принимать сообщения. Все почтовые ящики (mailbox) не активны.

В режиме Low-power установлен сигнал SLEEP в регистре CAN_SR; иначе установлен сигнал WAKEUP в регистре CAN_SR. Эти два поля взаимоисключающие, за исключением состояния после сброса контроллера CAN (после сброса оба бита WAKEUP и SLEEP залипают в состоянии 0). После сброса при включении питания режим Low-power запрещен и бит WAKEUP в регистре CAN_SR установлен только после 11 следующих друг за другом рецессивных бит на шине.

Разрешение Low-power Mode. Программа приложения может разрешить режим Low-power установкой бита LPM в глобальном регистре CAN_MR. Контроллер CAN войдет в режим Low-power, как только будут переданы все ожидающие отправки сообщения.

Когда контроллер CAN входит в режим Low-power, устанавливается сигнал SLEEP в регистре CAN_SR. В зависимости от соответствующей маски в регистре CAN_IMR, будет сгенерировано прерывание при установке бита SLEEP.

Сигнал SLEEP в регистре CAN_SR автоматически очищается, когда установится бит WAKEUP. Сигнал WAKEUP автоматически очищается, когда SLEEP устанавливается.

Прием запрещен, когда сигнал SLEEP устанавливается в лог. 1 в регистре CAN_SR. Важно отметить, что сообщения с более высоким приоритетом, чем последнее переданное сообщение могут быть получены между выдачей команды для установки бита LPM и входом в режим Low-power.

Как только произведен вход в режим Low-power, тактирование контроллера CAN может быть выключено программированием встроенного контроллера управления питанием (Power Management Controller, PMC). Контроллер CAN будет потреблять только статический ток.

Счетчики ошибок запрещены, когда сигнал SLEEP установится в лог.1.

Таким образом, чтобы войти в режим Low-power, программа приложения должна:

• Установить поле LPM в регистре CAN_MR.
• Подождать установки сигнала SLEEP.

После установки бита SLEEP может быть выключена тактовая частота контроллера CAN. Это выполняется программированием PMC.

Рис. 36-8. Разрешение Low-power Mode.

Выход из Low-power Mode. Контроллер CAN может проснуться после детектирования активности на шине CAN. Детектирование активности шины осуществляется внешним модулем, который может быть встроен в чип микроконтроллера. Когда получено оповещение об активности шины CAN, программное обеспечение запрещает режим Low-power путем программирования контроллера CAN.

Чтобы запретить режим Low-power, программа приложения должна:

• Разрешить тактирование контроллера CAN. Это осуществляется программированием PMC.
• Очистить поле LPM в регистре CAN_MR.

Контроллер CAN синхронизируется самостоятельно по активности шины путем проверки 11 последовательных "рецессивных" бит. Как только синхронизация произошла, устанавливается флаг WAKEUP в регистре CAN_SR.

В зависимости от соответствующей маски в регистре CAN_IMR, генерируется прерывание при установке бита WAKEUP. Бит SLEEP в регистре CAN_SR автоматически сбрасывается в лог. 0, когда бит WAKEUP устанавливается в лог. 1. И наоборот, сигнал WAKEUP автоматически сбросится в лог. 0, когда установится в лог. 1 бит SLEEP.

Если по шине не отправляется сообщение, тогда контроллер CAN может отправить сообщений на 11 бит позже запрета режима Low-power.

Если имеется активность на шине, когда режим Low-power запрещен, то контроллер CAN синхронизируется по активности шины в следующем межкадровом промежутке. Предыдущее сообщение теряется (см. рис. 36-9).

Рис. 36-9. Запрет Low-power Mode.

[Инициализация контроллера CAN]

После сброса при включении питания контроллер CAN запрещен. Активизация тактирования контроллера CAN должна быть запущена с помощью контроллера управления питанием (Power Management Controller, PMC), и линия прерывания контроллера CAN должна быть разрешена с помощью контроллера прерывания (AIC).

Контроллер CAN должен быть инициализирован в соответствии с параметрами сети CAN. Регистр CAN_BR определяет точку выборки во время периода времени бита. CAN_BR должен быть установлен перед тем, как контроллер CAN разрешен установкой бита CANEN в регистре CAN_MR.

Контроллер CAN разрешается установкой бита CANEN в регистре CAN_MR. На этой стадии внутренняя машина состояний контроллера CAN сбрасывается, счетчики ошибок сбрасываются в 0, флаги ошибок сбрасываются в 0.

Как только контроллер CAN разрешен, синхронизация шины осуществляется автоматически сканированием 11 рецессивных бит. Бит WAKEUP в регистре CAN_SR автоматически устанавливается в 1, когда контроллер CAN засинхронизировался (WAKEUP и SLEEP находятся в лог. 0 сразу после сброса).

Контроллер CAN может начать прослушивать сеть в режиме Autobaud. В этом случае счетчики ошибки заблокированы, и mailbox может быть сконфигурирован в режиме приема (Receive Mode). Путем сканирования флагов ошибок значение регистра CAN_BR синхронизируется с сетью. Как только будет обнаружено отсутствие ошибок, приложение запрещает режим Autobaud очисткой бита ABM в регистре CAN_MR.

Рис. 36-10. Возможная процедура инициализации.

[Обработка прерываний контроллера CAN]

Имеется 2 типа прерываний. Один тип прерывания связан с получением сообщения, и другой тип обрабатывает ошибки или связанные с системой источники прерывания.

Все источники прерывания могут маскироваться записью лог. 1 в соответствующие поля регистра CAN_IDR (маскирование означает запрет прерывания). Прерывания могут быть демаскированы (разрешены) записью лог. 1 в соответствующие поля регистра CAN_IER. После сброса при включении питания все источники прерывания запрещены (маскированы). Текущее состояние маски может быть проверено чтением регистра CAN_IMR.

Чтение регистра CAN_SR дает состояние всех источников прерывания.

Следующие события могут инициировать одно из двух видов прерываний:

• Прерывание, связанное с объектом сообщения

- Для приложения доступны регистры данных в объекте почтового ящика. В режиме приема (Receive Mode) было принято новое сообщение. В режиме передачи (Transmit - Mode) сообщение было успешно отправлено.
Отправленная передача была оборвана.

• Системные прерывания

- Прерывание Bus off: модуль CAN вошел в состояние выключения шины.
- Прерывание пассивной ошибки: модуль CAN входит в режим Error Passive.
- Error Active Mode: модуль CAN ни в режиме Error Passive, ни в режиме Bus Off.
- Прерывание Warn Limit: модуль CAN в режиме Error Active, но как минимум один из его счетчиков ошибок превысил значение 96.
- Прерывание Wake-up: генерируется после пробуждения и синхронизации с шиной.
- Прерывание Sleep: генерируется после разрешения режима Low-power, как только все ожидающие передачи сообщения будут отправлены.
- Прерывание переполнения внутреннего счетчика таймера: происходит когда счетчик таймера переходит со своего максимального значения в 0.
- Прерывание метки времени (Timestamp interrupt): генерируется после приема или передачи начала фрейма или по окончании фрейма. Значение внутреннего счетчика копируется в регистр CAN_TIMESTP.

Все прерывания очищаются путем очистки их источника, за исключением прерывания от переполнения счетчика внутреннего таймера и прерывания метки времени. Эти прерывания очищаются чтением регистра CAN_SR.

[Обработка сообщений контроллера CAN]

Обработка приема. Для конфигурирования почтовых ящиков (mailbox) с целью приема сообщений доступно 2 режима - режим приема (Receive Mode) и режим приема с перезаписью (Receive with Overwrite Mode). В Receive Mode первое принятое сообщение сохраняется в регистре данных mailbox. В Receive with Overwrite Mode последнее принятое сообщение сохраняется в mailbox.

Простой mailbox приема. Mailbox находится в Receive Mode, как только сконфигурировано поле MOT в регистре CAN_MMRx. Перед разрешением Receive Mode должны быть установлены идентификатор сообщения (Message ID) и маска допустимости сообщения (Message Acceptance Mask).

После того, как Receive Mode разрешен, флаг MRDY в регистре CAN_MSR автоматически очищается, пока не будет принято первое сообщение. Когда первое сообщение было принято mailbox, установится флаг MRDY. При установке флага MRDY будет ожидать обработки прерывание. Это прерывание может быть маскировано в зависимости от флага mailbox в глобальном регистре CAN_IMR.

Данные сообщения сохраняются в регистре данных mailbox, пока программа приложения не оповестит, что обработка принятых данных окончена. Это осуществляется запросом новой команды перемещения данных с установкой флага MTCR в регистре CAN_MCRx. Это автоматически очистит флаг MRDY.

Флаг MMI в регистре CAN_MSRx оповестит программу, что сообщение было потеряно mailbox-ом. Этот флаг устанавливается, когда сообщения были приняты, но установлен флаг MRDY в регистре CAN_MSRx. Этот флаг очищается чтением регистра CAN_MSR. Mailbox, настроенный в Receive Mode, предотвращает перезапись первого сообщения новыми, пока установлен флаг MRDY в регистре CAN_MSRx. См. рис. 36-11.

Рис. 36-11. Mailbox приема.

Примечание: в случае архитектуры ARM, регистры CAN_MSRx, CAN_MDLx, CAN_MDHx могут быть прочитаны с использованием оптимизированной инструкции LDM ассемблера.

Почтовый ящик в режиме приема с перезаписью (Receive with Overwrite Mailbox). Для установки этого режима также требуется конфигурирования поля MOT регистра CAN_MMRx. Также перед разрешением приема должны быть установлены идентификатор сообщения (Message ID) и маска допустимости сообщения (Message Acceptance Mask).

После того, как прием разрешен, флаг MRDY в регистре CAN_MSR автоматически очищается, пока не будет принято первое сообщение. Когда первое сообщение было принято mailbox, установится флаг MRDY. При установке флага MRDY будет ожидать обработки прерывание. Это прерывание может быть маскировано в зависимости от флага mailbox в глобальном регистре CAN_IMR.

Если новое сообщение было принято, когда флаг MRDY установлен, то это новое сообщение будет сохранено в регистре данных mailbox, перезаписывая старое сообщение. Флаг MMI в регистре CAN_MSRx оповестит программное обеспечение, что сообщение было отброшено mailbox-ом. Этот флаг очищается чтением регистра CAN_MSR.

Контроллер CAN может сохранить новое сообщение в регистрах данных CAN (это регистры CAN_MDHx и CAN_MDLx), когда приложение их считывает. Чтобы проверить, что CAN_MDHx и CAN_MDLx не принадлежат различным сообщениям, приложение должно проверить поле MMI в регистре CAN_MSRx перед и после чтения CAN_MDHx и CAN_MDLx. Если флаг MMI установился опять после того, как регистры данных были прочитаны, программа приложения должна перечитать регистры CAN_MDHx и CAN_MDLx (см. рис. 36-12).

Рис. 36-12. Почтовый ящик, работающий на прием с перезаписью (Receive with Overwrite Mailbox).

Соединение почтовых ящиков в цепочку (Chaining Mailboxes). Несколько mailbox-ов можно использовать для приема буфера, разделенного на несколько сообщений с одинаковым ID. В этом случае mailbox с самым маленьким номером будет обработан первым. В режимах обычного приема и приема с перезаписью, поле PRIOR в регистре CAN_MMRx не оказывает эффекта. Если Mailbox 0 и Mailbox 5 приняли сообщение с одинаковым ID, то первое из этих двух сообщений будет находиться в Mailbox 0, и второе сообщение будет находиться в Mailbox 5. Mailbox 0 должен быть сконфигурирован в режиме простого приема (Receive Mode, т. е. сохраняется первое принятое сообщение) и Mailbox 5 должен быть сконфигурирован в режиме приема с перезаписью (Receive with Overwrite Mode). Mailbox 0 не может быть сконфигурирован в режиме приема с перезаписью, иначе все сообщения попадут в этот mailbox, и Mailbox 5 никогда не будет обрабатываться.

Если несколько mailbox-ов соединяются в цепочку для приема буфера с разделением на несколько сообщений, то все mailbox-ы, за исключением последнего (у которого самый большой порядковый номер) должны быть сконфигурированы в режиме приема. Первое принятое сообщение попадет в первый mailbox, второе будет отклонено первым и попадет во второй mailbox, и т. д., так что последнее сообщение будет принято последним mailbox и будет отклонено предыдущим (см. рис. 36-13).

Рис. 36-13. Соединение 3 почтовых ящиков в цепочку, чтобы разделить принимаемый буфер на 3 сообщения.

Если количества почтовых ящиков недостаточное (установился флаг MMI в последнем mailbox), пользователь должен прочитать все данные, принятые в последнем mailbox, чтобы получить все сообщения разделенного буфера (см. рис. 36-14).

Рис. 36-14. Соединение 3 почтовых ящиков в цепочку, чтобы разделить принимаемый буфер на 4 сообщения.

Обработка передачи. Для конфигурирования mailbox в режиме передачи (Transmit Mode) также требуется соответствующая настройка поля MOT регистра CAN_MMRx. Также требуется установить Message ID и Message Acceptance mask, чтобы определить получателя сообщения.

После того, как режим передачи разрешен, автоматически установится флаг MRDY в регистре CAN_MSR, пока не будет отправлена первая команда. Когда флаг MRDY установлен, программа приложения может подготовить сообщение к отправке путем записи регистров CAN_MDx. Сообщение будет передано, как только программа запросит команду передачи установкой бита MTCR, и установит длину сообщения в регистре CAN_MCRx.

Флаг MRDY остается в состоянии 0 так долго, пока сообщение не отправлено или его передача оборвана. Важно отметить, что нельзя обращаться к регистрам данных mailbox, пока флаг MRDY очищен. Когда флаг MRDY установится, будет ожидать своей обработки прерывание mailbox. Это прерывание может быть замаскировано в зависимости от соответствующего флага mailbox в глобальном регистре CAN_IMR.

Можно также отправить фрейм remote установкой бита MRTR вместо установки поля MDLC. Ответ на фрейм remote обрабатывается другим mailbox-ом приема. В этом случае устройство работает как потребитель данных, но с помощью двух mailbox-ов. Можно обработать эмиссию фрейма remote и прием ответа, используя только один mailbox, сконфигурированный в режиме потребителя (Consumer Mode). Подробнее см. секцию "Обработка фреймов Remote".

Несколько сообщений в одно и то же время могут конкурировать за доступ к шине, тогда задействуется арбитраж. В этом случае первым будет отправлено сообщение с самым высоким приоритетом. Несколько команд запросов на передачу могут быть сгенерированы одновременно путем установки битов MBx в регистре CAN_TCR. Приоритет настраивается в поле PRIOR регистра CAN_MMRx. Приоритет 0 это самый высокий приоритет, приоритет 15 самый низкий. Таким образом, можно установить часть ID сообщения для установки поля PRIOR. Если два mailbox-а имеют одинаковый приоритет, то сначала будет отправлено сообщение из mailbox с меньшим порядковым номером. Так что если mailbox 0 и mailbox 5 имеют одинаковый приоритет, и одновременно имеют для отправки сообщение, то сначала будет отправлено сообщение из mailbox 0.

Установка бита MACR в регистре CAN_MCRx обрывает передачу. Передаче нескольких mailbox-ов может быть прервана записью полей MBx в регистре CAN_MACR. Если сообщение отправляется, когда установлена команда обрыва передачи, то приложение оповещается установкой бита MRDY, но не бита MABT в регистре CAN_MSRx. Иначе, если сообщение не отправлено, то биты MRDY и MABT устанавливаются в регистре CAN_MSR.

Когда арбитраж на шине потерян для сообщения mailbox-а, контроллер CAN пытается выиграть следующий арбитраж шины с таким же сообщением, если него все еще есть самый высокий приоритет. Сообщения отправляются и предпринимается автоматическая повторная переотправка, пока для них не будет выигран арбитраж шины. Эта функция может быть запрещена путем установки бита DRPT в регистре CAN_MR. В этом случае если сообщение не было отправлено первый раз и передано трансиверу CAN, то оно автоматически обрывается. Устанавливается флаг MABT в регистре CAN_MSRx до следующей команды передачи.

На рис. 36-15 показано, как делаются 3 попытки сообщения MBx (MRDY в MBx установлен в 0).

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

Рис. 36-15. Обработка передачи.

Обработка фреймов Remote. Модель продюсера / потребителя (Producer / consumer) эффективна в контексте обработки широковещательных сообщений. Модель проталкивания (push) позволяет продюсеру выполнять широковещание для сообщений; модель вытягивания (pull) позволяет потребителю запрашивать сообщения.

Рис. 36-16. Модель Producer / Consumer.

В режиме Pull потребитель посылает фрейм remote продюсеру. Когда продюсер получил фрейм remote, он отправляет ответ, который может быть принят одним или многими потребителями. При использовании передающих и принимающих mailbox-ов потребитель должен выделить 2 mailbox-а, один в режиме передачи для отправки фреймов remote, и как минимум один в режиме приема, чтобы захватывать ответ продюсера. Та же самая структура прикладывается и к продюсеру: один mailbox приема требуется для получения фрейма remote, и один передающий mailbox требуется для ответа.

Mailbox-ы могут быть сконфигурированы в режиме продюсера (Producer) или потребителя (Consumer). Единственный mailbox может обрабатывать фрейм remote и производить ответ. С 8 mailbox-ами контроллер CAN может обработать 8 независимых продюсеров / потребителей.

Конфигурация продюсера. Mailbox в режиме Producer требует соответствующего конфигурирования поля MOT в регистре CAN_MMRx. Перед разрешением приема должны быть настроены Message ID и маски Message Acceptance.

После разрешение режима Producer флаг MRDY в регистре CAN_MSR автоматически установится, пока не появится первая команда переноса данных. Программа приложения подготавливает данные для отправки путем записи регистров CAN_MDHx и CAN_MDLx, затем путем установки бита MTCR в регистре CAN_MCRx. Данные отправляются после приема фрейма remote, как только произойдет выигрыш арбитража шины.

Флаг MRDY остается в 0, пока сообщение не будет отправлено или оборвано. Нельзя осуществлять доступ к регистрам данных, пока флаг MRDY очищен. Когда флаг MRDY установится, будет выставлен запрос на обработку прерывания. Это прерывание может быть замаскировано (запрещено) в соответствии с флагом mailbox-а в глобальном регистре CAN_IMR.

Если фрейм remote был принят, когда нет готовых данных для отправки (установился сигнал MRDY в регистре CAN_MSRx), то устанавливается сигнал MMI в регистре CAN_MSRx. Этот бит очищается чтением регистра CAN_MSRx.

Поле MRTR в регистре CAN_MSRx ничего не означает. Оно используется только когда настроены режимы обычного приема или приема с перезаписью.

После того, как принят фрейм remote, mailbox функционирует как передающий mailbox. Первым будет отправлено сообщение с самым высоким приоритетом. Передаваемое сообщение может быть оборвано установкой бита MACR в регистре CAN_MCR. См. секцию выше "Обработка передачи".

Рис. 36-17. Обработка продюсера.

Конфигурация потребителя (Consumer). Для конфигурирования mailbox в режиме Consumer нужно соответствующим образом сконфигурировать поле MOT в регистре CAN_MMRx. Также должны быть настроены Message ID и маски Message Acceptance перед разрешением приема.

После разрешения режима Consumer флаг MRDY в регистре CAN_MSR автоматически установится, пока не появится первая команда переноса данных. Программа приложения посылает remote frame путем установки бита MTCR в регистре CAN_MCRx, или бита MBx в глобальном регистре CAN_TCR. Приложение оповещается об ответе установкой бита MRDY в регистре CAN_MSRx. Приложение может прочитать содержимое данных в регистрах CAN_MDHx и CAN_MDLx. Когда флаг MRDY установится, будет выставлен запрос на обработку прерывания. Это прерывание может быть замаскировано (запрещено) в соответствии с флагом mailbox-а в глобальном регистре CAN_IMR.

Бит MRTR в регистре CAN_MCRx ничего не означает. Он используется только когда настроен режим передачи.

После того, как фрейм remote отправлен, mailbox функционирует как принимающий mailbox. Первое принятое сообщение сохраняется в регистрах данных mailbox-а. Если другие сообщения, предназначенные для этого mailbox, были отправлены, когда флаг MRDY установлен в регистре CAN_MSRx, то они будут потеряны. Приложение об этом будет оповещено чтением поля MMI в регистре CAN_MSRx. Операция чтения автоматически очистит флаг MMI.

Если продюсер отвечает нескольким сообщениям, у контроллера CAN может быть один mailbox в конфигурации потребителя, 0 или несколько mailbox-ов в режиме простого приема и один mailbox в режиме приема с перезаписью. В этом случае mailbox потребителя должен иметь номер меньше, чем номер mailbox-а в режиме приема с перезаписью. Команда передачи может сработать для всех mailbox-ов одновременно путем установки нескольких полей MBx в регистре CAN_TCR.

Рис. 36-18. Обработка потребителя.

[Режимы диаграмм времени контроллера CAN]

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

• Timestamping Mode: значение счетчика внутреннего таймера захватывается в момент начала фрейма (Start Of Frame, SoF) или окончания фрейма (End Of Frame, EoF).
• Time Triggered Mode: операция передачи mailbox-а сработает, когда счетчик таймера достигнет триггера mailbox-а.

Timestamping Mode разрешается очисткой бита TTM в регистре CAN_MR. Time Triggered Mode разрешается установкой бита TTM в регистре CAN_MR.

Timestamping Mode. Каждый mailbox имеет свое собственное значение метки времени (timestamp). Каждый раз, когда сообщение отправляется или принимается через mailbox, 16-битное значение MTIMESTAMP в регистре CAN_TIMESTP перемещается в младшие биты биты регистра CAN_MSRx. Значение, прочитанное в регистре CAN_MSRx соответствует значению внутреннего таймера в момент начала фрейма (SoF) или (EoF), когда сообщение обрабатывается mailbox-ом.

Рис. 36-19. Mailbox Timestamp.

Time Triggered Mode. В режиме Time Triggered базовые циклы могут быть разделены на несколько окон времени. Базовый цикл начинается с эталонного сообщения. Каждое время окна определяется от эталонного сообщения, операция передачи должна произойти внутри предопределенного окна времени. Mailbox не должен выиграть арбитраж в предыдущем окне времени, и это не должно быть повторено, если арбитраж потерян в окне времени.

Рис. 36-20. Принцип работы Time Triggered Mode.

Режим Time Trigger разрешается установкой поля TTM в регистре CAN_MR. В режиме Time Triggered, как и в режиме Timestamp, поле CAN_TIMESTP захватывает значения счетчика внутреннего таймера, но поля MTIMESTAMP в регистрах CAN_MSRx не активны и будут прочитаны как 0.

Синхронизация по опорному сообщению. В режиме Time Triggered счетчик внутреннего таймера автоматически сбрасывается, когда новое сообщение принимается в последний mailbox. Этот сброс происходит после приема окончания фрейма (EoF) по фронту нарастания сигнала MRDY в регистре CAN_MSRx. Это позволяет синхронизацию счетчика внутреннего таймера с приемом опорного сообщения и началом нового окна времени.

Передача в пределах окна времени. Метка времени определена для каждого mailbox. Это определяется 16-битным полем MTIMEMARK в регистре CAN_MMRx. На каждом тактовом цикле внутреннего таймера значение CAN_TIM сравнивается с меткой времени каждого mailbox. Когда счетчик внутреннего таймера достигает значения MTIMEMARK, генерируется событие внутреннего таймера для mailbox.

В режиме Time Triggered операции передачи задерживаются, пока не произойдет событие внутреннего таймера для mailbox. Приложение подготавливает сообщение для отправки путем установки MTCR в регистре CAN_MCRx. Сообщение не отправляется, пока значение CAN_TIM меньше чем значение MTIMEMARK, заданное в регистре CAN_MMRx.

Если операция передачи потерпела неудачу, например сообщение потеряло арбитраж шины и следующая попытка передачи откладывается до следующего события триггера внутреннего таймера. Это предотвращает от перекрытия следующего окна времени, но сообщение все еще ожидает отправки и будет повторно отправлено в следующем окне времени, когда CAN_TIM станет равным значению MTIMEMARK. Также можно предотвратить повтор установкой поля DRPT в регистре CAN_MR.

Остановка счетчика внутреннего таймера. Внутренний таймер может быть заморожен установкой бита TIMFRZ в регистре CAN_MR. Это предотвращает неожиданное переполнение счетчика таймера, когда он достигает значения FFFFh. Когда такое происходит, это автоматически заморозит таймер до выдачи нового сброса, либо до приема сообщения в последний mailbox или любой другой операции, сбрасывающей счетчик. Бит TOVF в регистре CAN_SR устанавливается, когда счетчик замораживается. Бит TOVF в регистре CAN_SR очищается чтением регистра CAN_SR. В зависимости от соответствующей маски прерывания в регистре CAN_IMR, генерируется прерывание, когда TOVF устанавливается.

Рис. 36-21. Функционирование режима Time Triggered.

[Интерфейс программирования контроллера CAN]

Таблица 36-2. Карта адресов регистров (смещения указаны относительно начального адреса 0xFFFD0000).

// *****************************************************************************

//   Структура, отражающая адресное пространство CAN микроконтроллеров ARM7

// *****************************************************************************

typedef struct _AT91S_CAN {
	AT91_REG	 CAN_MR; // Mode Register
	AT91_REG	 CAN_IER; // Interrupt Enable Register
	AT91_REG	 CAN_IDR; // Interrupt Disable Register
	AT91_REG	 CAN_IMR; // Interrupt Mask Register
	AT91_REG	 CAN_SR; // Status Register
	AT91_REG	 CAN_BR; // Baudrate Register
	AT91_REG	 CAN_TIM; // Timer Register
	AT91_REG	 CAN_TIMESTP; // Time Stamp Register
	AT91_REG	 CAN_ECR; // Error Counter Register
	AT91_REG	 CAN_TCR; // Transfer Command Register
	AT91_REG	 CAN_ACR; // Abort Command Register
	AT91_REG	 Reserved0[52]; // 
	AT91_REG	 CAN_VR; // Version Register
	AT91_REG	 Reserved1[64]; // 
	AT91S_CAN_MB	 CAN_MB0; // CAN Mailbox 0
	AT91S_CAN_MB	 CAN_MB1; // CAN Mailbox 1
	AT91S_CAN_MB	 CAN_MB2; // CAN Mailbox 2
	AT91S_CAN_MB	 CAN_MB3; // CAN Mailbox 3
	AT91S_CAN_MB	 CAN_MB4; // CAN Mailbox 4
	AT91S_CAN_MB	 CAN_MB5; // CAN Mailbox 5
	AT91S_CAN_MB	 CAN_MB6; // CAN Mailbox 6
	AT91S_CAN_MB	 CAN_MB7; // CAN Mailbox 7
	AT91S_CAN_MB	 CAN_MB8; // CAN Mailbox 8
	AT91S_CAN_MB	 CAN_MB9; // CAN Mailbox 9
	AT91S_CAN_MB	 CAN_MB10; // CAN Mailbox 10
	AT91S_CAN_MB	 CAN_MB11; // CAN Mailbox 11
	AT91S_CAN_MB	 CAN_MB12; // CAN Mailbox 12
	AT91S_CAN_MB	 CAN_MB13; // CAN Mailbox 13
	AT91S_CAN_MB	 CAN_MB14; // CAN Mailbox 14
	AT91S_CAN_MB	 CAN_MB15; // CAN Mailbox 15
} AT91S_CAN, *AT91PS_CAN;

Примечание: у микроконтроллеров AT91SAM7X128, AT91SAM7X256, AT91SAM7X512 имеются только mailbox 0..7.

[Общие регистры контроллера]

[Регистры mailbox-ов]

// *****************************************************************************

// Структура, отражающая адресное пространство регистров mailbox

// *****************************************************************************

typedef struct _AT91S_CAN_MB {
	AT91_REG	 CAN_MB_MMR; // MailBox Mode Register
	AT91_REG	 CAN_MB_MAM; // MailBox Acceptance Mask Register
	AT91_REG	 CAN_MB_MID; // MailBox ID Register
	AT91_REG	 CAN_MB_MFID; // MailBox Family ID Register
	AT91_REG	 CAN_MB_MSR; // MailBox Status Register
	AT91_REG	 CAN_MB_MDL; // MailBox Data Low Register
	AT91_REG	 CAN_MB_MDH; // MailBox Data High Register
	AT91_REG	 CAN_MB_MCR; // MailBox Control Register
} AT91S_CAN_MB, *AT91PS_CAN_MB;

[Ссылки]

1. ARM-based Flash MCU SAM7X512 / SAM7X256 / SAM7X128 DATASHEET site:atmel.com.
2. Интерфейс CAN в микроконтроллере ARM AT91SAM7X256.
3. AT91SAM7: проблема установки бита MRDY в регистре статуса CAN mailbox.