Администрирование Железо MCP2515: контроллер шины CAN с интерфейсом SPI Wed, August 23 2017  

Поделиться

нашли опечатку?

Пожалуйста, сообщите об этом - просто выделите ошибочное слово или фразу и нажмите Shift Enter.


MCP2515: контроллер шины CAN с интерфейсом SPI Печать
Добавил(а) microsin   

Основные возможности контроллера:

• Реализует стандарт CAN V2.0B на скорости 1 мегабит/сек:
   - Поле данных длиной 0..8 байт.
   - Стандартный и расширенный формат для фреймов data и remote.
• Буферы приема, маски и фильтры:
   - Два буфера приема, сообщения хранятся в них с поддержкой приоритета.
   - 6 фильтров по 29 бит.
   - 2 маски по 29 бит.
• Фильтрация по первым двум байтам данных (применимо к стандартным фреймам данных).
• 3 буфера передачи с функцией приоритизацией и обрыва передачи (Abort).
• Высокоскоростной интерфейс SPI (10 МГц):
   - Режимы SPI 0,0 и 1,1.
• Режим One-Shot гарантирует, что попытка передачи сообщения будет выполнена только 1 раз.
• Вывод тактового сигнала (Clock Out) с программируемым прескалером:
   - Может использоваться как источник тактирования для других устройств.
• Сигнал начала фрейма (Start-of-Frame, SOF) доступен для мониторинга:
   - Можно использовать для протокола на основе тайм-слотов и/или диагностик шины, чтобы детектировать раннюю деградацию шины.
• Выход для генерации прерывания с функцией разрешения.
• Выходы заполнения буфера (Buffer Full Output Pins) конфигурируются как:
   - Выходы для генерации прерывания для каждого приемного буфера.
   - Выходные порты общего назначения.
• Входные выводы запроса на отправку (Request-to-Send, RTS) индивидуально конфигурируются как:
   - Управляющие выводы для запроса на передачу для каждого буфера передачи.
   - Входные порты общего назначения.
• Технология КМОП с низким энергопотреблением (Low-Power CMOS):
   - Работает от напряжений питания в диапазоне 2.7V .. 5.5V.
   - Ток потребления в активном режиме 5 мА (типичное значение).
   - Ток в режиме приостановки (standby current, режим сна, Sleep mode) 1 мкА (типичное значение).
• Поддерживаемый диапазон рабочих температур:
   - Индустриальное исполнение (I): -40°C .. +85°C.
   - Расширенное исполнение (E): -40°C .. +125°C.

[Типы корпусов]

MCP2515 PDIP18 SOIC18 MCP2515 TSSOP20 MCP2515 QFN20
18-выводный PDIP/SOIC 20-выводный TSSOP 20-выводный 4x4 QFN*

Примечание *: под донышком корпуса QFN20 имеется теплоотводящая металлическая площадка, предназначенная для пайки Exposed Thermal Pad (EP, см. даташит [1]).

[Общее описание]

Микросхема MCP2515 это специализированный, выделенный контроллер сети Controller Area Network (CAN), реализующий спецификацию CAN версии 2.0B. Может передавать и принимать как стандартные, так и расширенные фреймы данных, так и фреймы remote. У MCP2515 имеется 2 маски разрешения (acceptance mask) и 6 фильтров (acceptance filter), которые используются для отбрасывания нежелательных сообщений, что уменьшает нагрузку на управляющий микроконтроллер. С управляющим микроконтроллером MCP2515 соединяется через интерфейс SPI [2].

MCP2515 разработан таким образом, чтобы максимально упростить приложения, требующие подключения к CAN-шине. Простая блок-схема MCP2515 показана на рис. 1-1. Устройство состоит из 3 основных блоков:

1. Модуль CAN, который включает в себя систему обработки протокола CAN, маски, фильтры, буферы передачи и приема.
2. Логика управления и регистры, которые используются для конфигурирования устройства и работы с ним.
3. Блок поддержки протокола SPI.

MCP2515 block diagram fig1 1

Рис. 1-1. Блок-схема MCP2515.

Пример реализации сети с устройствами MCP2515 показан на рис. 1-2.

MCP2515 system example fig1 2

Рис. 1-2. Пример реализации обмена по шине CAN на контроллерах MCP2515.

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

Логика управления. Блок управляющей логики управляет настройкой и функционированием MCP2515 путем взаимодействия с другими блоками с целью передачи информации и управления.

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

Дополнительно имеется 3 вывода для немедленного запуска передачи сообщения, которое было предварительно загружено в один из трех регистров передачи. Использование этих выводов не обязательно, так как инициировать отправку сообщения можно также через управляющие регистры, доступные через SPI.

Блок поддержки протокола SPI. Управляющий микроконтроллер MCP2515 подключается к устройству через интерфейс SPI. Запись или чтение всех регистров осуществляется стандартными командами записи и чтения SPI в дополнение к специализированным командам SPI.

Таблица 1-1. Описание выводов контроллера MCP2515.

Имя Тип1 Описание Альтернативная функция
TXCAN O Выход передачи шины CAN. -
RXCAN I Вход приема шины CAN. -
CLKOUT O Тактовый выход с программируемым прескалером. Сигнал начала фрейма (SOF).
/TX0RTS I Сигнал RTS для буфера TXB02. Цифровой вход общего назначения2.
/TX1RTS I Сигнал RTS для буфера TXB12.
/TX2RTS   Сигнал RTS для буфера TXB22.
OSC2 O Вывод для подключения кварцевого резонатора (выход генератора). -
OSC1 I Вывод для подключения кварцевого резонатора (вход генератора). Вход для подачи внешнего тактового сигнала.
VSS P Общий провод для сигналов логики и ввода/вывода. -
/RX1BF O Выход для выдачи сигнала прерывания по событию приема буфера RXB1. Цифровой выход общего назначения.
/RX0BF O Выход для выдачи сигнала прерывания по событию приема буфера RXB0.
/INT O Выход для подачи сигнала прерывания. -
SCK I Вход тактов интерфейса SPI. -
SI I Вход данных интерфейса SPI (MOSI). -
SO O Выход данных интерфейса SPI (MISO). -
/CS I Сигнал выборки для интерфейса SPI. -
/RESET I Вход сброса устройства, активный уровень лог. 0. -
VDD P + напряжения питания. -
NC - Никуда не подключено (не используемый вывод). -

Примечание 1: в столбце "Тип" показан тип вывода. O означает выход, I означает вход, P означает вывод питания.

Примечание 2: на этом выводе имеется внутренний верхний подтягивающий резистор (pull-up, второй его конец соединен с VDD) на 100 кОм (номинальное значение).

[Буферы, маски, фильтры приема и буферы передачи]

У контроллера MCP2515 имеется 3 буфера передачи и 2 буфера приема, 2 маски разрешения приема сообщения (acceptance mask, по одной для каждого премного буфера) и всего 6 фильтров разрешения приема (acceptance filter). На рис. 1-3 показана блок-диаграмма этих буферов и их подключение к системе обработки протокола.

MCP2515 CAN buffers and protocol engine fig1 3

Рис. 1-3. Блок-диаграмма буферов и системы обработки протокола CAN.

[Подсистема обработки протокола CAN]

CAN protocol engine состоит из нескольких функциональных блоков, показанных на рис. 1-4.

MCP2515 CAN protocol engine block diagram

Рис. 1-4. Блок-схема подсистемы CAN.

Автомат конечных состояний протокола. Сердцем подсистемы обработки протокола CAN является автомат конечных состояний (Finite State Machine, FSM). Эта FSM представляет собой секвенсер, который управляет последовательным потоком данных между регистрами сдвига передачи/приема (TX/RX shift register), регистром контрольной суммы (CRC register) и сигналами шины. FSM также управляет логикой обработки ошибок (Error Management Logic, EML) и параллельными потоками данных между регистрами сдвига TX/RX и буферами. FSM гарантирует, что процессы приема, арбитража, передачи и сигнализации об ошибка выполняются в соответствии с протоколом CAN. Автоматическая ретрансмиссия сообщений по шине также обрабатывается FSM.

Проверка контрольной суммы. Регистр Cyclic Redundancy Check (CRC) генерирует код, который передается либо после поля управления (Control Field, для сообщений с 0 байт данных) либо после поля данных (Data Field), и используется для проверки поля CRC входящих сообщений.

Логика обработки ошибок. Error Management Logic (EML) отвечает за обработку отказов устройства CAN. У неё есть 2 счетчика: счетчик ошибок приема (Receive Error Counter, REC) и счетчик ошибок передачи (Transmit Error Counter, TEC), которые инкрементируются и декрементируются командами от процессора потока бит. На базе значений этих счетчиков ошибок контроллер CAN переходит между состояниями error-active, error-passive или bus-off.

Логика формирования последовательности бит. Bit Timing Logic (BTL) мониторит вход шины CAN, и обрабатывает относящиеся к шине интервалы времени в соответствии с протоколом CAN. BTL синхронизируется по переходам шины recessive-to-dominant в моменты начала фрейма Start-of-Frame (жесткая синхронизация) и по любому переходу recessive-to-dominant на шине, если контроллер CAN сам не передает доминантный бит (ресинхронизация). BTL предоставляет также программируемые сегменты времени, чтобы компенсировать задержки распространения (propagation delay time), сдвиги фазы, и для определения точки выборки в интервале бита. Программирование BTL зависит от скорости (baud rate) и внешних физических задержек по шине.

Рецессивный и доминантный в протоколе CAN используются как аналоги сигналов лог. 1 и лог. 0 в цифровой технике, т. е. они так же последовательно передают цифровые данные, как лог. 1. и лог. 0. Однако в отличие от обычных лог. 1 и лог. 0 сигналы "рецессивный" и "доминантный" имеют особое значение в том смысле, что доминантный бит может переопределять значение рецессивного бита (отсюда и пошло название битов: рецессивный и доминантный). При этом физический смысл этих сигналов обычно привязывается к среде передачи информации шины CAN с учетом выполнения условия рецессивности/доминантности.

Например, если сигнал передается светом по оптоволоконному кабелю, то рецессивным уровнем может считаться отсутствие света в кабеле, а доминантным - наличие света. Аналогичным образом наличие сигнала радиопередатчика может считаться доминантным битом, а отсутствие сигнала - рецессивным. Также может использоваться параллельное соединение выходов с открытым коллектором (стоком), тогда рецессивным будет лог. 1, а доминантным лог. 0. Во всех этих примерах доминантный уровень перекрывает (переназначает) рецессивный уровень, что имеет важное значение в разрешении коллизий на шине CAN (подробнее см. Википедию).

[Фрейм сообщения CAN]

MCP2515 поддерживает стандартные фреймы данных, расширенные фреймы данных и фреймы remote (стандартные и расширенные), как это определено в спецификации стандарта CAN 2.0B.

Standard Data Frame. Стандартный фрейм данных CAN показан на рис. 2-1. Как и все другие фреймы, этот фрейм начинается с бита начала фрейма (Start-Of-Frame, SOF), который имеет доминантное состояние и позволяет выполнить жесткую синхронизацию всех узлов на шине CAN.

MCP2515 standard data frame CAN fig2 1

Рис. 2-1. Стандартный фрейм данных CAN.

Пояснения к рис. 2-1: Start-of-Frame, End-of-Frame начало и конец фрейма (SOF/EOF). ID10..ID0 биты идентификатора. RTR бит Remote Transmission Request, запрос передачи с противоположного окончания. IDE бит Identifier Extension, бит определения типа фрейма - стандартный или расширенный. RB0 расшифровывается как Reserved Bit Zero, т. е. зарезервированный нулевой бит. DLC3..DLC0 здесь содержится количество байт полезной нагрузки в сообщении (Data Length Code). CRC Del это бит CRC Delimiter, бит разделителя CRC. Ack Slot Bit бит слота подтверждения, ACK Del это ACK Delimiter, бит разделителя подтверждения. IFS расшифровывается как InterFrame Space, т. е. промежуток между фреймами.

За SOF идет поле арбитража, состоящее из 12 бит: идентификатор из 11 бит, и бит запроса передачи с дальней точки (Remote Transmission Request, RTR). Бит RTR используется для того, чтобы отделять друг от друга фрейм данных (бит RTR является доминантным) от фрейма remote (в этом случае бит RTR рецессивный).

За полем арбитража идет поле управления (control field), состоящее из 6 бит. Первый бит этого поля это бит расширения идентификатора (Identifier Extension, IDE), который должен быть доминантным, чтобы задать стандартный фрейм. Следующий бит, зарезервированный нулевой бит (Reserved Bit Zero, RB0), в протоколе CAN зарезервирован и определен как доминантный. Остальные 4 бита поля управления содержат биты длины данных (Data Length Code, DLC), которые определяют количество байт данных (0..8), которое содержится в сообщении.

После поля управления идет поле данных, содержащие передаваемую полезную нагрузку, и его длина определяется полем DLC (0..8 байт).

За полем данных идет поле контрольной суммы (Cyclic Redundancy Check, CRC), которое используется для детектирования ошибок передачи. Поле CRC содержит 15-битную последовательность контрольной суммы, за которой идет рецессивный бит разделителя контрольной суммы (CRC Delimiter).

Последнее поле состоит из двухбитного поля подтверждения (Acknowledge, ACK). Во время битового слота ACK, передающий узел посылает рецессивный бит. Любой узел, который принял безошибочный фрейм, подтверждает корректный прием фрейма отправкой обратно доминантного бита (независимо от того, сконфигурирован ли этот узел принять это определенное сообщение или нет). Рецессивный разделитель подтверждения (recessive acknowledge delimiter) завершает поле подтверждения, и не может быть перезаписан доминантным битом.

Extended Data Frame. В расширенном фрейме данных CAN, показанном на рис. 2-2, за битом SOF идет поле арбитража, которое состоит из 32 бит. Первые 11 это старшие биты (Most Significant bits, MSB, так называемый базовый идентификатор, Base-lD) полного 29-битного идентификатора. За этими 11 битами идет бит замены запроса дальней передачи (Substitute Remote Request, SRR), который определен как рецессивный. За битом SRR идет бит lDE, который также является рецессивным, он определяет, что это расширенный фрейм CAN.

MCP2515 extended data frame CAN fig2 2

Рис. 2-2. Расширенный фрейм данных CAN.

Следует отметить, что если арбитраж остается не разрешенным после передачи первых 11 бит идентификатора, и один из узлов, вовлеченных в арбитраж, отправляет стандартный фрейм (состоящий из 11 битного идентификатора), то этот стандартный фрейм выиграет арбитраж шины CAN, потому что он вставит доминантный бит lDE. Также бит SRR в расширенном фрейме CAN должен быть рецессивным, чтобы позволить вставку доминантного бита RTR узлом, который отправляет стандартный фрейм remote.

За битами SRR и lDE идут остальные 18 бит идентификатора (Extended lD) и бит запроса передачи из дальнего окончания (remote transmission request bit).

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

За полем арбитража следует поле управления из 6 бит. Первые 2 бита этого поля зарезервированы, и должны быть доминантными. Остальные 4 бита поля управления это биты DLC, которые задают количество байт данных, содержащихся в сообщении.

Остальная часть фрейма (поле данных, поле CRC, поле подтверждения, end-of-frame и разделитель) сконструированы точно так же, как и у стандартного фрейма данных (см. секцию "Standard Data Frame").

Remote Frame. Обычно передача данных выполняется по автономному принципу, на основе узла-источника данных (например, фрейм данных поступает от датчика, когда имеются в наличии новые данные). Однако есть возможность, чтобы узел-получатель запросил для себя данные от узла-источника. Чтобы выполнить это, узел-получатель отправляет фрейм remote с идентификатором, совпадающим с идентификатором требуемого фрейма данных. Подходящий источник данных в ответ на запрос (этот запрос и называется remote frame request) отправит фрейм данных.

MCP2515 remote frame CAN fig2 3

Рис. 2-3. Фрейм remote шины CAN.

Есть 2 различия между фреймом remote (показан на рис. 2-3) и фреймом данных. Во-первых, бит RTR находится в рецессивном состоянии, и во-вторых, здесь нет поля данных. При этом событии фрейм данных и фрейм remote с тем же идентификатором будет отправлены одновременно, так что фрейм данных выиграет арбитраж, поскольку за идентификатором идет доминантный бит RTR. При таком методе обмена узел, который отправил фрейм remote, немедленно получит требуемые данные.

