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

• Реализует стандарт 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.

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

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 [3].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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) и внешних физических задержек по шине.

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

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

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

5 байт используются для хранения стандартного и расширенного идентификаторов, а также другой информации арбитража (см. регистры TXBnSIDL, TXBnEID8, TXBnEID0, TXBnDLC). Последние 8 байт предназначены для данных полезной нагрузки передаваемого сообщения (см. регистр TXBnDm).

Для передачи должны быть загружены как минимум регистры 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 (см. регистр TXBnSIDH). Регистр 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 будет установлен.

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

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

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

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

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

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

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

Из этих трех буферов приема MAB всегда осуществляет прием следующего сообщения с шины CAN. MAB осуществляет сборку всех принимаемых сообщений. Собранные сообщения будут переданы в буферы RXBn (см. регистры RXBnSIDH, RXBnSIDL, RXBnEID8, RXBnEID0, RXBnDLC, RXBnDm) только тогда, когда сообщения будут удовлетворять критерию допустимости (определяется фильтрами).

Каждый из двух буферов приема 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 и фильтрацию помех, применяемую при детектировании начала фрейма.

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

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

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

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

Состояние "запрещено" будет работать, когда очищен бит BFPCTRL.BnBFE, при этом вывод /RXnBF будет находиться в состоянии высокого сопротивления. Вывод /RXnBF может быть сконфигурирован либо для сигнализации заполнения соответствующего буфера, либо для работы как стандартный цифровой выход. Конфигурация и состояние этих выводов доступно через регистр BFPCTRL. Когда сконфигурирован режим генерации сигнала прерывания (установкой битов 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.

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

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

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

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

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

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

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

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

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

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

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

Примечание: 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 находится в любом режиме, кроме режима конфигурации.

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

[Интервалы времени шины 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 как количество бит в секунду, передаваемых идеальным передатчиком без ресинхронизации. Это описывается выражением:

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

t_bit = t_SyncSeg + t_PropSeg + t_PS1 + t_PS2

Рис. 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. Таким образом:

PS2_min = 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:

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

Рис. 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.

Без ресинхронизации (e = 0)

Ресинхронизация по медленному передатчику (e > 0)

Ресинхронизация по быстрому передатчику (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] не оказывают никакого влияния.

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

Протокол 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 и счетчик ошибок передачи Transmit Error Counter, регистр TEC. Значения этих обоих счетчиков может прочитать управляющий микроконтроллер. Эти счетчики инкрементируются / декрементируются в соответствии со спецификацией шины 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 бит. Если это нежелательно, то такая ситуация должна быть адресована обработчику прерывания.

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

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

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

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

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

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

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

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

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

Примечание: /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. Прерывания ожидают обработки, пока установлен один из флагов. Как только один из флагов прерывания установлен устройством, этот флаг не может быть сброшен управляющим микроконтроллером, пока не будет снято условие возникновения прерывания.

[Генератор]

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

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

Примечания:

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

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

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

Примечания:

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

Рис. 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.

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

Для точной настройки на стандартные частоты CAN хорошо подходят кварцы с частотами 4, 8, 12, 16 МГц. Для расчета значений регистров CNF1, CNF2, CNF3 под выбранный кварц можно использовать онлайн-калькулятор [5]. Там нет именно чипа MCP2515, однако есть MCP2510, настройки которого совместимы с MCP2515.

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

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

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

Примечания:

(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).

Рис. 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 (см. во врезке описание регистра CANCTRL). Когда меняются режимы, то режим в действительности не поменяется, пока не завершатся все ожидающие передачи. Запрошенный режим может быть проверен чтением битов CANSTAT.OPMODE (см. во врезке описание регистра CANSTAT).

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.

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

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

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

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

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

Примечание: в столбце 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.

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

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

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

#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__

#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.
4. CAN Bit Time Calculation.
5. CAN Bus Bit Timing Calculator.