Error Frame. Фрейм ошибки генерируется любым узлом шины CAN, который детектирует ошибку на шине. Фрейм ошибки (error frame), показанный на рис. 2-4, состоит из 2 полей: флаг ошибки, за которым следует поле разделителя ошибки. Здесь имеется 2 типа полей флага ошибки. Тип отправляемого поля флага ошибки зависит от статуса ошибки того узла, который генерирует поле флага ошибки. Ниже описаны типы полей флага ошибки.

MCP2515 active error frame CAN fig2 4

Рис. 2-4: Active Error Frame CAN.

Различают 2 типа состояния ошибки узла - узел в состоянии активной ошибки и узел в состоянии пассивной ошибки. Узел в состоянии активной ошибки находится в том случае, если его внутренние счетчики ошибок заставили узел перейти в это состояние. Узел в состоянии пассивной ошибки находится в том случае, когда его внутренние счетчики не заставляют перейти в активное состояние ошибки, но узел обнаружил ошибку на шине. Т. е. активное состояние ошибки узла это когда он внутри себя обнаружил ошибку, а пассивное состояние ошибки это тогда, когда узел обнаружил ошибку снаружи.

Если узел перешел в активное состояние ошибки, то он прерывает передачу текущего сообщения генерацией флага active error. Этот флаг active error состоит из 6 доминантных бит, которые следуют друг за другом. Эта последовательность бит нарушает принцип бит-стаффинга. Все другие узлы на шине распознают эту ошибку бит-стаффинга, и как результат сами генерируют фреймы ошибки, которые называются флагами эха ошибки (error echo flags).

Поле флага эха ошибки состоит из следующих друг за другом последовательности доминантных бит, от 6 до 12 штук (генерируемых одним или большим количеством узлов). Поле разделителя ошибки (8 следующих друг за другом рецессивных бит) завершают фрейм ошибки. По завершению фрейма ошибки активность шины возвращается в нормальное состояние, и узел, передача которого была прервана, пытается отправить оборванное сообщение.

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

Если узел, находящийся в пассивном состоянии ошибки, обнаружил ошибку шины, то узел передает флаг пассивной ошибки (error-passive flag), за которым идет поле разделителя ошибки. Флаг пассивной ошибки состоит из 6 следующих друг за другом рецессивных бит. Фрейм ошибки для узла пассивной ошибки состоит из 14 рецессивных бит. По этой причине, если ошибка шины не обнаружена узлом активной ошибки или передающим узлом, то сообщение продолжает передаваться, потому что биты флага пассивной ошибки никак не влияют на шину.

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

Разделитель ошибки состоит из 8 рецессивных бит, и позволяет узлам шины после возникновения ошибки перезапустить обмен по шине с чистого листа.

Фрейм перегрузки (Overload Frame). Фрейм перегрузки, показанный на рис. 2-5, имеет тот же формат, что и фрейм активной ошибки. Однако фрейм перегрузки может быть сгенерирован только в промежутке между фреймами. Таким образом, фрейм перегрузки можно отличить от фрейма ошибки (фрейм ошибки передается во время передачи сообщения).

MCP2515 overload frame CAN fig2 5

Рис. 2-5. Overload Frame CAN.

Фрейм перегрузки состоит из 2 полей: флаг перегрузки, за которым идет разделитель перегрузки. Флаг перегрузки состоит из 6 доминантных бит, за которыми идут флаги перегрузки, генерируемые другими узлами (и, как и для флага активной ошибки, дают максимум 12 доминантных бит). Разделитель перезагрузки состоит из 8 рецессивных бит. Фрейм перегрузки может быть сгенерирован узлом в 2 случаях:

1. Узел детектировал доминантный бит во время промежуточного пространства между фреймами, что не допустимо. Исключение из этого правила: доминантный бит был детектирован во время третьего бита IFS. В этом случае приемники интерпретируют это как SOF (начало фрейма).
2. Из-за внутренних условий, когда узел все еще не может начать принимать следующее сообщение (например, он не успел обработать предыдущий принятый фрейм). Узел может генерировать максимум 2 последовательных фрейма перегрузки, чтобы задержать начало приема следующего сообщения.

Примечание: случай 2 никогда не должен произойти с MCP2515 из-за очень малых внутренних задержек.

Промежуточное пространство (Interframe Space). Этот интервал времени отделяет друг от друга предыдущий фрейм (любого типа) от последующего фрейма данных или фрейма remote. Промежуточное пространство состоит из как минимум 3 рецессивных бит, которые называются интервалом перерыва (Intermission). Это дает узлам время на внутреннюю обработку перед началом следующего фрейма сообщения. После intermission шина остается в рецессивном состоянии (bus idle), пока не начнется следующая передача.

[Передача сообщения]

Буферы передачи. В устройстве MCP2515 реализовано 3 буфера передачи. Каждый из них занимает 14 байт SRAM, и отображается на карту памяти устройства.

Первый байт TXBnCTRL, это управляющий регистр, связанный с буфером сообщения. Информация в этом регистре определяет условия, при которых сообщение будет передано, и показывает статус передачи сообщения (см. Регистр 3-2).

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

Для передачи должны быть загружены как минимум регистры TXBnSIDH, TXBnSIDL и TXBnDLC. Если в сообщении присутствуют байты данных, то также должны быть загружены регистры TXBnDm. Если сообщение использует расширенный идентификатор, то также должны быть загружены регистры TXBnEIDm, и должен быть установлен бит TXBnSIDL.EXIDE.

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

Примечание: бит TXBnCTRL.TXREQ должен быть очищен (показывая тем самым, что буфер передачи не ожидает передачи) перед записью в буфер передачи.

Приоритет передачи (Transmit Priority). Приоритет передачи относится к приоритизации в пределах MCP2515 для сообщений, ожидающих передачу. Это не зависит от схемы приоритизации арбитража, встроенного в протокол CAN, и не обязательно связано с ним.

Перед отправкой SOF сравниваются друг с другом приоритеты всех буферов передачи. Первым будет отправлен тот буфер, у которого самый высокий приоритет. Например, если у буфера передачи 0 приоритет выше, чем у буфера 1, то буфер 0 будет отправлен первым.

Если 2 буфера имеют одинаковый настроенный приоритет, то буфер с самым большим порядковым номером будет отправлен первым. Например, если буфер передачи 1 имеет тот же приоритет, что и буфер передачи 0, то буфер 1 будет отправлен первым.

Всего имеется 4 уровня приоритета передачи. Если поле TXBnCTRL.TXP[1:0] для какого-то отдельного буфера сообщения установлено в 11, то у этого буфера самый высокий возможный приоритет отправки. Если поле TXBnCTRL.TXP[1:0] буфера сообщения установлено в 00, то этот буфер имеет самый низкий приоритет (будет отправлен последним из всех ожидающих).

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

• Записью регистра через SPI
• Отправкой команды RTS через SPI
• Установка вывода TXnRTS в лог. 0 для определенного буфера передачи

Если передача инициируется через интерфейс SPI, то бит TXREQ может быть установлен одновременно с битами приоритета TXP.

Когда установлен бит TXBnCTRL.TXREQ, биты TXBnCTRL.ABTF, TXBnCTRL.MLOA и TXBnCTRL.TXERR автоматически очищаются.

Примечание: установка бита TXBnCTRL.TXREQ не инициирует передачу сообщения. Это просто помечает буфер сообщения, что он готов к передачи. Реальная передача начнется, когда устройство обнаружит доступность шины для передачи.

Как только передача успешно завершилась, бит TXBnCTRL.TXREQ очищается, бит CANINTF.TXnIF установится, и будет сгенерирован внешний сигнал прерывания, если установлен бит CANINTE.TXnIE.

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

• Если сообщение начало передаваться, но произошло событие ошибки, то будут установлены биты TXBnCTRL.TXERR и CANINTF.MERRF, и будет сгенерировано внешнее прерывание на выводе /INT, если установлен бит CANINTE.MERRE.
• Если сообщение было потеряно, то будет установлен арбитраж в бите TXBnCTRL.MLOA.

Примечание: если разрешен режим One-Shot (битом CANCTRL.OSM), то перечисленные выше условия все еще остаются в силе. Однако бит TXREQ будет очищен, и не будет предприниматься попытка отправить сообщение второй раз.

Режим One-Shot. Режим одиночной передачи (One-Shot mode) гарантирует, что будет осуществлена только одна попытка отправить сообщение. Обычно, если сообщение CAN проиграло арбитраж, или если его передача была уничтожена фреймом ошибки, то сообщение передается повторно. Когда разрешен режим One-Shot, то попытка отправить сообщение будет произведена только 1 раз, независимо от проигрыша арбитража или ошибки фрейма.

Режим One-Shot требуется для того, чтобы поддерживать времена слотов в детерминированных системах, таких как TTCAN.

Выводы TXnRTS. Ножки TXnRTS это выводы входа, которые можно сконфигурировать следующим образом:

• Входы для приема запроса на отправку (Request-to-send, RTS), что предоставляет альтернативный способ запуска передачи сообщения из любого буфера передачи.
• Стандартные цифровые входы.

Конфигурирование режима работы этих выводов осуществляется регистром TXRTSCTRL (см. Register 3-3). Регистр TXRTSCTRL может быть модифицирован, когда MCP2515 находится в режиме конфигурации (Configuration mode, см. секцию "Режимы работы"). Если выводы TXnRTS сконфигурированы как входы RTS, то они отображаются на соответствующий бит TXBnCTRL.TXREQ буфера передачи. Бит TXREQ защелкивается по спаду уровня (переход в лог. 0) на выводе TXnRTS. Выводы TXnRTS были разработаны, чтобы автоматически начать передачу сообщения, когда вывод RXnBF переходит в лог. 0.

Выводы TXnRTS имеют внутренние верхние подтягивающие резисторы (pull-up) с номинальным значением 100 кОм.

Обрыв передачи. Управляющий микроконтроллер может запросить прервать передачу сообщения определенного буфера путем очистки соответствующего бита TXBnCTRL.TXREQ.

Дополнительно может быть запрошен обрыв всех ожидающих отправки сообщений путем установки бита CANCTRL.ABAT. Этот бит ДОЛЖЕН быть сброшен (обычно после того, как проверено, что биты TXREQ очищены), чтобы продолжить отправку сообщений. Флаг TXBnCTRL.ABTF будет установлен только в том случае, если обрыв был запрошен через бит CANCTRL.ABAT. Обрыв сообщения сбросом бита TXREQ НЕ ПРИВЕДЕТ к установке бита ABTF.

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

Примечание 2: когда разрешен режим One-Shot, если сообщение было прервано из-за ошибки фрейма или проигрыша арбитража, то бит TXBnCTRL.ABTF будет установлен.

MCP2515 transmit message flowchart fig3 1

Рис. 3-1. Алгоритм отправки сообщения.

[Описание регистров передачи]

Ниже во врезках приведено описание регистров и каждого из их отдельных бит. Под каждым битом приведена его легенда, состоящая из комбинации символов:

Символ Легенда
R Читаемый бит.
W Записываемый бит.
U Не реализованный бит, читается как 0.
-n Значение в момент POR (Power On Reset, при включении питания), n = 0 или 1.
1 Бит установлен.
0 Бит сброшен.
x Состояние бита не известно.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит  - ABTF MLOA TXERR TXREQ - TXP1 TXP0
Легенда U-0 R-0 R-0 R-0 R/W-0 U-0 R/W-0 R/W-0

7 не реализован, читается как 0.

6, ABTF: бит флага обрыва сообщения (Message Aborted Flag).

1 сообщение было оборвано.
0 передача сообщения была успешна завершена.

5, MLOA: сообщение проиграло арбитраж (Message Lost Arbitration).

1 сообщение при попытке отправки проиграло арбитраж.
0 сообщение выиграло арбитраж при отправке.

4, TXERR: была детектирована ошибка передачи (Transmission Error Detected).

1 произошла ошибка шины при передачи сообщения.
0 при передаче сообщения не была обнаружена ошибка.

3, TXREQ: бит запроса на передачу сообщения (Message Transmit Request).

1 буфер в настоящий момент ожидает передачи. Управляющий микроконтроллер устанавливает этот бит, чтобы выставить запрос на передачу сообщения. Этот бит автоматически очистится, когда сообщение будет отправлено.
0 буфер сейчас не ожидает своей передачи. Управляющий микроконтроллер может очистить этот бит, чтобы запросить отмену передачи.

2 не реализован, читается как 0.

1-0, TXP[1:0]: биты приоритета буфера передачи (Transmit Buffer Priority).

11 самый высокий приоритет сообщения.
10 высокий приоритет, но ниже самого высокого.
01 низкий приоритет, но выше самого низкого.
00 самый низкий приоритет.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит - - B2RTS B1RTS B0RTS B2RTSM B1RTSM B0RTSM
Легенда U-0 U-0 R-x R-x R-x R/W-0 R/W-0 R/W-0

7-6 эти биты не реализованы, читаются как 0.

5, B2RTS: состояние вывода /TX2RTS (/TX2RTS Pin State).

4, B1RTS: бит состояния вывода /TX1RTX (/TX1RTX Pin State).

3, B0RTS: бит состояния вывода /TX0RTS (/TX0RTS Pin State).

- В режиме цифрового входа (Digital Input mode) в бите BnRTS (n=0..2) может быть прочитан уровень входа /TXnRTS.
- Читается как 0, когда вывод /TXnRTS находится в режиме входа запроса на передачу RTS (Request-to-Send mode).

2, B2RTSM: бит режима вывода /TX2RTS.

1, B1RTSM: бит режима вывода /TX1RTS.

0, B0RTSM: бит режима вывода /TX0RTS.

1 вывод BnRTSM (n=0..2) используется для запроса на передачу буфера TXB0 (по спаду уровня).
0 BnRTSM работает как цифровой вход (Digital input).

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[10:3]
Легенда R/W-x

7-0, SID[10:3]: биты стандартного идентификатора сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[2:0] - EXIDE - EID[17:16]
Легенда R/W-x R/W-x R/W-x R/W-x R/W-x

7-5, SID[2:0]: биты стандартного идентификатора сообщения.

4 не реализован, читается как 0.

3, EXIDE: бит разрешения расширенной адресации (Extended Identifier Enable).

1 сообщение будет отправлено с расширенным идентификатором.
0 сообщение будет отправлено со стандартным идентификатором.

2 не реализован, читается как 0.

1-0, EID[17:16]: биты расширенного идентификатора сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[15:8]
Легенда R/W-x

7-0, EID[15:8]: биты расширенного идентификатора сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[7:0]
Легенда R/W-x

7-0, EID[7:0]: биты расширенного идентификатора сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит  - RTR - - DLC[3:0]
Легенда U-0 R/W-x R/W-x R/W-x R/W-x

7 не реализован, читается как 0.

6, RTR: бит запроса передачи с дальнего окончания (Remote Transmission Request).

1 переданное сообщение содержит фрейм remote.
0 переданное сообщение это фрейм данных.

5-4 не реализованные биты, читаются как 0.

3-0, DLC[3:0]: биты длины сообщения (Data Length Code). Устанавливает количество байт данных, передаваемых в сообщении (от 0 до 8 байт).

Примечание: есть возможность установить поле DLC значением, которое больше 8, но все равно будет передано только 8 байт полезной нагрузки сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит TXBnDm[7:0]
Легенда R/W-x

7-0, TXBnDm7:TXBnDm0: байт данных m буфера передачи n (Transmit Buffer n Data Field Bytes)

[Прием сообщения]

RXB1, RXB0, MAB. У MCP2515 имеется два полных буфера приема RXBn, с несколькими фильтрами в каждом. Фильтры позволяют отбрасывать нежелательные сообщения. Также имеется отдельный буфер сборки сообщения MAB (расшифровывается как Message Assembly Buffer), который работает как третий буфер приема (см. рис. 4-2).

MCP2515 receive buffer block diagram fig4 2

Рис. 4-2. Блок-диаграмма буфера приема.

Примечание: к сообщениям, принятым в MAB, сначала прикладываются маски и фильтры буфера RXB0. Кроме того, только в одном фильтре может произойти совпадение (например, если сообщение совпадает с обоими RXF0 и RXF2, то будет учтено совпадение для RXF0, и сообщение будет перемещено в буфер RXB0).

Из этих трех буферов приема MAB всегда осуществляет прием сообщения с шины CAN. MAB осуществляет сборку принимаемого сообщения. Собранные сообщения будут переданы в буферы RXBn (см. регистр 4-4 и регистр 4-9) только тогда, когда сообщения будут удовлетворять критерию допустимости (определяется фильтрами).

Каждый из двух буферов приема RXB0 и RXB1 могут получить через MAB полное сообщение от подсистемы обработки протокола. Управляющий микроконтроллер может получить доступ к одному из буферов, в то время как другой буфер будет доступен для приема сообщения или для хранения ранее принятого сообщения.

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

Флаги приема / прерывания.  Когда сообщение перемещается в любой из буферов приема, устанавливается соответствующий бит CANINTF.RXnIF. Этот бит должен быть очищен управляющим микроконтроллером, чтобы позволить новому сообщению быть помещенным в соответствующий буфер. Этот буфер предоставляет позитивную обратную связь, дающую гарантию, что управляющий микроконтроллер завершил выборку сообщения из буфера до того, как MCP2515 попытается загрузить новое сообщение в тот же буфер приема.

Если бит CANINTE.RXnIE установлен, то на выводе /INT будет сгенерирован сигнал прерывания, показывающий прием допустимого сообщения. В дополнение связанный вывод RXnBF выдаст на выходе лог. 0, если он был сконфигурирован как вывод индикации заполнения буфер приема. Подробнее см. секцию "Выводы RX0BF и RX1BF".

Приоритет приема. У буфера RXB0 есть привязанные к нему маска и 2 фильтра допустимости сообщения. Также у буфера RXB0 приоритет приема выше, поэтому принятое сообщение сначала обрабатывается по маске и фильтрам буфера RXB0.

Буфер RXB1 имеет приоритет ниже, и к нему привязаны одна маска и 4 фильтра допустимости сообщения. В дополнение к тому, что к сообщению сначала прикладываются маска и фильтры RXB0, меньшее количество фильтров допустимости в RXB0 делают его более строгим в проверке, и это подразумевает наличие более высокого приоритета для буфера RXB0.

Когда сообщение принято, биты [3:0] регистра RXBnCTRL покажут номер фильтра допустимости, который разрешил прием, независимо от того, было ли это сообщение обычным, или оно было remote-запросом передачи.

Режим пролонгации буфера RXB0. Дополнительно регистр RXB0CTRL может быть сконфигурирован так, что если RXB0 содержит допустимое сообщение, и при этом было принято другое допустимое сообщение, то не произойдет ошибка переполнения, и новое сообщение просто будет перемещено в буфер RXB1, независимо от критерия допустимости, определенного для буфера RXB1.

Биты RXM устанавливают специальные режимы приема. Обычно эти биты очищены (в них записано 00), чтобы разрешить прием всех допустимых сообщений, как это настроено фильтрами допустимости. В этом случае принять ли стандартные или расширенные сообщение определяется битом RFXnSIDL.EXIDE в регистре фильтра допустимости.

Если биты RXBnCTRL.RXM установлены в состояние 01 или 10, то приемник будет принимать только стандартные или только расширенные сообщения соответственно. Если у фильтра допустимости установлен бит RFXnSIDL.EXIDE, так что он не соответствует режиму, настроенному битами RXBnCTRL.RXM, то приемный фильтр будет считаться бесполезным. Эти два режима бит RXBnCTRL.RXM могут использоваться в системах, где заранее известно, что на шине CAN присутствуют только стандартные или только расширенные сообщения.

Если биты RXBnCTRL.RXM установлены в 11, то буфер будет принимать все сообщения, независимо от того, что настроено фильтрами допустимости. Также если в сообщении имеется ошибка до EOF (до конца фрейма), то порция сообщения, которая была собрана в MAB до появления ошибки фрейма будет загружена в буфер приема. Этот режим имеет некоторое значение для отладки системы CAN, и не должен использоваться в реальных рабочих условиях эксплуатации систем CAN.

Сигнал SOF. Если это разрешено, то при поступлении начала фрейма (Start-of-Frame, SOF) на выводе SOF генерируется сигнал, соответствующий началу каждого сообщения, как это было детектировано на выводе приема RXCAN.

Вывод RXCAN мониторит состояние ожидания шины, чтобы поймать перепад перехода шины из рецессивного состояния в доминантное. Если доминантное состояние остается до точки выборки, то MCP2515 интерпретирует это как SOF, и будет сгенерирован импульс сигнала SOF. Если доминантное состояние не сохранилось до точки выборки, то MCP2515 интерпретирует это как выброс помехи на шине, и сигнал SOF не будет сгенерирован. Рис. 4-1 показывает сигнализацию SOF и фильтрацию помех, применяемую при детектировании начала фрейма.

MCP2515 SOF signaling fig4 1

Рис. 4-1. Сигнализация о поступлении начала фрейма.

Режим One-Shot использует сигнализацию SOF для систем TTCAN. Дополнительно управляющий микроконтроллер может опрашивать одновременно оба сигнала выводов RXCAN и SOF, и по ним заранее детектировать наличие физических проблем с короткими выбросами помех на шине до того, как эти проблемы могут повлиять на обмен по шине CAN.

Выводы /RX0BF и /RX1BF. В дополнение к выводу /INT, который предоставляет для управляющего микроконтроллера сигнал прерывания от многих разных событий, имеются также сигналы заполнения приемного буфера (/RX0BF и /RX1BF), что можно использовать для индицирования того, что допустимое сообщение было принято в буфер RXB0 или RXB1 соответственно. Выводы /RX0BF и /RX1BF имеют три разных конфигурации (что определяется регистром 4-3 BFPCTRL):

1. Запрещено.
2. Сигнал прерывания по заполнению буфера.
3. Цифровой выход общего назначения.

Состояние "запрещено" будет работать, когда очищен бит BFPCTRL.BnBFE, при этом вывод /RXnBF будет находиться в состоянии высокого сопротивления. Вывод /RXnBF может быть сконфигурирован либо для сигнализации заполнения соответствующего буфера, либо для работы как стандартный цифровой выход. Конфигурация и состояние этих выводов доступно через регистр BFPCTRL (регистр 4-3). Когда сконфигурирован режим генерации сигнала прерывания (установкой битов BFPCTRL.BxBFE и BFPCTRL.BxBFM), эти выводы имеют активное состояние лог. 0, и они привязаны к биту CANINTF.RXnIF для каждого буфера. Когда этот бит переходит в лог. 1 для одного из буферов приема (показывая тем самым, что допустимое сообщение было загружено в буфер), то соответствующий вывод RXBnBF перейдет в состояние лог. 0. Когда бит CANINTF.RXnIF очищается управляющим микроконтроллером, соответствующий вывод сигнала прерывания перейдет в лог. 1, и останется в этом состоянии, пока в буфер приема не будет загружено новое сообщение.

Когда выводы /RXnBF сконфигурированы как цифровые выходы, бит BFPCTRL.BxBFM должен быть очищен, и бит BFPCTRL.BnBFE должен быть установлен для соответствующего буфера. В этом режиме состояние вывода управляется битом BFPCTRL.BnBFS. Запись лог. 1 в бит BnBFS приведет к тому, что на соответствующем выходе /RXnBF появится лог. 1, а запись лог. 0 в бит BnBFS приведет к выводу на выходе /RXnBF лог. 0. Когда выводы /RXnBF используются в таком режиме, состояние вывода должно модифицироваться только с использованием команды Bit Modify SPI, чтобы предотвратить появление выбросов на другом выводе /RXnBF.

Таблица 4-1. Конфигурирование выводов /RXnBF.

BnBFE BnBFM BnBFS Состояние выводов
0 x x Запрещено, выходы в состоянии высокого сопротивления.
1 1 x Выдача сигнала прерывания приема буфера.
1 0 0 Цифровой выход в состоянии лог. 0.
1 0 1 Цифровой выход в состоянии лог. 1.

MCP2515 receive flowchart fig4 3

Рис. 4-3. Блок-диаграмма алгоритма приема.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит - RXM1 RXM0 - RXRTR BUKT BUKT1 FILHIT0
Легенда U-0 R/W-0 R/W-0 U-0 R-0 R/W-0 R-0 R-0

7 не реализован, читается как 0.

6-5, RXM[1:0]: биты режима работы буфера приема.

11 маски/фильтры отключены; будет принято любое сообщение.
10 будут приняты только допустимые сообщения с расширенным идентификатором (ID), соответствующие критерию фильтра.
01 будут приняты только допустимые сообщения со стандартным ID, соответствующие критерию фильтра. Регистры расширенного ID фильтра RXFnEID8:RXFnEID0 игнорируются для сообщений со стандартными ID.
00 будут приняты все допустимые сообщения с использованием стандартных или расширенных ID, которые удовлетворяют критерию фильтра. Регистры фильтра расширения ID RXFnEID8:RXFnEID0 прикладываются к первым двум байтам в сообщениях со стандартным ID.

4  не реализован, читается как 0.

3, RXRTR: Received Remote Transfer Request.

1 принят запрос на передачу от другого пира сети (Remote Transfer Request).
0 не было принято запроса Remote.

2, BUKT: бит разрешения пролонгации буфера RXB0 (Rollover Enable).

1 при поступлении нового сообщения для буфера RXB0 старое, не обработанное сообщения в том же буфере будет перемещено в буфер RXB1, независимо от других условий (независимо от того, заполнен ли буфер RXB1, и независимо от состояния его фильтров).
0 запрет пролонгации RXB0.

1, BUKT1: копия бита BUKT, доступная только для чтения (используется внутри MCP2515).

0, FILHIT0: бит срабатывания фильтра (Filter Hit bit) - показывает, какой фильтр допустимости разрешил прием сообщения.

1 Acceptance Filter 1 (RXF1)
0 Acceptance Filter 0 (RXF0)

Примечание: если произошла пролонгация с перемещением данных из RXB0 в RXB1, то бит FILHIT будет отражать фильтр, который разрешил прием нового сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит - RXM1 RXM0 - RXRTR FILHIT2 FILHIT1 FILHIT0
Легенда U-0 R/W-0 R/W-0 U-0 R-0 R-0 R-0 R-0

7 не реализован, читается как 0.

6-5, RXM[1:0]: биты управления режимами работы буфера приема (Receive Buffer Operating mode).

11 маски/фильтры отключены; будет принято любое сообщение.
10 будут приняты только допустимые сообщения с расширенным идентификатором (ID), соответствующие критерию фильтра.
01 будут приняты только допустимые сообщения со стандартным ID, соответствующие критерию фильтра. Расширенные регистры ID фильтра RXFnEID8:RXFnEID0 игнорируются для сообщений со стандартными ID.
00 будут приняты все допустимые сообщения с использованием стандартных или расширенных ID, которые удовлетворяют критерию фильтра.

4 не реализован, читается как 0.

3, RXRTR: принят запрос передачи от другого пира сети (Received Remote Transfer Request).

1 принят запрос на передачу от другого пира сети (Remote Transfer Request).
0 не было принято запроса Remote.

2-0, FILHIT[2:0]: биты срабатывания фильтра (Filter Hit bits) - показывают, какой фильтр допустимости разрешил прием сообщения.

101 = Acceptance Filter 5 (RXF5)
100 = Acceptance Filter 4 (RXF4)
011 = Acceptance Filter 3 (RXF3)
010 = Acceptance Filter 2 (RXF2)
001 = Acceptance Filter 1 (RXF1) (только если установлен бит BUKT в регистре RXB0CTRL)
000 = Acceptance Filter 0 (RXF0) (только если установлен бит BUKT в регистре RXB0CTRL)

№ разрядов 7 6 5 4 3 2 1 0
Имена бит - - B1BFS B0BFS B1BFE B0BFE B1BFM B0BFM
Легенда U-0 U-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0

7-6 не реализованы, читаются как 0.

5, B1BFS: бит состояния вывода /RX1BF (только для режима цифрового выхода). Читается как 0, когда /RX1BF сконфигурирован как выход сигнала прерывания.

4, B0BFS: бит состояния вывода /RX0BF (только для режима цифрового выхода). Читается как 0, когда /RX0BF сконфигурирован как выход сигнала прерывания.

3, B1BFE: бит разрешения функции вывода /RX1BF.

1 функционирование вывода разрешено, его рабочий режим определяется битом B1BFM.
0 функция вывода запрещена, он переходит в состояние высокого сопротивления.

2, B0BFE: бит разрешения функции вывода /RX0BF.

1 функционирование вывода разрешено, его рабочий режим определяется битом B0BFM.
0 функция вывода запрещена, он переходит в состояние высокого сопротивления.

1, B1BFM: бит рабочего режима вывода /RX1BF.

1 вывод используется как выход сигнала прерывания, когда допустимое сообщение загружен в буфер RXB1.
0 режим цифрового выхода.

0, B0BFM: бит рабочего режима вывода /RX0BF.

1 вывод используется как выход сигнала прерывания, когда допустимое сообщение загружен в буфер RXB0.
0 режим цифрового выхода.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[10:3]
Легенда R-x

7-0, SID[10:3]: биты стандартного идентификатора. В этих битах содержатся 8 старших бит стандартного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[2:0] SRR IDE - EID[17:16]
Легенда R-x R-x R-x U-0 R-x

7-5, SID[2:0]: биты стандартного идентификатора. В этих битах содержатся 3 младших бита стандартного идентификатора принятого сообщения.

4, SRR: бит запроса стандартного фрейма remote (Standard Frame Remote Transmit Request), допустим только если бит IDE = 0.

1 принят Standard Frame Remote Transmit Request.
0 принят стандартный фрейм данных (Standard Data Frame).

3, IDE: бит флага расширенного идентификатора (Extended Identifier Flag). Этот бит показывает, какой фрейм был принят: стандартный или расширенный.

1 был принят расширенный фрейм (Extended Frame).
0 был принят стандартный фрейм (Standard Frame).

2 не реализован, читается как 0.

1-0, EID[17:16]: биты расширенного идентификатора (Extended Identifier). Эти биты содержат 2 самых старших бита расширенного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[15:8]
Легенда R-x

7-0, EID[15:8]: Биты расширенного идентификатора (Extended Identifier). Здесь хранятся биты 15..8 расширенного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[7:0]
Легенда R-x

7-0, EID[7:0]: Биты расширенного идентификатора (Extended Identifier). Здесь хранятся младшие 8 бит расширенного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит - RTR RB1 RB0 DLC[3:0]
Легенда R-x R-x R-x R-x R-x

7 не реализован, читается как 0.

6, RTR: бит запроса передачи расширенного фрейма (Extended Frame Remote Transmission Request), допустим только когда RXBnSIDL.IDE=1.

1 был принят Extended Frame Remote Transmit Request.
0 был принят Extended Data Frame.

5, RB1: зарезервированный бит 1.

4, RB0: зарезервированный бит 0.

3-0, DLC[3:0]: биты кода длины данных (Data Length Code). Показывает количество байт данных в принятом сообщении.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит RBnD[7:0]
Легенда R-x

7-0, RBnD7:RBnD0: байт m поля данных буфера приема n (Receive Buffer n Data Field Bytes m). Это 8 байт, содержащих полезную нагрузку принятого сообщения.

Фильтры и маски приема. Фильтры допустимости сообщения и маски используются для того, чтобы определить - нужно ли принять или отбросить сообщение, собранное в MAB. Если сообщение считается допустимым, то оно будет загружено в один из буферов приема (см. рис. 4-5). Как только сообщение было принято в MAB, поля идентификатора принятого сообщения сравниваются со значениями фильтра. Если обнаружено соответствие (т. е. обнаружено допустимое сообщение), то это сообщение будет загружено в один из буферов приема.

Фильтрация по байтам данных. Когда принимаются стандартные фреймы данных (у которых 11-битные идентификаторы), MCP2515 автоматически накладывает 16 бит масок и фильтров, обычно связанных с расширенными идентификаторами, на первые 16 бит поля данных (байты данных 0 и 1). На рис. 4-4 показано, как маски и фильтры прикладываются для расширенных и стандартных фреймов данных.

MCP2515 masks and filters apply to CAN frames fig4 4

Рис. 4-4: Маски и фильтры, прикладываемые к фреймам CAN.

Примечание *: два старших бита (EID17 и EID16) маски и фильтра не используются.

Фильтрация по байтам данных снижает нагрузку на управляющий микроконтроллер при реализации высокоуровневых протоколов, когда они осуществляют фильтрацию по старшему байту данных (как например, в протоколе DeviceNet™).

Совпадение с фильтром. Маски фильтра (см. регистры от 4-14 до 4-17) используются, чтобы определить, какие биты в идентификаторе должны совпадать с битами фильтров. Таблица истинности в таблице 4-2 показывает, как каждый бит в идентификаторе сравнивается с масками и фильтрами, чтобы определить, должно ли сообщение быть помещено в буфер приема. Маска в сущности определяет, какой из битов фильтра используется для фильтрации. Если любой бит в маске установлен в 0, то это означает, что ни один из битов фильтра не применяется, так что сообщения будет автоматически принято, независимо от состояния битов фильтра.

Таблица 4-2. Таблица истинности фильтра/маски.

Бит
маски n
Бит
фильтра n
Бит ID
сообщения
Принять или отбросить
сообщение по биту n
0 x x Принять
1 0 0 Принять
1 0 1 Отбросить
1 1 0 Отбросить
1 1 1 Принять

Примечание: X означает, что не имеет значения.

Как показано в блок-диаграмме буферов приема (рис. 4-2), фильтры допустимости RXF0 и RXF1 (и маска фильтра RXM0) связаны RXB0. Фильтры RXF2, RXF3, RXF4, RXF5 и маска RXM1 связана с RXB1.

Биты FILHIT. Фильтр, который совпал с принятым сообщением, может быть определен по битам FILHIT в соответствующем регистре RXBnCTRL. Это бит RXB0CTRL.FILHIT0 для буфера 0, и биты RXB1CTRL.FILHIT[2:0] для буфера 1 (см. во врезках описание регистров 4-1 и 4-2).

Примечание: 000 и 001 могут произойти только если установлен бит BUKT в регистре RXB0CTRL, что позволяет сообщениям из буфера RXB0 переместиться в буфер RXB1.

RXB0CTRL содержит 2 копии бита BUKT и бита FILHIT[0].

Кодирование бита BUKT разрешает эти 3 бита использовать подобно битам RXB1CTRL.FILHIT, и для определения попадания в фильтры RXF0 и RXF1, либо для RXB0, либо для перемещения данных в RXB1 при пролонгации буфера RXB0.

111 Acceptance Filter 1 (RXB1)
110 Acceptance Filter 0 (RXB1)
001 Acceptance Filter 1 (RXB0)
000 Acceptance Filter 0 (RXB0)

Если бит BUKT очищен, то здесь имеется 6 кодов, соответствующих 6 фильтрам. Если бит BUKT установлен, то 6 кодов соответствуют 6 фильтрам, плюс 2 дополнительных кода соответствуют RXF0 и RXF1, когда произошло перемещение данных из буфера RXB0 в буфер RXB1 (пролонгация RXB0).

Совпадение с несколькими фильтрами. Если произошло совпадение с одним или большим количеством фильтров, биты FILHIT будут кодировать двоичным значением фильтр с самым малым номером, для которого произошло совпадение с сообщением. Например, если сообщение соответствует совпадению с фильтрами RXF2 и RXF4, то в биты FILHIT будет загружено значение для RXF2. Это в сущности осуществляет приоритизацию фильтров допустимости так, что фильтры с меньшим номером имеют приоритет выше. Сообщения сравниваются с фильтрами в порядке очередности - от младшего номера фильтра к старшему. Это также гарантирует, что сообщение будет принято только в один буфер. Такой принцип подразумевает, что буфер RXB0 имеет приоритет выше, чем буфер RXB1.

Конфигурирование масок и фильтров. Регистры маски и фильтров могут быть модифицированы только тогда, когда MCP2515 находится в режиме конфигурации (Configuration mode, см. раздел "Режимы работы").

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

MCP2515 message acceptance mask and filter operation fig4 5

Рис. 4-5. Принцип работы маски и фильтров, определяющих допустимость принимаемого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[10:3]
Легенда R/W-x

7-0, SID[10:3]: биты фильтра стандартного идентификатора (Standard Identifier Filter). Здесь хранятся биты фильтра, накладываемые на биты [10:3] порции стандартного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[2:0]
- EXIDE - EID[17:16]
Легенда R/W-x U-0 R/W-x U-0 R/W-x

7-5, SID[2:0]: биты фильтра стандартного идентификатора (Standard Identifier Filter). Здесь хранятся биты фильтра, накладываемые на биты [2:0] порции стандартного идентификатора принятого сообщения.

4 не реализован, читается как 0.

3, EXIDE: бит разрешения расширенного идентификатора (Extended Identifier Enable).

1 фильтр прикладывается только к расширенным фреймам.
0 фильтр прикладывается только к стандартным фреймам.

2 не реализован, читается как 0.

1-0, EID[17:16]: биты фильтра расширенного идентификатора (Extended Identifier Filter). Здесь хранятся бит фильтра, накладываемые на биты [17:16] порции расширенного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[15:8]
Легенда R/W-x

7-0, EID[15:8]: биты расширенного идентификатора (Extended Identifier). В этих битах хранятся биты, прикладываемые к битам [15:8] порции расширенного идентификатора принятого сообщения, или к байту 0 в принятых данных, если соответствующие RXM=00 и EXIDE=0.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[7:0]
Легенда R/W-x

7-0, EID[7:0]: биты расширенного идентификатора (Extended Identifier). В этих битах хранятся биты, прикладываемые к битам [7:0] порции расширенного идентификатора принятого сообщения, или к байту 1 в принятых данных, если соответствующие RXM=00 и EXIDE=0.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[10:3]
Легенда R/W-0

7-0, SID[10:3]: биты маски стандартного идентификатора (Standard Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [10:3] порции стандартного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SID[2:0]
- - - EID[17:16]
Легенда R/W-0 U-0 U-0 U-0 R/W-0

7-5, SID[2:0]: биты маски стандартного идентификатора (Standard Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [2:0] порции стандартного идентификатора принятого сообщения.

4-2 не реализованы, читаются как 0.

1-0, EID[17:16]: биты маски расширенного идентификатора (Extended Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [17:16] порции расширенного идентификатора принятого сообщения.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[15:8]
Легенда R/W-0

7-0, EID[15:8]: биты маски расширенного идентификатора (Extended Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [15:8] порции расширенного идентификатора принятого сообщения. Если соответствующие биты RXM=00 и EXIDE=0, то эти биты прикладываются к байту 0 принятых данных.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит EID[7:0]
Легенда R/W-0

7-0, EID[7:0]: биты маски расширенного идентификатора (Extended Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [7:0] порции расширенного идентификатора принятого сообщения. Если соответствующие биты RXM=00 и EXIDE=0, то эти биты прикладываются к байту 1 принятых данных.

[Интервалы времени шины CAN]

Все узлы, присутствующие на определенной шине CAN, должны иметь одинаковую номинальную скорость обмена данными (bit rate). Протокол CAN использует принцип кодирования без возврата к нулю NRZ (Non Return to Zero), который не предоставляет вставку тактов в поток данных. Таким образом, такты приема должны быть восстановлены принимающими узлами, и синхронизированы с тактами передатчика.

Все генераторы и интервалы времени передачи могут отличаться от узла к узлу, так что приемник должен иметь некую фазовую автоподстройку частоты (Phase Lock Loop, PLL) для синхронизации перепадов передачи и поддержки тактирования приемника. Поскольку данные кодируются по принципу NRZ, то нужно применять вставку бита (так называемый бит-стаффинг), чтобы гарантировать, что перепад произойдет как минимум не реже чем каждые 6 битовых интервалов, чтобы поддерживать синхронизацию цифровой автоподстройки частоты (Digital Phase Lock Loop, DPLL).

Формирование битовых интервалов реализовано в MCP2515 с использованием системы DPLL, которая конфигурируется для синхронизации с приходящими данными, а также для предоставления номинальных интервалов времени для передаваемых данных. DPLL разбивает каждый битовый интервал на несколько сегментов, построенных на минимальных интервалах времени, так называемых квантов времени (Time Quanta, сокращенно TQ).

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

Время бита CAN. Все устройства на шине CAN должны использовать одинаковую скорость следования бит (bit rate). Однако не требуется, чтобы у всех устройств была абсолютно одна и та же тактовая частота главного генератора. Для разных частот отдельных устройств bit rate подстраивается настройкой прескалера скорости (Baud Rate Prescaler), и количества квантов времени в каждом сегменте.

Время бита CAN строится из не перекрывающихся сегментов. Каждый из этих сегментов строится их целого числа интервалов времени, называемых Time Quanta (TQ), как будет объяснено далее в этом документе. Номинальная скорость (Nominal Bit Rate, NBR) определяется спецификацией CAN как количество бит в секунду, передаваемых идеальным передатчиком без ресинхронизации. Это описывается выражением:

NBR = fbit = 1/tbit                                Выражение 5-1

Номинальное время бита. Номинальное время бита (Nominal Bit Time, NBT) tbit строится из не перекрывающихся сегментов (рис. 5-1). Таким образом, NBT это сумма следующих сегментов времени:

tbit = tSyncSeg + tPropSeg + tPS1 + tPS2

MCP2515 CAN bit time segments fig5 1

Рис. 5-1. Сегменты времени бита шины CAN.

С интервалом NBT связаны точка выборки (sample point), ширина скачка синхронизации (Synchronization Jump Width, SJW) и время обработки информации (Information Processing Time, IPT), что будет рассмотрено далее.

Сегмент синхронизации. Synchronization Segment (SyncSeg) это первый сегмент в NBT, и он используется для синхронизации узлов на шине CAN. Ожидаемые перепады бит должны происходить в интервале SyncSeg. Этот сегмент времени фиксирован, и равен 1 TQ.

Сегмент распространения. Propagation Segment (PropSeg) существует для компенсации физических задержек между узлами. Задержка распространения определена как двойная сумма времени распространения сигнала по проводам шины CAN, включая задержки, вносимые драйвером шины. Параметр PropSeg может программироваться в диапазоне 1..8 TQ.

Сегмент фазы 1 и сегмент фазы 2. Два сегмента фазы PS1 и PS2 используются для компенсации ошибок фазы на шине. PS1 может быть удлинен (или PS2 может быть укорочен) пересинхронизацией. PS1 программируется в интервале 1..8 TQ, и PS2 программируется в интервале 2..8 TQ.

Точка выборки. Sample point (точка выборки, или точка оцифровки сигнала) это момент времени внутри бита, по которому читается и интерпретируется логический уровень сигнала. Точка выборки находится в конце интервала PS1. Исключение из этого правила - когда режим выборки конфигурируется для выборки 3 раза на 1 бит. В этом случае, пока бит все еще оцифровывается по окончании PS1, делаются еще 2 дополнительные выборки на половинах интервалов TQ до окончания PS1, при этом значение прочитанного бита определяется по мажоритарному принципу.

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

PS2min = IPT = 2TQ

Ширина скачка синхронизации. Synchronization Jump Width (SJW) подстраивает тактовую частоту бит, как это необходимо, в диапазоне 1..4 TQ (определяется конфигурацией), чтобы сохранять синхронизацию с передаваемым сообщением. Синхронизация более подробно рассматривается в этом документе далее.

Квант времени (Time Quantum). Каждый из сегментов времени составляет время бита, и состоит из целого количества минимальных единиц времени, называемых Time Quanta (TQ). Длина каждого интервала Time Quantum базируется на периоде кварцевого генератора (tOSC). Базовое значение TQ рано двойному периоду генератора. На рис. 5-2 показано, как период бита вычисляется из TOSC и TQ. Длина TQ равна одному периоду тактов (tBRPCLK), что программируется настройкой прескалера, так называемого Baud Rate Prescaler (BRP). Длительность кванта времени TQ может быть вычислена по выражению 5-2:

TQ = 2*BRP*TOSC = 2*BRP/FOSC                                                 Выражение 5-2

Здесь BRP соответствует конфигурации, как это показано в описании регистра 5-1.

MCP2515 TQ and bit period fig5 2

Рис. 5-2. TQ и период бита.

[Синхронизация]

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

Когда детектирован перепад в передаваемых данных, логика будет сравнивать место положения перепада с ожидаемым временем (SyncSeg). Затем схема будет при необходимости подстраивать интервалы времени PS1 и PS2.

Для синхронизации используются 2 механизма:

1. Жесткая синхронизация.
2. Пересинхронизация (ресинхронизация).

Жесткая синхронизация. Такой механизм синхронизации выполняется только когда происходит перепад recessive-to-dominant во время ожидания шины (BUS IDLE, т. е. на шине нет сигналов), что означает начало сообщения. После жесткой синхронизации счетчики времени бита перезапускаются с SyncSeg.

Жесткая синхронизация приводит к тому, что перепад происходит внутри сегмента синхронизации перезагруженного времени бита. По правилам синхронизации, если произошла жесткая синхронизация, то во времени интервала бита не будет происходить пересинхронизация.

Пересинхронизация (ресинхронизация). В результате этого механизма синхронизации интервал PS1 может быть удлинен, или PS2 может быть укорочен. Величина укорачивания или удлинения сегментов фазы буфера ограничена верхним пределом, задаваемым шириной шага синхронизации (Synchronization Jump Width, SJW).

Величина SJW будет добавлена к PS1 или вычтена из PS2 (см. рис. 5-3). SJW представляет циклическую фильтрацию DPLL. Интервал SJW программируется в диапазоне 1..4 TQ.

MCP2515 synchronizing bit time fig5 3a
Без ресинхронизации (e = 0)
MCP2515 synchronizing bit time fig5 3b
Ресинхронизация по медленному передатчику (e > 0)
MCP2515 synchronizing bit time fig5 3c
Ресинхронизация по быстрому передатчику (e < 0)

Рис. 5-3. Синхронизация времени бита.

Ошибки фазы. Метод кодирования NRZ не подразумевает вставки в передаваемое сообщение тактовой частоты бит. Информация от тактировании выделяется по перепадам recessive-to-dominant на шине. Свойство протокола, которое устанавливает фиксированный максимум количества следующих друг за другом одинаковых бит (bitstuffing, бит-стаффинг, т. е. вставка противоположных по уровню бит) гарантирует, что в течение фрейма поток бит будет содержать перепады, необходимые для ресинхронизации.

Ошибка фазы на перепаде определяется позицией перепада относительно SyncSeg, и эта ошибка измеряется в интервалах TQ. Ошибка фазы, измеряемая в единицах TQ, определяется следующим образом:

• e = 0, если перепад попадает в интервал сегмента синхронизации (SYNCSEG).
• e > 0, если перепад попадает перед точкой выборки (SAMPLE POINT), тогда TQ добавляется к PS1.
• e < 0, если перепад попадает после точки выборки предыдущего бита, тогда TQ вычитается из PS2.

e = 0, нет ошибки фазы. Когда e=0, то ошибка фазы отсутствует. Если магнитуда ошибки фазы меньше или равна запрограммированному значению SJW, то эффект от ресинхронизации тот же самый, что и от жесткой синхронизации.

e > 0, положительная ошибка фазы. Если величина ошибки больше SJW, если ошибка фазы положительна, то PS1 увеличивается на величину, равную SJW.

e < 0, отрицательная ошибка фазы. Если величина ошибки фазы больше, чем ширина шага ресинхронизации, и ошибка фазы отрицательна, то PS2 укорачивается на величину, равную SJW.

Правила ресинхронизации:

1. Для синхронизации используются только лишь перепады уровня recessive-to-dominant.
2. Разрешается только одна синхронизация в одном интервале бита.
3. Перепад будет использоваться для синхронизации только если значение, детектированное на предыдущей точке выборки (ранее прочитанное значение на шине) отличается от значения шины, которое следует сразу за перепадом.
4. Передающий узел не ресинхронизируется при положительной фазе ошибки (e > 0).
5. Если абсолютная величина ошибки фазы больше SJW, соответствующий сегмент фазы будет подстроен на величину, равную SJW.

Программирование сегментов времени. Для программирования сегментов времени нужно соблюдать следующие требования:

• PropSeg + PS1 >= PS2
• PropSeg + PS1 >= TDELAY
• PS2 > SJW

Например, если предположить, что скорость 125 кГц то с частотой кварца FOSC = 20 МГц нужно:

TOSC = 50 нс, выбор BRP[5:0] = 04h, тогда TQ = 500 нс. Чтобы получить 125 кГц, время бита должно быть равно 16 TQ.

Обычно выборка бита должна происходить на интервале 60-70% времени бита, в зависимости от параметров системы. Также обычно TDELAY равна 1..2 TQ.

SyncSeg = 1 TQ и PropSeg = 2 TQ. Чтобы установить PS1 = 7 TQ, нужно поместить выборку в момент 10 TQ после перехода. Это оставляет 6 TQ для PS2.

Поскольку PS2 = 6, то в соответствии с правилами SJW должен быть максимум 4 TQ. Однако большое значение SJW обычно нужно только когда генерация тактов разных узлов не точна или нестабильна, например при использовании керамических резонаторов. Так что для SJW обычно достаточно значения 1.

Допуск на погрешность частоты генератора. Выработано эмпирическое правило, что требования к точности формирования интервалов времени бита позволяют ставить керамические резонаторы в приложениях, где используются скорости до 125 килобит/сек. Для полного диапазона скоростей шины протокола CAN требуется применение кварцевого резонатора. Допускается максимальный уход частоты генератора от узла к узлу 1.7%.

[Регистры конфигурации интервалов бита]

Конфигурационные регистры CNF1, CNF2, CNF3 управляют интервалами времени для формирования бит интерфейса шины CAN. Эти регистры можно модифицировать только когда MCP2515 находится в режиме конфигурации (Configuration mode, см. раздел "Режимы работы").

CNF1. Биты BRP[5:0] управляют прескалером скорости (Baud Rate Prescaler). Эти биты устанавливают длину TQ относительно входной частоты OSC1, с минимальной длиной TQ, равной 2 TOSC (когда BRP[5:0] = b000000). Биты SJW[1:0] выбирают ширину шага ресинхронизации в единицах интервалов TQ.

CNF2. Биты PRSEG[2:0] устанавливают длину (в единицах интервалов TQ) сегмента распространения. Биты PHSEG1[2:0] устанавливают длину PS1 (также в единицах интервалов TQ).

Бит SAM управляет количеством выборок оцифровки сигнала на выводе RXCAN. Если установить этот бит в 1, то тогда сигнал приема будет опрашиваться 3 раза: дважды на интервале TQ/2 перед точкой выборки и один раз на обычной точке выборки (которая находится в конце интервала PS1). Значение уровня шины определяется по мажоритарному принципу. Если бит SAM установлен в 0, то вывод RXCAN опрашивается один раз в точке выборки.

Бит BTLMODE управляет тем, как определяется длина PS2. Если этот бит установлен в 1, то длина PS2 определяется битами PHSEG2[2:0] регистра CNF3. Если же бит BTLMODE установлен в 0, то длина PS2 больше, чем PS1 и время обработки информации (которое для MCP2515 фиксировано на значении 2 TQ).

CNF3. Биты PHSEG2[2:0] устанавливают длину PS2 (в единицах интервалов TQ), если бит CNF2.BTLMODE установлен в 1. Если бит BTLMODE установлен в 0, то биты PHSEG2[2:0] не оказывают никакого влияния.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SJW[1:0]
BRP[5:0]
Легенда R/W-0 R/W-0

7-6, SJW[1:0]: ширина шага синхронизации (Synchronization Jump Width Length).

11 ширина = 4 TQ
10 ширина = 3 TQ
01 ширина = 2 TQ
00 ширина = 1 TQ

5-0, BRP[5:0]: биты управления прескалером скорости (Baud Rate Prescaler). TQ = 2*(BRP+1)/FOSC.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит BTLMODE SAM PHSEG1[2:0]
PRSEG[2:0]
Легенда R/W-0 R/W-0 R/W-0 R/W-0

7, BTLMODE: бит управления длиной PS2 (PS2 Bit Time Length).

1 длина PS2 определяется битами PHSEG22:PHSEG20 регистра CNF3.
0 длина PS2 больше PS1 и IPT (IPT = 2TQ).

6, SAM: бит конфигурации точки выборки (Sample Point Configuration).

1 вход приемника опрашивается 3 раза возле точки выборки.
0 вход приемника опрашивается 1 раз в точке выборки.

5-3, PHSEG1[2:0]: биты управления длиной интервала PS1 (PS1 Length). PS1 = (PHSEG1+1)*TQ.

2-0, PRSEG[2:0]: биты управления длиной сегмента распространения (Propagation Segment Length). PropSeg = (PRSEG+1)*TQ.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит SOF WAKFIL - - - PHSEG2[2:0]
Легенда R/W-0 R/W-0 U-0 U-0 U-0 R/W-0

7, SOF: бит сигнала начала фрейма (Start-of-Frame signal bit). Если CANCTRL.CLKEN = 0, бит SOF не оказывает никакого влияния. Если CANCTRL.CLKEN = 1, то:

1 вывод CLKOUT разрешен для сигнала SOF.
0 вывод CLKOUT разрешен для функции вывода тактовых импульсов.

6, WAKFIL: бит фильтра пробуждения (Wake-up Filter).

1 фильтр пробуждения разрешен.
0 фильтр пробуждения запрещен.

5-3 биты не реализованы, читаются как 0.

2-0, PHSEG2[2:0]: управление длиной PS2. PS2 = (PHSEG2+1)*TQ. Минимально допустимая длина для PS2 равна 2TQ.

[Детектирование ошибок]

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

CRC Error. Проверка контрольной суммы (Cyclic Redundancy Check, CRC): передатчик вычисляет специальные проверочные биты для данных начиная от SOF и заканчивая полем данных. Последовательность бит CRC передается в поле CRC фрейма. Принимающий узел также вычисляет последовательность бит CRC по той же самой формуле, что и передатчик, и сравнивает вычисленную CRC с принятой. Если обнаружено несовпадение, то произошла ошибка CRC, и тогда генерируется фрейм ошибки. Передача сообщения повторяется.

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

Form Error. Если узел детектирует доминантный бит в одном из 4 сегментов, где его не должно быть - включая конец фрейма end-of-frame (EOF), промежуток между фреймами interframe space (IFS), разделитель подтверждения (acknowledge delimiter) или разделитель CRC, то тогда возникает ошибка формы, и генерируется ошибка фрейма. Передача сообщения повторяется.

Bit Error. Ошибка бита возникает, если передатчик детектирует противоположный уровень бита, не соответствующий тому, который был послан (например, передавался доминантный бит, но был детектирован рецессивный, или был передан рецессивный бит, но на шине вместо него был обнаружен доминантный бит).

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

Stuff Error. Если в промежутке между началом фрейма (start-of-frame, SOF) и разделителем CRC, обнаружено 6 следующих друг за другом бит одинаковой полярности, то нарушено правило бит-стаффинга. Тогда происходит ошибка бит-стаффинга и генерируется ошибка фрейма. Передача сообщения повторяется.

Состояния ошибки. Про обнаруженные ошибки все другие узлы сети CAN узнают через генерацию и получение фреймов ошибки (error frame, см. рис. 2-4). Передача фрейма ошибочного сообщения прерывается, и этот фрейм повторяется, как только это становится возможным. Кроме того, каждый узел CAN находится в одном из 3 состояний ошибки, каждое из которых соответствует значению внутренних счетчиков ошибок:

1. Error-active (состояние активной ошибки).
2. Error-passive (состояние пассивной ошибки).
3. Bus-off (шина выключена, это относится только к передатчику).

Состояние error-active это обычное состояние, когда узел может передавать сообщения и фреймы активной ошибки (построенного из доминантных бит, см. рис. 2-4) без каких-либо ограничений.

В состоянии error-passive могут передаваться сообщения и фреймы пассивной ошибки (состоящие из рецессивных бит).

Состояние bus-off временно делает невозможным для узла участвовать в обмене по шине. Во время этого состояния сообщения не могут ни приниматься, ни передаваться. Только передатчики могут перейти в состояние bus-off.

Режимы ошибки и счетчики ошибок. Контроллер MCP2515 содержит 2 счетчика ошибок: счетчик ошибок приема Receive Error Counter, REC (см. регистр 6-2) и счетчик ошибок передачи Transmit Error Counter, TEC (см. регистр 6-1). Значения этих обоих счетчиков может прочитать управляющий микроконтроллер. Эти счетчики инкрементируются / декрементируются в соответствии со спецификацией шины CAN.

MCP2515 находится в состоянии error-active, если значение обоих счетчиков меньше 128, предела error-passive. В состояние error-passive MCP2515 переходит, если как минимум один из счетчиков ошибок равен или больше 128.

В состояние bus-off контроллер переходит, если TEC превышает 255, предел bus-off. Контроллер остается в этом состоянии, пока не будет принята последовательность восстановления шины (bus-off recovery sequence). Bus-off recovery sequence состоит из 128 передач следующих друг за другом 11 последовательных рецессивных бит (см. рис. 6-1).

Примечание: после того, как MCP2515, перейдет в bus-off, он восстановится обратно в состояние error-active без какого-либо вмешательства со стороны управляющего микроконтроллера, если шина остается в состоянии ожидания (idle) на время 128 * 11 бит. Если это нежелательно, то такая ситуация должна быть адресована обработчику прерывания.

MCP2515 error modes state diagram fig6 1

Рис. 6-1: Диаграмма переходов между состояниями режимов ошибки.

Текущий режим работы MCP2515 может быть прочитан управляющим микроконтроллером через регистр EFLG (см. регистр 6-3).

Дополнительно есть бит флага предупреждения о состоянии ошибки (error state warning flag, EFLG:EWARN), который установится, если как минимум один из счетчиков ошибок превысит лимит 96. Бит EWARN сбрасывается, если оба счетчика ошибок станут меньше 96.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит TEC[7:0]
Легенда R-0

7-0, TEC[7:0]: биты счетчика ошибок передачи (Transmit Error Count).

№ разрядов 7 6 5 4 3 2 1 0
Имена бит REC[7:0]
Легенда R-0

7-0, REC[7:0]: биты счетчика ошибок приема (Receive Error Count).

№ разрядов 7 6 5 4 3 2 1 0
Имена бит RX1OVR RX0OVR TXBO TXEP RXEP TXWAR RXWAR EWARN
Легенда R/W-0 R/W-0 R-0 R-0 R-0 R-0 R-0 R-0

7, RX1OVR: бит флага переполнения буфера приема 1 (Receive Buffer 1 Overflow Flag). Устанавливается, когда буфером RXB1 было принято допустимое сообщение, и CANINTF.RX1IF=1. Бит RX1OVR должен быть сброшен управляющим микроконтроллером.

6, RX0OVR: бит флага переполнения буфера приема 0 (Receive Buffer 0 Overflow Flag). Устанавливается, когда буфером RXB0 было принято допустимое сообщение, и CANINTF.RX0IF=1. Бит RX0OVR должен быть сброшен управляющим микроконтроллером.

5, TXBO: бит флага ошибки отключения шины (Bus-Off Error Flag). Устанавливается, когда TEC достигает значения 255. Сбрасывается после получения последовательности восстановления шины (bus recovery sequence).

4, TXEP: бит флага пассивной ошибки передачи (Transmit Error-Passive Flag). Устанавливается, когда TEC равен или больше 128. Сбрасывается, когда TEC меньше 128.

3, RXEP: бит флага пассивной ошибки приема (Receive Error-Passive Flag). Устанавливается, когда REC равен или больше 128. Сбрасывается, когда REC меньше 128.

2, TXWAR: бит флага предупреждения об ошибке передачи (Transmit Error Warning Flag). Устанавливается, когда TEC равен или больше 96. Сбрасывается, когда TEC меньше 96.

1, RXWAR: бит флага предупреждения об ошибке приема (Receive Error Warning Flag). Устанавливается, когда REC равен или больше 96. Сбрасывается, когда REC меньше 96.

0, EWARN: бит флага предупреждения об ошибке (Error Warning Flag). Устанавливается, когда TEC или REC равен или больше 96 (т. е. когда TXWAR или RXWAR = 1). Сбрасывается, когда оба счетчика, и REC, и TEC меньше 96.

[Прерывания]

У контроллера MCP2515 есть 8 источников прерывания. Регистр CANINTE содержит отдельные биты разрешения прерываний для каждого из источников. Регистр CANINTF содержит соответствующие биты флагов прерываний для каждого из источников. Когда происходит прерывание, вывод /INT (выход) переводится в низкий уровень контроллером MCP2515, и остается в низком уровне, пока прерывание не будет очищено управляющим микроконтроллером. Прерывание не может быть очищено, если преобладает соответствующее прерыванию условие.

Рекомендуется, чтобы использовалась команда модификации бита (Bit Modify) для сброса битов флага в регистре CANINTF вместо обычных операций записи. Это гарантирует нежелательное изменение другого флага, который может поменяться во время команды записи (Write), что потенциально может привести к тому, что какое-то прерывание может быть пропущено.

Следует отметить, что флаги CANINTF читаются/записываются, и для управляющего микроконтроллера может быть сгенерировано прерывание при установке любого из флагов CANINTF, если это разрешено соответствующим битом CANINTE.

Биты кода прерывания. Источник ожидающего обработки прерывания показывается битами CANSTAT.ICOD (код прерывания), что показано в регистре 10-2. При событии, когда произошло несколько прерываний, /INT останется в лог. 0, пока все прерывания не будут сброшены управляющим микроконтроллером. Биты CANSTAT.ICOD будут отражать код для прерывания с самым высокоприоритетным прерыванием, которое в настоящий момент ожидает своей обработки. Прерывания приоритезируются внутри MCP2515 так, что чем меньше значение ICOD, тем выше приоритет прерывания. Как только было очищено прерывание с самым высоким приоритетом, битами ICOD будет отображаться код следующего из самых приоритетных прерываний, ожидающих обработки (если такие имеются, см. таблицу 7-1). Битами ICOD отражаются только те источники прерывания, которые связаны с установленными битами регистра разрешения прерываний CANINTE.

Таблица 7-1: как декодируются биты ICOD[2:0].

ICOD[2:0] Двоичное выражение
000 /ERR•/WAK•/TX0•/TX1•/TX2•/RX0•/RX1
001 ERR
010 /ERR•WAK
011 /ERR•/WAK•TX0
100 /ERR•/WAK•/TX0•TX1
101 /ERR•/WAK•/TX0•/TX1•TX2
110 /ERR•/WAK•/TX0•/TX1•/TX2•RX0
111 /ERR•/WAK•/TX0•/TX1•/TX2•/RX0•RX1

Примечание: /ERR связано с CANINTE, ERRIE.

Прерывание передачи. Когда разрешено прерывание передачи (CANINTE.TXnIE=1), будет генерироваться прерывание выводом /INT, как только соответствующий буфер передачи опустошился и готов к загрузке нового сообщения. Бит CANINTF.TXnIF будет установлен, чтобы показать источник прерывания. Это прерывание очищается сбросом бита TXnIF.

Прерывание приема. Когда разрешено прерывание приема (CANINTE.RXnIE=1), будет генерироваться прерывание выводом /INT, как только будет успешно принято и загружено сообщение в соответствующий буфер приема. Это прерывание активизируется сразу после получения поля EOF. Бит CANINTF.RXnIF будет установлен, чтобы показать источник прерывания. Это прерывание очищается сбросом бита RXnIF.

Прерывание ошибки сообщения. Когда происходит ошибка при передаче или приеме сообщения, установится флаг ошибки сообщения (CANINTF.MERRF) и, если установлен бит CANINTE.MERRE, будет генерироваться прерывание выводом /INT. Это предназначено для упрощения детектирования скорости шины совместно с режимом "только прослушивание" (Listen-Only mode).

Прерывание для пробуждения от активности шины (Bus Activity Wake-up). Когда MCP2515 находится в режиме сна (Sleep mode), и разрешено прерывание пробуждения по активности шины (CANINTE.WAKIE=1), будет сгенерировано прерывание выводом /INT, и будет установлен бит CANINTF.WAKIF, если была детектирована активность шины CAN. Это прерывание приведет к выходу MCP2515 из режима сна. Это прерывание сбрасывается очисткой бита WAKIF.

Примечание: MCP2515 пробуждается только в режим Listen-Only.

Прерывание ошибки. Когда разрешено прерывание ошибки (CANINTE.ERRIE=1), будет сгенерировано прерывание выводом /INT, если произойдет переполнение или если изменится состояние ошибки передатчика или приемника. Содержимое регистра флагов ошибки (Error Flag, EFLG) покажет одно из следующих условий.

Переполнение в приемнике. произойдет, когда MAB собрал допустимое принятое сообщение (это сообщение удовлетворяет критерию фильтров допустимости) и для загрузки сообщения нет свободных буферов приема, соответствующих фильтру. Тогда будет установлен соответствующий бит EFLG.RXnOVR, чтобы показать событие переполнения. Этот бит должен быть очищен управляющим микроконтроллером.

Предупреждение приемника. Счетчик REC достиг предела предупреждения об ошибке 96.

Предупреждение передатчика. Счетчик TEC достиг предела предупреждения об ошибке 96.

Приемник в ERROR-PASSIVE. Счетчик REC превысил предел error-passive 127, и контроллер перешел в состояние error-passive.

Передатчик в ERROR-PASSIVE. Счетчик TEC превысил предел error-passive 127, и контроллер перешел в состояние error-passive.

BUS-OFF. Счетчик TEC достиг значения 255, и устройство перешло в состояние отключения от шины.

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

№ разрядов 7 6 5 4 3 2 1 0
Имена бит MERRE WAKIE ERRIE TX2IE TX1IE TX0IE RX1IE RX0IE
Легенда R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0

7, MERRE: бит разрешения прерывания ошибки (Message Error Interrupt Enable). 1 разрешено прерывание от ошибки при приеме или передаче сообщения, 0 запрещено.

6, WAKIE: бит разрешения прерывания пробуждения (Wake-up Interrupt Enable). 1 разрешено прерывание от активности шины CAN, 0 запрещено.

5, ERRIE: бит разрешения прерывания ошибки (Error Interrupt Enable, регистром EFLG декодируются несколько источников прерывания). 1 прерывание по изменению состояния EFLG, 0 запрещено.

4, TX2IE: бит разрешения прерывания по опустошению буфера передачи 2 (Transmit Buffer 2 Empty Interrupt Enable). 1 прерывание по опустошению буфера TXB2, 0 запрещено.

3, TX1IE: бит разрешения прерывания по опустошению буфера передачи 1 (Transmit Buffer 1 Empty Interrupt Enable). 1 прерывание по опустошению буфера TXB1, 0 запрещено.

2, TX0IE: бит разрешения прерывания по опустошению буфера передачи 0 (Transmit Buffer 0 Empty Interrupt Enable). 1 прерывание по опустошению буфера TXB0, 0 запрещено.

1, RX1IE: бит разрешения прерывания по заполнению буфера приема 1 (Receive Buffer 1 Full Interrupt Enable). 1 прерывание, когда сообщение принято в RXB1, 0 запрещено.

0, RX0IE: бит разрешения прерывания по заполнению буфера приема 0 (Receive Buffer 0 Full Interrupt Enable). 1 прерывание, когда сообщение принято в RXB0, 0 запрещено.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит MERRF WAKIF ERRIF TX2IF TX1IF TX0IF RX1IF RX0IF
Легенда R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0

7, MERRF: флаг прерывания ошибки сообщения (Message Error Interrupt Flag).

6, WAKIF: флаг прерывания пробуждения (Wake-up Interrupt Flag).

5, ERRIF: флаг прерывания ошибки (Error Interrupt Flag), источники прерывания декодируются содержимым регистра EFLG.

4, TX2IF: флаг прерывания опустошения буфера передачи 2 (Transmit Buffer 2 Empty Interrupt Flag).

3, TX1IF: флаг прерывания опустошения буфера передачи 1 (Transmit Buffer 1 Empty Interrupt Flag).

2, TX0IF: флаг прерывания опустошения буфера передачи 0 (Transmit Buffer 0 Empty Interrupt Flag).

1, RX1IF: флаг прерывания заполнения буфера приема 1 (Receive Buffer 1 Full Interrupt Flag).

0, RX0IF: флаг прерывания заполнения буфера приема 0 (Receive Buffer 0 Full Interrupt Flag).

Примечание: каждый из этих флагов должен быть очищен управляющим микроконтроллером, чтобы условие события соответствующего прерывания было сброшено. Если флаг = 1, то ожидается обработка соответствующего прерывания, если 0 то нет ожидающего обработки прерывания.

[Генератор]

MCP2515 разработан в расчете использования совместно с кварцевым или керамическим резонатором, подключенным между выводами OSC1 и OSC2. Генератор MCP2515 требует использования кристалла с параллельным срезом. Использование кристалла с последовательным срезом может дать уход частоты за пределы, установленные производителем кристалла. Стандартная схема генератора показана на рис. 8-1. 

MCP2515 crystal ceramic resonator fig8 1

Рис. 8-1. Работа генератора от кварцевого или керамического резонатора.

Примечания:

(1) Последовательно включенный резистор (RS) может потребоваться для кварцев с типом среза AT (AT strip-cut).
(2) Резистор обратной связи (RF), имеет обычный номинал в диапазоне 2 .. 10 МОм.

MCP2515 может также управляться от внешнего источника тактов, подключенного к выводу OSC1, как это показано на рис. 8-2 и рис. 8-3.

MCP2515 external clock fig8 2

Рис. 8-2. Работа от внешнего источника тактов.

Примечания:

(1) Может использоваться резистор, подключенный на землю, чтобы уменьшить шумы в системе. Это может увеличить потребляемый ток.
(2) Должны быть учтены ограничения скважности тактов (Duty cycle), см. таблицу 12-1 даташита [1].

MCP2515 external series resonant crystal oscillator circuit fig8 3

Рис. 8-3. Схема внешнего генератора для кварцев с последовательным типом среза(1).

Примечание (1): должны быть учтены ограничения скважности тактов (Duty cycle), см. таблицу 12-1 даташита [1].

Таймер запуска генератора. В контроллер MCP2515 использует Oscillator Start-up Timer (OST), который удерживает MCP2515 в состоянии сброса (Reset), чтобы гарантировать, что генератор стабилизирует свою частоту перед тем, как внутреннее состояние контроллера изменится на рабочее. OST остается в состоянии Reset на первые 128 тактов OSC1 после включения питания, или после события пробуждения из режима сна (Sleep mode). Следует отметить, что не должны быть осуществлены операции протокола SPI, пока не истечет время таймера OST.

Вывод CLKOUT. предназначен для разработчика системы в целях использования в качестве главного источника тактов системы, или для других устройств в системе. У вывода CLKOUT есть внутренний прескалер, который может делить частоту FOSC на 1, 2, 4 и 8. Функция CLKOUT разрешается одновременно с выбором настройки прескалера через регистр CANCNTRL (см. регистр 10-1).

Примечание: максимально допустимая частота на CLKOUT равна 25 МГц (см. таблицу 13-5 даташита [1]).

В таблицах 8-1 и 8-2 приведены рекомендации по выбору емкостей конденсаторов для керамических и кварцевых резонаторов. Общие указания по выбору конденсаторов: указанные значения емкостей были проверены как базовые для запуска генератора и работы контроллера. Значения не были оптимизированы. Могут потребоваться разные значения конденсаторов, чтобы достичь качественных параметров генератора для определенных условий. Пользователь должен протестировать генератор при разных ожидаемых значениях напряжения питания VDD во всем диапазоне температур эксплуатации. См. также дополнительные примечания (1)..(4).

Таблица 8-1. Выбор конденсаторов для керамических резонаторов.

Типичные используемые значения емкости конденсаторов
Режим Частота OSC1 OSC2
HS 8 МГц 27 пФ 27 пФ
16 МГц 22 пФ 22 пФ
Использовались резонаторы:
4.0 МГц
8.0 МГц
16.0 МГц

Таблица 8-2. Выбор конденсаторов для кварцевого генератора.

Типичные используемые значения емкости конденсаторов
Тип генератора(1)(4) Частота кварца(2) OSC1 OSC2
HS 4 МГц 27 пФ 27 пФ
  8 МГц 22 пФ 22 пФ
  20 МГц 15 пФ 15 пФ
Использовались кварцы(3):
4.0 МГц
8.0 МГц
20.0 МГц

Примечания:

(1) Хотя повышенная емкость увеличивает стабильность генератора, это также увеличивает и время запуска генератора.
(2) Поскольку у резонатора/кварца есть собственные характеристики, пользователь должен проконсультироваться у производителя резонатора/кварца на предмет получения соответствующих значений для внешних компонентов.
(3) Может потребоваться резистор RS, чтобы избежать перегрузки кристалла с низким рабочим уровнем сигнала.
(4) Всегда проверяйте параметры генератора при изменениях VDD и температуры, ожидаемых в приложении.

Вывод CLKOUT становится активным при сбросе системы и по умолчанию остается в состоянии выдачи самой низкой частоты (делением на 8), так что это можно использовать для тактирования управляющего микроконтроллера.

Когда выставлен запрос на режим сна (Sleep mode), MCP2515 выдаст дополнительные 16 тактов на выводе CLKOUT перед входом в режим сна. В состоянии ожидания (Idle) вывода CLKOUT (когда контроллер находится в режиме сна) на его выходе присутствует лог. 0. Когда функция CLKOUT запрещена (CANCNTRL.CLKEN=0), вывод CLKOUT находится в состоянии высокого сопротивления (его выходной драйвер отключен).

Функция CLKOUT разработана так, чтобы гарантировать, что времена thCLKOUT и tlCLKOUT сохраняются, когда работа CLKOUT разрешена, запрещена или изменяется значение прескалера.

[Сброс]

MCP2515 различает два способа сброса:

1. Hardware Reset (аппаратный сброс) - низким уровнем на выводе /RESET.
2. SPI Reset - подачей команды Reset через SPI.

Функционал обоих видов сброса эквивалентен. Важно осуществить один из этих способов сброса после включения питания, чтобы гарантировать переход логики и регистров в свое состояние по умолчанию. Аппаратный сброс можно осуществить автоматически, путем подключения RC-цепочки к выводу /RESET pin (см. рис. 9-1). Значения элементов цепочки должны быть такие, чтобы импульс лог. 0 был длительностью как минимум 2 мкс после того, как VDD достигнет своего рабочего напряжения, как это определено электрическими параметрами (tRL).

MCP2515 RESET pin example fig9 1

Рис. 9-1: Пример схемы организации сброса с помощью ввода /RESET.

Примечания:

(1) Диод D помогает быстро разрядить конденсатор, когда падает уровень напряжения VDD (выключение питания).
(2) R1 = 1..10 кОм ограничит импульс тока, втекающий в вывод /RESET от внешнего конденсатора C, когда напряжение вывода /RESET упадет из-за разряда статического электричества (Electrostatic Discharge, ESD) или от перенапряжения (Electrical Overstress, EOS).

[Режимы работы]

У MCP2515 есть 5 режимов работы:

1. Configuration mode
2. Normal mode
3. Sleep mode
4. Listen-Only mode
5. Loopback mode

Рабочий режим выбирается через биты регистр CANCTRL.REQOP (см. описание регистра 10-1). Когда меняются режимы, то режим в действительности не поменяется, пока не завершатся все ожидающие передачи. Запрошенный режим может быть проверен чтением битов CANSTAT.OPMODE (см. регистр 10-2).

Configuration Mode. Перед активизацией MCP2515 должен быть инициализирован. Это возможно только в режиме конфигурации MCP2515. Режим конфигурации автоматически выбирается при включении питания, сбросе, или в него можно войти из любого другого режима путем установки бит CANTRL.REQOP в значение 100. Когда осуществлен вход в режим конфигурации, все счетчики ошибок очищаются. Только в режиме конфигурации можно изменить следующие регистры:

• CNF1, CNF2, CNF3
• TXRTSCTRL
• Регистры фильтров
• Регистры маски

Sleep Mode. У контроллера MCP2515 имеется внутренний режим сна, используемый для минимизации тока потребления устройства. Интерфейс SPI остается активным для чтения, даже когда MCP2515 находится в режиме сна, позволяя получить доступ к содержимому регистров.

Чтобы войти в режим сна, в регистре CANCTRL устанавливаются биты запроса смены режима (REQOP[2:0]). Биты CANSTAT.OPMODE показывают текущий рабочий режим. Эти биты должны быть прочитаны после отправки команды Sleep контроллеру MCP2515. MCP2515 остается активным и не войдет в режим сна, пока эти биты не покажут вход в режим сна.

Когда в устройство находится во внутреннем режиме сна, прерывание пробуждения (wake-up interrupt) остается активным (если оно было разрешено). Это сделано для того, чтобы управляющий микроконтроллер также может быть помещен в режим сна, и разбужен контроллером MCP2515, когда он обнаружит активность на шине.

Когда MCP2515 находится в режиме сна, он останавливает свой внутренний генератор. MCP2515 проснется, когда на шине обнаружится активность, или когда управляющий микроконтроллер через интерфейс SPI установит бит CANINTF.WAKIF для "генерации" попытки пробуждения (бит CANINTE.WAKIE также должен быть установлен, чтобы возникло прерывание пробуждения, wake-up interrupt).

В режиме сна MCP2515 вывод TXCAN будет оставаться в рецессивном состоянии.

Функции пробуждения. В режиме сна контроллер MCP2515 будет мониторить свой вход RXCAN на предмет обнаружения активности шины. Если установлен бит CANINTE.WAKIE, то контроллер проснется и сгенерирует прерывание для управляющего микроконтроллера. Поскольку внутренний генератор был выключен в режиме сна, понадобится некоторое время на запуск генератора и возврата контроллера в состояние, когда он снова сможет принимать сообщения. Это время определяется таймером запуска генератора (Oscillator Start-up Timer, OST), и определено равным 128 TOSC.

Контроллер проигнорирует сообщение, которое вывело его его из режима сна, как и все другие сообщения, которые проходили, пока контроллер еще не пробудился до конца. После пробуждения контроллер окажется в режиме "только прослушивание" (Listen-Only mode). Управляющий микроконтроллер должен установить нормальный режим (Normal mode) перед тем, как MCP2515 сможет обмениваться данными по шине.

Контроллер может быть запрограммирован для подключения фильтра низкой частоты по входу RXCAN, пока контроллер находится во внутреннем режиме сна. Эта возможность может использоваться для предотвращения ложного пробуждения из-за коротких выбросов помех на сигнальных проводах шины CAN. Бит CNF3.WAKFIL разрешает или запрещает работу этого фильтра.

Listen-Only Mode. Режим "только прослушивание" (Listen-Only mode) предоставляет MCP2515 возможность принимать абсолютно все сообщения (включая ошибочные) путем конфигурирования бит RXBnCTRL.RXM[1:0]. Этот режим можно использовать для приложений снифера / мониторинга шины CAN, или для детектирования скорости обмена по шине CAN для приложений с "горячим" подключением к шине.

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

Режим прослушки (Listen-Only mode) является "тихим" в том смысле, что контроллер в этом режиме не передает вообще никаких сообщений (включая флаги ошибок или сигналы подтверждения). В режиме прослушки будут приняты как допустимые, так и недопустимые и ошибочные сообщения, не взирая ни на какие фильтры и маски, или настройки режимов буфера (RXMn, биты Receive Buffer mode). Счетчики ошибок в режиме прослушки сбрасываются и деактивируются. Режим прослушки активируется установкой битов запроса смены режима регистра CANCTRL.

Loopback Mode. Режиме закольцовывания (Loopback mode) позволяет осуществлять внутренние пересылки из буферов передачи в буферы приема, без реальной пересылки сообщений по шине CAN. Этот режим можно использовать для разработки и проверки системы.

В режиме закольцовывания бит ACK игнорируется, и контроллер сможет принимать сообщения от самого себя, как будто это были бы сообщения от другого узла шины CAN. Loopback mode, как и режим прослушки, является "тихим", т. е. в этом режиме по шине CAN не будет передаваться никаких сообщений (включая флаги ошибки или сигналы подтверждения). Вывод TXCAN будет оставаться в рецессивном состоянии.

Фильтры и маски могут использоваться, чтобы позволить попадать в буферы приема только отдельным сообщениям. Маски могут быть установлены во все нули, чтобы обеспечить прием всех сообщений. Loopback активируется установкой битов запроса смены режима регистра CANCTRL.

Normal Mode. Нормальный режим это стандартный рабочий режим MCP2515. В этом режиме контроллер активно мониторит все сообщения на шине и генерирует биты подтверждения (Acknowledge bits), фреймы ошибки (error frames), и т. д. Также только в этом режиме MCP2515 будет сам передавать сообщения по шине CAN.

№ разрядов 7 6 5 4 3 2 1 0
Имена бит REQOP[2:0]
ABAT OSM CLKEN CLKPRE[1:0]
Легенда R/W-1 R/W-0 R/W-0 R/W-0 R/W-0 R/W-1 R/W-1

7-5, REQOP[2:0]: биты запроса смены режима работы (Request Operation mode).

000 установка Normal mode
001 установка Sleep mode
010 установка Loopback mode
011 установка Listen-Only mode
100 установка Configuration mode

Все другие значения бит REQOP недопустимы, и не должны использоваться. После включения питания REQOP = 111.

4, ABAT: бит отмены всех ожидающих передач (Abort All Pending Transmissions.

1 запрос на отмену всех ожидающих передачи буферов.
0 прервать запрос на отмену всех передач.

3, OSM: бит однократного режима передачи (One-Shot mode).

1 разрешено. Для передачи сообщения будет предпринята только одна попытка, независимо от наличия ошибок.
0 запрещено. Если это необходимо, сообщения будут отправляться повторно.

2, CLKEN: бит разрешения вывода тактов CLKOUT (CLKOUT Pin Enable).

1 вывод CLKOUT разрешен.
0 вывод CLKOUT запрещен (вывод находится в состоянии высокого сопротивления).

1-0, CLKPRE[1:0]: биты управления прескалером CLKOUT (CLKOUT Pin Prescaler).

00 FCLKOUT = System Clock/1
01 FCLKOUT = System Clock/2
10 FCLKOUT = System Clock/4
11 FCLKOUT = System Clock/8

№ разрядов 7 6 5 4 3 2 1 0
Имена бит OPMOD[2:0]
- ICOD[2:0]
-
Легенда R-1 R-0 R-0 U-0 R-0 U-0

7-5, OPMOD[2:0]: биты индикации текущего рабочего режима (Operation mode).

000 устройство находится в Normal mode
001 устройство находится в Sleep mode
010 устройство находится в Loopback mode
011 устройство находится в Listen-Only mode
100 устройство находится в Configuration mode

4 не реализован, читается как 0.

3-1, ICOD[2:0]: биты флагов кода прерывания (Interrupt Flag Code).

000 нет ожидающего обработки прерывания
001 прерывание ошибки (Error Interrupt)
010 прерывание пробуждения (Wake-up Interrupt)
011 прерывание опустошения буфера передачи 0 (TXB0 Interrupt)
100 прерывание опустошения буфера передачи 1 (TXB1 Interrupt)
101 прерывание опустошения буфера передачи 2 (TXB2 Interrupt)
110 прерывание заполнения буфера приема 0 (RXB0 Interrupt)
111 прерывание заполнения буфера приема 1 (RXB1 Interrupt)

0 не реализован, читается как 0.

[Карта регистров]

Адресация регистров MCP2515 показана в таблице 11-1. Адреса каждого регистра определяется по столбцу (старший ниббл адреса) и строке (младший ниббл адреса) таблицы. Расположение регистров на карте адресного пространства сделано таким образом, чтобы оптимизировать последовательный доступ при чтении или записи данных. Некоторые специфичные регистры управления и статуса позволяют осуществлять индивидуальную модификацию бит с использованием команды SPI Bit Modify. Регистры, которые позволяют использовать эту команду, показаны в серых ячейках таблицы. Обзор всех регистров управления MCP2515 приведен в таблице 11-2.

Таблица 11-1. Карта адресного пространства CAN-контроллера MCP2515.

LO HI
0000 0001 0010 0011 0100 0101 0110 0111
0000 RXF0SIDH RXF3SIDH RXM0SIDH TXB0CTRL TXB1CTRL TXB2CTRL RXB0CTRL RXB1CTRL
0001 RXF0SIDL RXF3SIDL RXM0SIDL TXB0SIDH TXB1SIDH TXB2SIDH RXB0SIDH RXB1SIDH
0010 RXF0EID8 RXF3EID8 RXM0EID8 TXB0SIDL TXB1SIDL TXB2SIDL RXB0SIDL RXB1SIDL
0011 RXF0EID0 RXF3EID0 RXM0EID0 TXB0EID8 TXB1EID8 TXB2EID8 RXB0EID8 RXB1EID8
0100 RXF1SIDH RXF4SIDH RXM1SIDH TXB0EID0 TXB1EID0 TXB2EID0 RXB0EID0 RXB1EID0
0101 RXF1SIDL RXF4SIDL RXM1SIDL TXB0DLC TXB1DLC TXB2DLC RXB0DLC RXB1DLC
0110 RXF1EID8 RXF4EID8 RXM1EID8 TXB0D0 TXB1D0 TXB2D0 RXB0D0 RXB1D0
0111 RXF1EID0 RXF4EID0 RXM1EID0 TXB0D1 TXB1D1 TXB2D1 RXB0D1 RXB1D1
1000 RXF2SIDH RXF5SIDH CNF3 TXB0D2 TXB1D2 TXB2D2 RXB0D2 RXB1D2
1001 RXF2SIDL RXF5SIDL CNF2 TXB0D3 TXB1D3 TXB2D3 RXB0D3 RXB1D3
1010 RXF2EID8 RXF5EID8 CNF1 TXB0D4 TXB1D4 TXB2D4 RXB0D4 RXB1D4
1011 RXF2EID0 RXF5EID0 CANINTE TXB0D5 TXB1D5 TXB2D5 RXB0D5 RXB1D5
1100 BFPCTRL TEC CANINTF TXB0D6 TXB1D6 TXB2D6 RXB0D6 RXB1D6
1101 TXRTSCTRL REC EFLG TXB0D7 TXB1D7 TXB2D7 RXB0D7 RXB1D7
1110 CANSTAT
1111 CANCTRL

Примечания: LO это младший ниббл адреса, HI это старший ниббл адреса регистра. Регистры, находящиеся в ячейках с серым фоном, позволяют манипулировать отдельными своими битами командой Bit Modify. Регистры, которые размещены в оранжевых ячейках (маски и фильтры приема), можно модифицировать и читать только в режиме конфигурации, в других режимах они читаются как 0.

Таблица 11-2. Общая информация по регистрам управления CAN-контроллера MCP2515.

Имя
регистра
Адрес (hex) Бит 7 Бит 6 Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0 POR/RST
BFPCTRL 0C - - B1BFS B0BFS B1BFE B0BFE B1BFM B0BFM --00 0000
TXRTSCTRL 0D - - B2RTS B1RTS B0RTS B2RTSM B1RTSM B0RTSM --xx x000
CANSTAT xE OPMOD2 OPMOD1 OPMOD0 - ICOD2 ICOD1 ICOD0 - 100- 000-
CANCTRL xF REQOP2 REQOP1 REQOP0 ABAT OSM CLKEN CLKPRE1 CLKPRE0 1110 0111
TEC 1C Счетчик ошибок передачи 0000 0000
REC 1D Счетчик ошибок приема 0000 0000
CNF3 28 SOF WAKFIL - - - PHSEG22 PHSEG21 PHSEG20 00-- -000
CNF2 29 BTLMODE SAM PHSEG12 PHSEG11 PHSEG10 PRSEG2 PRSEG1 PRSEG0 0000 0000
CNF1 2A SJW1 SJW0 BRP5 BRP4 BRP3 BRP2 BRP1 BRP0 0000 0000
CANINTE 2B MERRE WAKIE ERRIE TX2IE TX1IE TX0IE RX1IE RX0IE 0000 0000
CANINTF 2C MERRF WAKIF ERRIF TX2IF TX1IF TX0IF RX1IF RX0IF 0000 0000
EFLG 2D RX1OVR RX0OVR TXBO TXEP RXEP TXWAR RXWAR EWARN 0000 0000
TXB0CTRL 30 - ABTF MLOA TXERR TXREQ - TXP1 TXP0 -000 0-00
TXB1CTRL 40 - ABTF MLOA TXERR TXREQ - TXP1 TXP0 -000 0-00
TXB2CTRL 50 - ABTF MLOA TXERR TXREQ - TXP1 TXP0 -000 0-00
RXB0CTRL 60 - RXM1 RXM0 - RXRTR BUKT BUKT FILHIT0 -00- 0000
RXB1CTRL 70 - RXM1 RXM0 - RXRTR FILHIT2 FILHIT1 FILHIT0 -00- 0000

Примечание: в столбце POR/RST даны значения при включении питания / сбросе.

[Интерфейс SPI]

MCP2515 разработан для прямого подключения к порту Serial Peripheral Interface [3] (SPI), который имеется практически во всех моделях микроконтроллеров, и поддерживает режимы Mode 0,0 и Mode 1,1. Команды и данные отправляются в MCP2515 через вывод SI (в терминологии SPI это сигнал MOSI), с тактированием данных по положительному перепаду сигнала SCK. Данные выводятся последовательно из MCP2515 через вывод SO (в терминологии SPI это вывод MISO) по спаду сигнала SCK. Вывод выборки /CS должен удерживаться в состоянии лог. 0 во время выполнения любой операции по шине SPI. Таблица 12-1 показывает байты инструкции для всех операций. Диаграммы входных и выходных сигналов см. на рис. 12-10 и рис. 12-11 для обоих режимов Mode 0,0 и Mode 1,1.

Примечание: MCP2515 ожидает, чтобы первый байт после активации /CS (появление лог. 0) первым пришедшим байтом будет байт инструкции/команды. При этом подразумевается, что /CS должен перейти в лог. 1 и снова перейти в лог. 0 для передачи другой команды.

Таблица 12-1. Набор инструкций (команд) SPI MCP2515.

Инструкция Формат Описание
RESET 1100 0000 Сбрасывает внутренние регистры в значения по умолчанию и устанавливает режим конфигурации.
READ 0000 0011 Читает данные регистров начиная с выбранного адреса.
READ RX BUFFER 1001 0nm0 При чтении буфера приема снижает нагрузку на SPI по сравнению с обычной командой READ, поскольку адрес задается прямо в команде в одном из 4 мест, указываемых через n и m. При этом связанный флаг приема (CANINTF.RXnIF) очистится автоматически после перехода /CS в лог. 1.
WRITE 0000 0010 Записывает данные в регистры начиная с выбранного адреса.
LOAD TX BUFFER 0100 0abc При заполнении буферов передачи снижает нагрузку на SPI по сравнению с обычной командой WRITE, поскольку адрес буфера задается сразу в команде, в одно из 6 мест, что определяется битами a, b, c.
RTS 1000 0def Инструктирует контроллер начать последовательность передачи любых буферов. Установленный бит d задает передавать TXB2, установленный бит e задает передавать TXB1, установленный бит f задает передавать TXB0.
READ STATUS 1010 0000 Команда для быстрого опроса, которая читает несколько бит статуса для операций передачи и приема.
RX STATUS 1011 0000 Команда быстрого опроса, которая показывает совпадение фильтра и тип (standard, extended и/или remote) принятого сообщения.
BIT MODIFY 0000 0101 Позволяет пользователю установить или очистить отдельные биты в указанном регистре. Примечание: не все регистры позволяют побитную модификацию с этой командой. Выполнение этой команды с регистрами, которые не поддерживают побитную модификацию, принудительно применит маску манипуляции битами FFh. Для получения списка регистров, поддерживающих побитную модификацию, см. раздел "Карта регистров".

Инструкция сброса RESET может использоваться для повторной инициализации внутренних регистров MCP2515 и установки режима конфигурации (Configuration mode). Эта команда предоставляет для интерфейса SPI тот же функционал, что и вывод сброса /RESET.

Инструкция RESET является однобайтной, которая требует выборки устройства переводом /CS в лог. 0, отправки байта инструкции и затем перевода /CS в лог. 1. Настоятельно рекомендуется послать команду Reset (или выдать импульс лог. 0 на вывод RESET) как часть инициализации устройства при включении питания.

Инструкция READ начинается переводом вывода /CS в лог. 0. Затем посылается инструкция READ, за которой следует 8-битный адрес (A7..A0). Далее данные, сохраненные в регистре, выдвигаются из MCP2515 через вывод SO.

Внутренний указатель адреса (Address Pointer) автоматически инкрементируется с каждым следующим выдвигаемым байтом. Таким образом, можно прочитать следующий, соседний по адресу регистр, если продолжать выдавать импульсы SCK. Таким методом можно прочитать любое количество следующих друг за другом по адресу регистров. Операция чтения прерывается переводом вывода /CS в лог. 1 (см. рис. 12-2).

MCP2515 READ instruction fig12 2

Рис. 12-2. Инструкция чтения (READ).

Инструкция READ RX BUFFER (рис. 12-3) предоставляет способ быстрой адресации для чтения буфера приема. Эта инструкция уменьшает затраты ресурсов, связанные с шиной SPI, до одного байта, содержащего в себе и команду, и адрес. Для байта команды имеется 4 возможных значения, определяющих установку указателя адреса. Как только байт команды отправлен, контроллер выдвигает наружу байты по заданному адресу регистра точно так же, как это было бы с инструкцией READ после получения байта адреса (т. е. также доступен последовательный доступ к регистрам). Инструкция READ RX BUFFER дополнительно снижает нагрузку на SPI автоматической очисткой связанного флага приема (CANINTF.RXnIF), когда /CS по окончании команды переходит в лог. 1.

MCP2515 READ RX BUFFER instruction fig12 3

Рис. 12-3. Инструкция чтения буфера приема (READ RX BUFFER).

Инструкция записи начинается переводом вывода /CS в лог. 0. Затем посылается команда WRITE, за которой идет адрес и как минимум 1 байт записываемых данных.

Можно записывать следующие друг за другом по адресу регистры, если продолжать выдвигать байты данных, пока /CS удерживается в лог. 0. Данные будут реально записываться в регистр по фронту нарастания SCK для бита D0. Если сигнал /CS перешел в лог. 1 до того, как загружены все 8 бит, операция записи будет прервана для этого байта данных, и ранее переданные байты окажутся при этом записанными. Подробную информацию о диаграммах сигналов последовательности записи см. на рис. 12-4.

MCP2515 BYTE WRITE instruction fig12 4

Рис. 12-4. Инструкция записи байта (WRITE).

Инструкция LOAD TX BUFFER (рис. 12-5) устраняет необходимость передачи 8-битного адреса, требуемого при обычной команде Write. Эта 8-битная инструкция быстро устанавливает указатель адреса в одно из 6 возможных значений, что позволяет загрузить адрес ID или данных для любого из 3 буферов передачи.

MCP2515 LOAD TX BUFFER fig12 5

Рис. 12-5. Инструкция загрузки буфера передачи (LOAD TX BUFFER).

Команда RTS может использоваться для инициирования передачи сообщения для одного или большего количества буферов передачи. Сначала, как обычно, вывод /CS переводится в лог. 0. Потом отправляется байт команды RTS. Как показано на рис. 12-6, последние 3 бита этой команды показывают, какой буфер (или буферы) передачи разрешены к отправке.

Эта команда установит бит TxBnCTRL.TXREQ для соответствующего буфера (буферов). Одной командой можно установить любые из этих трех бит. Если команда RTS отправляется с nnn=000, то она будет проигнорирована.

MCP2515 REQUEST TO SEND instruction fig12 6

Рис. 12-6. Инструкция запроса на передачу (REQUEST-TO-SEND, RTS).

Команда READ STATUS позволяет одной инструкцией быстро получить доступ к часто используемым битам состояния для приема и передачи сообщения. MCP2515 выбирается переводом вывода /CS в лог. 0, затем посылается байт команды Read Status, как это показано на рис. 12-8. Как только был отправлен байт команды, MCP2515 вернет 8 бит данных, которые содержат состояние контроллера.

Если после первого переданного байта будут посылаться дополнительные такты SCK, то MCP2515 продолжит выводить биты статуса, пока /CS удерживается в лог. 0 и поступают такты SCK.

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

MCP2515 READ STATUS instruction fig12 8

Рис. 12-8. Инструкция чтения состояния контроллера (READ STATUS).

Команда RX STATUS (рис. 12-9) используется для быстрого определения, какой фильтр пропустил сообщение, и сообщение какого типа было принято (standard, extended, remote). После отправки байта команды контроллер возвратит 8 бит данных, содержащие статус. Если будет выдано большее количество тактов после передачи 8 бит, то контроллер продолжит выводить те же биты статуса, пока /CS остается в лог. 0 и предоставляются такты SCK.

MCP2515 RX STATUS instruction fig12 9

Рис. 12-9. Инструкция чтения состояния приема (RX STATUS).

Команда BIT MODIFY предоставляет возможность установки или очистки отдельных бит в выбранном регистре статуса и управления. Эта команда доступна не для всех регистров, см. раздел "Карта регистров", чтобы определить, какие регистры можно использовать для этой команды.

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

MCP2515 BIT MODIFY instruction fig12 7

Рис. 12-7: Инструкция модификации бита (BIT MODIFY).

Как обычно, устройство выбирается переводом /CS в лог. 0, и затем посылается команда Bit Modify. За этой командой идет адрес регистра, байт маски, и последним идет байт данных.

Байт маски определяет, какие биты регистра будет разрешено изменить. Единица в маске позволит изменить соответствующий бит, а ноль не позволит.

Байт данных определяет, какое значение будет записано в разрешенные для модификации биты. Единица в байте данных установит бит, и ноль сбросит бит - для тех бит, у которых маской было разрешено изменение (в соответствующем разряде маски стоит 1). Пример, как это работает, см. на рис. 12-1).

MCP2515 BitModify fig12 1

Рис. 12-1. Работа команды Bit Modify.

MCP2515 SPI input timing fig12 10

Рис. 12-10. Диаграмма сигналов на входе интерфейса SPI.

MCP2515 SPI output timing fig12 11

Рис. 12-11. Диаграмма сигналов на выходе интерфейса SPI.

Примечание: подробную информацию о корпусах, маркировке и ревизиях кристаллов микросхемы MCP2515 см. в даташите [1].

Здесь MCP2515 подключен через SPI1, и обмен осуществляется простым методом, по опросу (без использования прерываний и DMA). Обмен осуществляется стандартными пакетами CAN (без расширенных идентификаторов). На прием используются два буфера RXB0 и RXB1 (в режиме пролонгации содержимого RXB0 путем перемещения данных в RXB1). На передачу используется только один буфер TXB0, буферы передачи TXB1 и TXB2 не используются (так сделано для того, чтобы строго упорядочивать передачу пакетов).

MCP2515 sch example

[mcp2515.h]

#ifndef __MCP2515__
#define __MCP2515__
 
#include "common/AT91SAM7X256.h"
#include "common/projtypes.h"
 
//------------------------Команды CAN контролера MCP2510
#define MCP_RESET          0xC0     // перезапуск
#define MCP_READ           0x03     // чтение
#define MCP_WRITE          0x02     // запись
#define MCP_RTS            0x80     // запрос на отправку
#define MCP_LOAD_TX_BUFFER 0x40     // Передать буфер TXB0, TXB1 или TXB2
#define MCP_READ_RX_BUFFER 0x92     // Прочитать буфер RXB0 или RXB1
#define MCP_READ_STATUS    0xA0     // Прочитать статус
#define MCP_BIT_MODIFY     0x05     // изменить бит
//------------------------Маски бит регистра CANINTF
#define MCP_CANINTF_TX0IF_MASK (1 << 2)
//------------------------Маски результата команды READ STAUS
#define MCP_READ_STAT_RX0IF_MASK (1 << 0)
#define MCP_READ_STAT_RX1IF_MASK (1 << 1)
//------------------------Маски для команды READ RX BUFFER
#define MCP_READ_RXB0 (0 << 2)
#define MCP_READ_RXB1 (1 << 2)
//------------------------Маски для регистра RXB0CTRL
#define MCP_RXB0CTRL_RXM_STANDARD_ID (1 << 5)
#define MCP_RXB0CTRL_BUKT            (1 << 2)
//------------------------Маска для команды LOAD TX BUFFER
#define MCP_LOAD_TXB0 (1 << 0)
 
//-----------------------Регистры CAN контролера MCP2510
#define MCP_CNF1      0x2A
#define MCP_CNF2      0x29
#define MCP_CNF3      0x28
#define MCP_CANCTRL   0x6F          // регистр управления (xF)
#define MCP_CANSTAT   0x0E          // регистр статуса (xE)
#define MCP_CANINTF   0x2C          // регистр флагов прерываний
#define MCP_EFLG      0x2D          // флаги ошибок
#define MCP_REC       0x1D
//-----------------------Прием RXB0
#define MCP_RXB0CTRL  0x60
#define MCP_RXB0SIDH  0x61          // Стандартный ID
#define MCP_RXB0SIDL  0x62          // Стандартный ID
#define MCP_RXM0SIDH  0x20          // Стандартная маска (старший байт)
#define MCP_RXM0SIDL  0x21          // Стандартная маска (младший байт)
#define MCP_RXF0SIDH  0x00          // Стандартный фильтр 0 (старший байт)
#define MCP_RXF0SIDL  0x01          // Стандартный фильтр 0 (младший байт)
#define MCP_RXF1SIDH  0x04          // Стандартный фильтр 1 (старший байт)
#define MCP_RXF1SIDL  0x05          // Стандартный фильтр 1 (младший байт)
#define MCP_RXB0DLC   0x65          // длина посылки
//-----------------------Прием RXB1
#define MCP_RXB1CTRL  0x70
#define MCP_RXB1SIDH  0x71          // Стандартный ID
#define MCP_RXB1SIDL  0x72          // Стандартный ID
#define MCP_RXM1SIDH  0x24          // Стандартная маска (старший байт)
#define MCP_RXM1SIDL  0x25          // Стандартная маска (младший байт)
#define MCP_RXF2SIDH  0x08          // Стандартный фильтр (старший байт)
#define MCP_RXF2SIDL  0x09          // Стандартный фильтр (младший байт)
#define MCP_RXF3SIDH  0x10          // Стандартный фильтр (старший байт)
#define MCP_RXF3SIDL  0x11          // Стандартный фильтр (младший байт)
#define MCP_RXF4SIDH  0x14          // Стандартный фильтр (старший байт)
#define MCP_RXF4SIDL  0x15          // Стандартный фильтр (младший байт)
#define MCP_RXF5SIDH  0x18          // Стандартный фильтр (старший байт)
#define MCP_RXF5SIDL  0x19          // Стандартный фильтр (младший байт)
#define MCP_RXB1DLC   0x75          // длина посылки
//-----------------------Передача TXB0
#define MCP_TXB0CTRL  0x30
#define MCP_TXB0SIDH  0x31          // ID
#define MCP_TXB0SIDL  0x32          // ID
#define MCP_TXB0DLC   0x35          // длина посылки
#define MCP_TEC       0x1C

#define MCP_port AT91C_BASE_PIOA
#define MCP_RESET_pin  (1 << 21)
#define MCP_CS_pin     (1 << 25)

#define MCP_PCS   1
#define MCP_NPCS  (((~(1 << MCP_PCS))&0x0F) << 16)

#define EXT_CAN_TX_BUFF_SIZE 512
#define EXT_CAN_TX_BUFF_MASK (EXT_CAN_TX_BUFF_SIZE-1)

#define MCP_SELECT() {MCP_port->PIO_CODR = MCP_CS_pin;}
#define MCP_DESELECT()  {MCP_port->PIO_SODR = MCP_CS_pin;}

void mcp_read_block (void *buf, u8 adress, u8 len); u8 mcp_receive_message (TCandata *rmsg, u8 bufmask);
void mcp_send_message (TCandata *tmsg, u8 bufmask); u8 mcp_read_reg (u8 adress);
void mcp_modify_reg_bit (u8 address, u8 bitmask, bool bitval);
void mcp_write_reg (u8 address, u8 data); u8 mcp_read_status (void);
bool mcp_init (u32 mask, u32 filtr, u8 speed);

#endif //__MCP2515__

[mcp2515.c]

#include "common/lib_AT91SAM7X256.h"
#include "mcp2515.h"
#include "pins.h"
#include "vars.h"
 
u8 mcp_read_reg (u8 address)
{
   // чтение регистра 
   MCP_SELECT();
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_READ;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|address;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|0x00;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   MCP_DESELECT();
   return AT91C_BASE_SPI1->SPI_RDR;
}
 
void mcp_modify_reg_bit (u8 address, u8 bitmask, bool bitval)
{
   // модификация бита регистра
   MCP_SELECT();
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_BIT_MODIFY;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|address;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|bitmask;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|(bitval?0xFF:0x00);
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   MCP_DESELECT();
}
 
void mcp_write_reg (u8 adress, u8 data)
{
   // запись в регистр 
   MCP_SELECT();
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_WRITE;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|adress;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|data;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   MCP_DESELECT();
}
 
u8 mcp_read_status (void)
{ 
   // чтение регистра статуса
   MCP_SELECT();
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_READ_STATUS;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|0x00;
   while(!(AT91C_BASE_SPI1 -> SPI_SR & AT91C_SPI_TXEMPTY));
   MCP_DESELECT();
   return AT91C_BASE_SPI1->SPI_RDR;
}
 
void mcp_COM (u8 cmd)
{ 
   // передача команды
   MCP_SELECT();
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|cmd;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   MCP_DESELECT();
}
 
u8 mcp_receive_message (TCandata *rmsg, u8 bufmask)
{
   u8 DLC;
    
   DLC = mcp_read_reg(MCP_RXB0DLC);
   MCP_SELECT();
   //Выдача инструкции READ RX BUFFER для буфера RXB0:
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_READ_RX_BUFFER|bufmask;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   for (u8 bytecnt=0; bytecnt < 8; bytecnt++)
   {
      AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|0;
      while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
      if (bytecnt < DLC)
         (*rmsg).d8[bytecnt] = AT91C_BASE_SPI1->SPI_RDR;
      else
         (*rmsg).d8[bytecnt] = 0;
   }
   MCP_DESELECT();
   mcp_write_reg(MCP_CANINTF, 0x00);
   return DLC;
}
 
void mcp_send_message (TCandata *tmsg, u8 bufmask)
{
   //Очистка бита опустошения буфера:
   mcp_modify_reg_bit(MCP_CANINTF, MCP_CANINTF_TX0IF_MASK, false);
   MCP_SELECT();
   //Выдача команды LOAD TX BUFFER для буфера TXB0:
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_LOAD_TX_BUFFER|bufmask;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   for (u8 bytecnt=0; bytecnt < 8; bytecnt++)
   {
      AT91C_BASE_SPI1->SPI_TDR=MCP_NPCS|tmsg->d8[bytecnt];
      while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   }
   MCP_DESELECT();
   //Выдача запроса на передачу TXB0:
   mcp_COM(MCP_RTS+1);
}
 
void mcp_read_block (void *buf, u8 adress, u8 len)
{
   MCP_SELECT();
   //Выдача инструкции READ:
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|MCP_READ;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   //Выдача адреса:
   AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|adress;
   while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
   //Чтение регистров друг за другом:
   for (int cnt=0; cnt < len; cnt++)
   {
      AT91C_BASE_SPI1->SPI_TDR = MCP_NPCS|0x00;
      while(!(AT91C_BASE_SPI1->SPI_SR & AT91C_SPI_TXEMPTY));
      ((u8*)buf)[cnt] = AT91C_BASE_SPI1->SPI_RDR;
   }
   MCP_DESELECT();
}
 
static void Init_SPI1 (void)
{
   AT91C_BASE_SPI1->SPI_CR = AT91C_SPI_SPIDIS;        // Запрет SPI1
   AT91F_PIO_CfgPeriph(AT91C_BASE_PIOA,               // Базовый адрес PIO для SPI1
                       0,                             // Peripheral A
                       ((unsigned int) AT91C_PA23_SPI1_MOSI) |
                       ((unsigned int) AT91C_PA29_SPI1_NPCS3)|
                       ((unsigned int) AT91C_PA24_SPI1_MISO) |
                       ((unsigned int) AT91C_PA22_SPI1_SPCK));
    
   // Конфигурирование PMC: разрешить тактирование SPI
   AT91F_SPI1_CfgPMC();
   AT91C_BASE_SPI1->SPI_CR  = AT91C_SPI_SWRST;        // Программный сброс
   AT91C_BASE_SPI1->SPI_CR  = AT91C_SPI_SPIEN;        // SPI1 разрешен
   AT91C_BASE_SPI1->SPI_CSR[MCP_PCS] = (AT91C_SPI_CPOL+AT91C_SPI_BITS_8 + (10 << 8));
   //Настройка режима SPI, и в том числе и скорости (5).
   //Скорость (частота) SPI = 47396571/5 = 9.48 МГц. Больше 10 МГц
   // делать нельзя (согласно даташиту на MCP2515).
   AT91C_BASE_SPI1->SPI_CSR[0]  = (AT91C_SPI_CPOL+AT91C_SPI_BITS_8 + (5 << 8));
   AT91C_BASE_SPI1->SPI_CSR[1]  = (AT91C_SPI_CPOL+AT91C_SPI_BITS_8 + (5 << 8));
   AT91C_BASE_SPI1->SPI_CSR[2]  = (AT91C_SPI_CPOL+AT91C_SPI_BITS_8 + (5 << 8));
   AT91C_BASE_SPI1->SPI_CSR[3]  = (AT91C_SPI_CPOL+AT91C_SPI_BITS_8 + (5 << 8));
   AT91F_SPI_CfgMode(AT91C_BASE_SPI1,AT91C_SPI_MSTR+AT91C_SPI_PS_VARIABLE);
}
 
bool mcp_init (u32 mask, u32 filtr, u8 speed)
{ 
   // инициализация CAN и задание маски и фильтра адреса и скорости
   int i;
   AT91F_PIO_CfgOutput (MCP_port, MCP_RESET_pin);
   AT91F_PIO_SetOutput (MCP_port, MCP_RESET_pin);
   
   AT91F_PIO_CfgOutput (MCP_port, MCP_CS_pin);
   AT91F_PIO_SetOutput (MCP_port, MCP_CS_pin);
   Init_SPI1();  // инициализация SPI
    
   /*
   // аппаратный сброс контроллера CAN не используется
   AT91F_PIO_ClearOutput (MCP_port, MCP_RESET_pin) ;
   for (i=1; i < 2500; i++); //задержка
   AT91F_PIO_SetOutput (MCP_port, MCP_RESET_pin) ;
   */
   //for (i=1; i < 2500; i++); //задержка
   mcp_COM(MCP_RESET);        //команда перезапуска MCP2515
   //for (i=1; i < 2500; i++); //задержка
   bool configmode = false;
   for (i=50; i; i--)
   {
      configmode = (0x80==mcp_read_reg(MCP_CANSTAT));
      if (configmode)
         break;
   }
   if (!configmode)
      return false;
   // SJW[1:0]=00b прыжок подстройки длительности бита нулевой
   // BTLMODE=1b длина PS2 опредляется битами PHSEG22:PHSEG20 регистра CNF3
   // SAM=0b вход приемника опрашивается 1 раз в точке выборки
   // SOF=0 на вывод CLKOUT выводятся тактовые импульсы (они не нужны)
   // WAKFIL=0 фильтр пробуждения запрещен
   //Настройки скорости 125К:
   mcp_write_reg(MCP_CNF1,0x07);   //SJW[1:0]=00b, BRP[5:0]=00111b
   mcp_write_reg(MCP_CNF2,0x90);   //BTLMODE=1b, SAM=0b, PHSEG1[2:0]=010b, PRSEG[2:0]=000b
   mcp_write_reg(MCP_CNF3,0x02);   //SOF=0, WAKFIL=0, PHSEG2[2:0]=010b
   /*
   //Настройки скорости 25К:
   mcp_write_reg(MCP_CNF1,0x0F);
   //SJW[1:0]=00b, BRP[5:0]=01111b
   mcp_write_reg(MCP_CNF2,0xBA);
   //BTLMODE=1b, SAM=0b, PHSEG1[2:0]=111b, PRSEG[2:0]=010b
   mcp_write_reg(MCP_CNF3,0x07);
   //SOF=0, WAKFIL=0, PHSEG2[2:0]=111b
   */
   
   //---------Установка маски и фильтра буфера RXB0:
   mcp_write_reg(MCP_RXF0SIDH, filtr >> 3);
   mcp_write_reg(MCP_RXF0SIDL, filtr << 5);
   mcp_write_reg(MCP_RXF1SIDH, 0);
   mcp_write_reg(MCP_RXF1SIDL, 0);
   mcp_write_reg(MCP_RXM0SIDH, mask >> 3);
   mcp_write_reg(MCP_RXM0SIDL, mask << 5);
   //---------Установка маски и фильтра буфера RXB1:
   mcp_write_reg(MCP_RXF2SIDH, filtr >> 3);
   mcp_write_reg(MCP_RXF2SIDL, filtr << 5);
   mcp_write_reg(MCP_RXF3SIDH, 0);
   mcp_write_reg(MCP_RXF3SIDL, 0);
   mcp_write_reg(MCP_RXF4SIDH, 0);
   mcp_write_reg(MCP_RXF4SIDL, 0);
   mcp_write_reg(MCP_RXF5SIDH, 0);
   mcp_write_reg(MCP_RXF5SIDL, 0);
   mcp_write_reg(MCP_RXM1SIDH, mask >> 3);
   mcp_write_reg(MCP_RXM1SIDL, mask << 5);
   //---------Установка ID и DLC буфера TXB0:
   mcp_write_reg(MCP_TXB0SIDH, (CAN_UP_OUT_ID_START+Device_number) >> 3);
   mcp_write_reg(MCP_TXB0SIDL, (CAN_UP_OUT_ID_START+Device_number) << 5);
   mcp_write_reg(MCP_TXB0DLC, 8);
   //---------Проверочное чтение регистров
   //mcp_read_block(&A00_03, 0x00, sizeof(TA00_03));
   //mcp_read_block(&A20_23, 0x20, sizeof(TA20_23));
   //---------Подключение маски и фильтра для SID
   // Здесь включается прием только стандартных идентификаторов, и включается
   // режим пролонгации буфера RXB0:
   mcp_write_reg(MCP_RXB0CTRL, MCP_RXB0CTRL_RXM_STANDARD_ID|MCP_RXB0CTRL_BUKT);
   //----------------перевод в normal
   mcp_write_reg(MCP_CANCTRL, 0x00);
   return true;
}

[Ссылки]

1. MCP2515 Stand-Alone CAN Controller with SPI Interface site:microchip.com.
2. MCP2515 - CAN контроллер site:pro-diod.ru.
3. Интерфейс SPI.

 

Добавить комментарий


Защитный код
Обновить

Top of Page