| MCP2515: контроллер шины CAN с интерфейсом SPI |
|
| Добавил(а) microsin | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Основные возможности контроллера: • Реализует стандарт CAN V2.0B на скорости 1 мегабит/сек: [Типы корпусов]
Примечание *: под донышком корпуса 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, маски, фильтры, буферы передачи и приема.
Рис. 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, второй его конец соединен с VDD) на 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) и внешних физических задержек по шине. Что такое рецессивный и доминантный биты. Рецессивный и доминантный в протоколе 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.
Рис. 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.
Рис. 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) отправит фрейм данных.
Рис. 2-3. Фрейм remote шины CAN. Есть 2 различия между фреймом remote (показан на рис. 2-3) и фреймом данных. Во-первых, бит RTR находится в рецессивном состоянии, и во-вторых, здесь нет поля данных. При этом событии фрейм данных и фрейм remote с тем же идентификатором будет отправлены одновременно, так что фрейм данных выиграет арбитраж, поскольку за идентификатором идет доминантный бит RTR. При таком методе обмена узел, который отправил фрейм remote, немедленно получит требуемые данные. [Поддержка обработки ошибок протокола CAN] Error Frame. Фрейм ошибки генерируется любым узлом шины CAN, который детектирует ошибку на шине. Фрейм ошибки (error frame), показанный на рис. 2-4, состоит из 2 полей: флаг ошибки, за которым следует поле разделителя ошибки. Здесь имеется 2 типа полей флага ошибки. Тип отправляемого поля флага ошибки зависит от статуса ошибки того узла, который генерирует поле флага ошибки. Ниже описаны типы полей флага ошибки.
Рис. 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, имеет тот же формат, что и фрейм активной ошибки. Однако фрейм перегрузки может быть сгенерирован только в промежутке между фреймами. Таким образом, фрейм перегрузки можно отличить от фрейма ошибки (фрейм ошибки передается во время передачи сообщения).
Рис. 2-5. Overload Frame CAN. Фрейм перегрузки состоит из 2 полей: флаг перегрузки, за которым идет разделитель перегрузки. Флаг перегрузки состоит из 6 доминантных бит, за которыми идут флаги перегрузки, генерируемые другими узлами (и, как и для флага активной ошибки, дают максимум 12 доминантных бит). Разделитель перезагрузки состоит из 8 рецессивных бит. Фрейм перегрузки может быть сгенерирован узлом в 2 случаях: 1. Узел детектировал доминантный бит во время промежуточного пространства между фреймами, что не допустимо. Исключение из этого правила: доминантный бит был детектирован во время третьего бита IFS. В этом случае приемники интерпретируют это как SOF (начало фрейма). Примечание: случай 2 никогда не должен произойти с MCP2515 из-за очень малых внутренних задержек. Промежуточное пространство (Interframe Space). Этот интервал времени отделяет друг от друга предыдущий фрейм (любого типа) от последующего фрейма данных или фрейма remote. Промежуточное пространство состоит из как минимум 3 рецессивных бит, которые называются интервалом перерыва (Intermission). Это дает узлам время на внутреннюю обработку перед началом следующего фрейма сообщения. После intermission шина остается в рецессивном состоянии (bus idle), пока не начнется следующая передача. [Передача сообщения] Буферы передачи. В устройстве 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 Если передача инициируется через интерфейс 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. Примечание: если разрешен режим 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. Алгоритм отправки сообщения. [Описание регистров передачи] Ниже во врезках приведено описание регистров и каждого из их отдельных бит. Под каждым битом приведена его легенда, состоящая из комбинации символов:
7 не реализован, читается как 0. 6, ABTF: бит флага обрыва сообщения (Message Aborted Flag). 1 сообщение было оборвано. 5, MLOA: сообщение проиграло арбитраж (Message Lost Arbitration). 1 сообщение при попытке отправки проиграло арбитраж. 4, TXERR: была детектирована ошибка передачи (Transmission Error Detected). 1 произошла ошибка шины при передачи сообщения. 3, TXREQ: бит запроса на передачу сообщения (Message Transmit Request). 1 буфер в настоящий момент ожидает передачи. Управляющий микроконтроллер устанавливает этот бит, чтобы выставить запрос на передачу сообщения. Этот бит автоматически очистится, когда сообщение будет отправлено. 2 не реализован, читается как 0. 1-0, TXP[1:0]: биты приоритета буфера передачи (Transmit Buffer Priority). 11 самый высокий приоритет сообщения.
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. 2, B2RTSM: бит режима вывода /TX2RTS. 1, B1RTSM: бит режима вывода /TX1RTS. 0, B0RTSM: бит режима вывода /TX0RTS. 1 вывод BnRTSM (n=0..2) используется для запроса на передачу буфера TXB0 (по спаду уровня).
7-0, SID[10:3]: биты стандартного идентификатора сообщения.
7-5, SID[2:0]: биты стандартного идентификатора сообщения. 4 не реализован, читается как 0. 3, EXIDE: бит разрешения расширенной адресации (Extended Identifier Enable). 1 сообщение будет отправлено с расширенным идентификатором. 2 не реализован, читается как 0. 1-0, EID[17:16]: биты расширенного идентификатора сообщения.
7-0, EID[15:8]: биты расширенного идентификатора сообщения.
7-0, EID[7:0]: биты расширенного идентификатора сообщения.
7 не реализован, читается как 0. 6, RTR: бит запроса передачи с дальнего окончания (Remote Transmission Request). 1 переданное сообщение содержит фрейм remote. 5-4 не реализованные биты, читаются как 0. 3-0, DLC[3:0]: биты длины сообщения (Data Length Code). Устанавливает количество байт данных, передаваемых в сообщении (от 0 до 8 байт). Примечание: есть возможность установить поле DLC значением, которое больше 8, но все равно будет передано только 8 байт полезной нагрузки сообщения.
7-0, TXBnDm7:TXBnDm0: байт данных m буфера передачи n (Transmit Buffer n Data Field Bytes) [Прием сообщения] 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. Запрещено. Состояние "запрещено" будет работать, когда очищен бит 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. Блок-диаграмма алгоритма приема.
7 не реализован, читается как 0. 6-5, RXM[1:0]: биты режима работы буфера приема. 11 маски/фильтры отключены; будет принято любое сообщение. 4 не реализован, читается как 0. 3, RXRTR: Received Remote Transfer Request. 1 принят запрос на передачу от другого пира сети (Remote Transfer Request). 2, BUKT: бит разрешения пролонгации буфера RXB0 (Rollover Enable). 1 при поступлении нового сообщения для буфера RXB0 старое, не обработанное сообщения в том же буфере будет перемещено в буфер RXB1, независимо от других условий (независимо от того, заполнен ли буфер RXB1, и независимо от состояния его фильтров). 1, BUKT1: копия бита BUKT, доступная только для чтения (используется внутри MCP2515). 0, FILHIT0: бит срабатывания фильтра (Filter Hit bit) - показывает, какой фильтр допустимости разрешил прием сообщения. 1 Acceptance Filter 1 (RXF1) Примечание: если произошла пролонгация с перемещением данных из RXB0 в RXB1, то бит FILHIT будет отражать фильтр, который разрешил прием нового сообщения.
7 не реализован, читается как 0. 6-5, RXM[1:0]: биты управления режимами работы буфера приема (Receive Buffer Operating mode). 11 маски/фильтры отключены; будет принято любое сообщение. 4 не реализован, читается как 0. 3, RXRTR: принят запрос передачи от другого пира сети (Received Remote Transfer Request). 1 принят запрос на передачу от другого пира сети (Remote Transfer Request). 2-0, FILHIT[2:0]: биты срабатывания фильтра (Filter Hit bits) - показывают, какой фильтр допустимости разрешил прием сообщения. 101 = Acceptance Filter 5 (RXF5)
7-6 не реализованы, читаются как 0. 5, B1BFS: бит состояния вывода /RX1BF (только для режима цифрового выхода). Читается как 0, когда /RX1BF сконфигурирован как выход сигнала прерывания. 4, B0BFS: бит состояния вывода /RX0BF (только для режима цифрового выхода). Читается как 0, когда /RX0BF сконфигурирован как выход сигнала прерывания. 3, B1BFE: бит разрешения функции вывода /RX1BF. 1 функционирование вывода разрешено, его рабочий режим определяется битом B1BFM. 2, B0BFE: бит разрешения функции вывода /RX0BF. 1 функционирование вывода разрешено, его рабочий режим определяется битом B0BFM. 1, B1BFM: бит рабочего режима вывода /RX1BF. 1 вывод используется как выход сигнала прерывания, когда допустимое сообщение загружен в буфер RXB1. 0, B0BFM: бит рабочего режима вывода /RX0BF. 1 вывод используется как выход сигнала прерывания, когда допустимое сообщение загружен в буфер RXB0.
7-0, SID[10:3]: биты стандартного идентификатора. В этих битах содержатся 8 старших бит стандартного идентификатора принятого сообщения.
7-5, SID[2:0]: биты стандартного идентификатора. В этих битах содержатся 3 младших бита стандартного идентификатора принятого сообщения. 4, SRR: бит запроса стандартного фрейма remote (Standard Frame Remote Transmit Request), допустим только если бит IDE = 0. 1 принят Standard Frame Remote Transmit Request. 3, IDE: бит флага расширенного идентификатора (Extended Identifier Flag). Этот бит показывает, какой фрейм был принят: стандартный или расширенный. 1 был принят расширенный фрейм (Extended Frame). 2 не реализован, читается как 0. 1-0, EID[17:16]: биты расширенного идентификатора (Extended Identifier). Эти биты содержат 2 самых старших бита расширенного идентификатора принятого сообщения.
7-0, EID[15:8]: Биты расширенного идентификатора (Extended Identifier). Здесь хранятся биты 15..8 расширенного идентификатора принятого сообщения.
7-0, EID[7:0]: Биты расширенного идентификатора (Extended Identifier). Здесь хранятся младшие 8 бит расширенного идентификатора принятого сообщения.
7 не реализован, читается как 0. 6, RTR: бит запроса передачи расширенного фрейма (Extended Frame Remote Transmission Request), допустим только когда RXBnSIDL.IDE=1. 1 был принят Extended Frame Remote Transmit Request. 5, RB1: зарезервированный бит 1. 4, RB0: зарезервированный бит 0. 3-0, DLC[3:0]: биты кода длины данных (Data Length Code). Показывает количество байт данных в принятом сообщении.
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 показано, как маски и фильтры прикладываются для расширенных и стандартных фреймов данных.
Рис. 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) Если бит 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. Принцип работы маски и фильтров, определяющих допустимость принимаемого сообщения.
7-0, SID[10:3]: биты фильтра стандартного идентификатора (Standard Identifier Filter). Здесь хранятся биты фильтра, накладываемые на биты [10:3] порции стандартного идентификатора принятого сообщения.
7-5, SID[2:0]: биты фильтра стандартного идентификатора (Standard Identifier Filter). Здесь хранятся биты фильтра, накладываемые на биты [2:0] порции стандартного идентификатора принятого сообщения. 4 не реализован, читается как 0. 3, EXIDE: бит разрешения расширенного идентификатора (Extended Identifier Enable). 1 фильтр прикладывается только к расширенным фреймам. 2 не реализован, читается как 0. 1-0, EID[17:16]: биты фильтра расширенного идентификатора (Extended Identifier Filter). Здесь хранятся бит фильтра, накладываемые на биты [17:16] порции расширенного идентификатора принятого сообщения.
7-0, EID[15:8]: биты расширенного идентификатора (Extended Identifier). В этих битах хранятся биты, прикладываемые к битам [15:8] порции расширенного идентификатора принятого сообщения, или к байту 0 в принятых данных, если соответствующие RXM=00 и EXIDE=0.
7-0, EID[7:0]: биты расширенного идентификатора (Extended Identifier). В этих битах хранятся биты, прикладываемые к битам [7:0] порции расширенного идентификатора принятого сообщения, или к байту 1 в принятых данных, если соответствующие RXM=00 и EXIDE=0.
7-0, SID[10:3]: биты маски стандартного идентификатора (Standard Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [10:3] порции стандартного идентификатора принятого сообщения.
7-5, SID[2:0]: биты маски стандартного идентификатора (Standard Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [2:0] порции стандартного идентификатора принятого сообщения. 4-2 не реализованы, читаются как 0. 1-0, EID[17:16]: биты маски расширенного идентификатора (Extended Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [17:16] порции расширенного идентификатора принятого сообщения.
7-0, EID[15:8]: биты маски расширенного идентификатора (Extended Identifier Mask). В этих битах хранятся биты маски, которые прикладываются к битам [15:8] порции расширенного идентификатора принятого сообщения. Если соответствующие биты RXM=00 и EXIDE=0, то эти биты прикладываются к байту 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 как количество бит в секунду, передаваемых идеальным передатчиком без ресинхронизации. Это описывается выражением:
Номинальное время бита. Номинальное время бита (Nominal Bit Time, NBT) tbit строится из не перекрывающихся сегментов (рис. 5-1). Таким образом, NBT это сумма следующих сегментов времени: tbit = tSyncSeg + tPropSeg + tPS1 + tPS2
Рис. 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:
Здесь BRP соответствует конфигурации, как это показано в описании регистра CNF1.
Рис. 5-2. TQ и период бита. [Синхронизация] Чтобы компенсировать сдвиги фазы между частотами генераторов каждого из узлов на шине, каждый контроллер CAN должен иметь возможность синхронизироваться с соответствующий перепадом приходящего сигнала. Синхронизация это процесс, реализованный функцией DPLL. Когда детектирован перепад в передаваемых данных, логика будет сравнивать место положения перепада с ожидаемым временем (SyncSeg). Затем схема будет при необходимости подстраивать интервалы времени PS1 и PS2. Для синхронизации используются 2 механизма: 1. Жесткая синхронизация. Жесткая синхронизация. Такой механизм синхронизации выполняется только когда происходит перепад recessive-to-dominant во время ожидания шины (BUS IDLE, т. е. на шине нет сигналов), что означает начало сообщения. После жесткой синхронизации счетчики времени бита перезапускаются с SyncSeg. Жесткая синхронизация приводит к тому, что перепад происходит внутри сегмента синхронизации перезагруженного времени бита. По правилам синхронизации, если произошла жесткая синхронизация, то во времени интервала бита не будет происходить пересинхронизация. Пересинхронизация (ресинхронизация). В результате этого механизма синхронизации интервал PS1 может быть удлинен, или PS2 может быть укорочен. Величина укорачивания или удлинения сегментов фазы буфера ограничена верхним пределом, задаваемым шириной шага синхронизации (Synchronization Jump Width, SJW). Величина SJW будет добавлена к PS1 или вычтена из PS2 (см. рис. 5-3). SJW представляет циклическую фильтрацию DPLL. Интервал SJW программируется в диапазоне 1..4 TQ.
Рис. 5-3. Синхронизация времени бита. Ошибки фазы. Метод кодирования NRZ не подразумевает вставки в передаваемое сообщение тактовой частоты бит. Информация от тактировании выделяется по перепадам recessive-to-dominant на шине. Свойство протокола, которое устанавливает фиксированный максимум количества следующих друг за другом одинаковых бит (bitstuffing, бит-стаффинг, т. е. вставка противоположных по уровню бит) гарантирует, что в течение фрейма поток бит будет содержать перепады, необходимые для ресинхронизации. Ошибка фазы на перепаде определяется позицией перепада относительно SyncSeg, и эта ошибка измеряется в интервалах TQ. Ошибка фазы, измеряемая в единицах TQ, определяется следующим образом: • e = 0, если перепад попадает в интервал сегмента синхронизации (SYNCSEG). e = 0, нет ошибки фазы. Когда e=0, то ошибка фазы отсутствует. Если магнитуда ошибки фазы меньше или равна запрограммированному значению SJW, то эффект от ресинхронизации тот же самый, что и от жесткой синхронизации. e > 0, положительная ошибка фазы. Если величина ошибки больше SJW, если ошибка фазы положительна, то PS1 увеличивается на величину, равную SJW. e < 0, отрицательная ошибка фазы. Если величина ошибки фазы больше, чем ширина шага ресинхронизации, и ошибка фазы отрицательна, то PS2 укорачивается на величину, равную SJW. Правила ресинхронизации: 1. Для синхронизации используются только лишь перепады уровня recessive-to-dominant. Программирование сегментов времени. Для программирования сегментов времени нужно соблюдать следующие требования: • PropSeg + PS1 >= PS2 Например, если предположить, что скорость 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, SJW[1:0]: ширина шага синхронизации (Synchronization Jump Width Length). 11 ширина = 4 TQ 5-0, BRP[5:0]: биты управления прескалером скорости (Baud Rate Prescaler). TQ = 2*(BRP+1)/FOSC.
7, BTLMODE: бит управления длиной PS2 (PS2 Bit Time Length). 1 длина PS2 определяется битами PHSEG22:PHSEG20 регистра CNF3. 6, SAM: бит конфигурации точки выборки (Sample Point Configuration). 1 вход приемника опрашивается 3 раза возле точки выборки. 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, SOF: бит сигнала начала фрейма (Start-of-Frame signal bit). Если CANCTRL.CLKEN = 0, бит SOF не оказывает никакого влияния. Если CANCTRL.CLKEN = 1, то: 1 вывод CLKOUT разрешен для сигнала SOF. 6, WAKFIL: бит фильтра пробуждения (Wake-up Filter). 1 фильтр пробуждения разрешен. 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 (состояние активной ошибки). Состояние 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.
7-0, TEC[7:0]: биты счетчика ошибок передачи (Transmit Error Count).
7-0, REC[7:0]: биты счетчика ошибок приема (Receive Error Count).
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 (код прерывания), что показано во врезке с описанием регистра 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. Прерывания ожидают обработки, пока установлен один из флагов. Как только один из флагов прерывания установлен устройством, этот флаг не может быть сброшен управляющим микроконтроллером, пока не будет снято условие возникновения прерывания.
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, 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.
Рис. 8-1. Работа генератора от кварцевого или керамического резонатора. Примечания: (1) Последовательно включенный резистор (RS) может потребоваться для кварцев с типом среза AT (AT strip-cut). MCP2515 может также управляться от внешнего источника тактов, подключенного к выводу OSC1, как это показано на рис. 8-2 и рис. 8-3.
Рис. 8-2. Работа от внешнего источника тактов. Примечания: (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) Хотя повышенная емкость увеличивает стабильность генератора, это также увеличивает и время запуска генератора. Вывод CLKOUT становится активным при сбросе системы и по умолчанию остается в состоянии выдачи самой низкой частоты (делением на 8), так что это можно использовать для тактирования управляющего микроконтроллера. Когда выставлен запрос на режим сна (Sleep mode), MCP2515 выдаст дополнительные 16 тактов на выводе CLKOUT перед входом в режим сна. В состоянии ожидания (Idle) вывода CLKOUT (когда контроллер находится в режиме сна) на его выходе присутствует лог. 0. Когда функция CLKOUT запрещена (CANCNTRL.CLKEN=0), вывод CLKOUT находится в состоянии высокого сопротивления (его выходной драйвер отключен). Функция CLKOUT разработана так, чтобы гарантировать, что времена thCLKOUT и tlCLKOUT сохраняются, когда работа CLKOUT разрешена, запрещена или изменяется значение прескалера. [Сброс] MCP2515 различает два способа сброса: 1. Hardware Reset (аппаратный сброс) - низким уровнем на выводе /RESET. Функционал обоих видов сброса эквивалентен. Важно осуществить один из этих способов сброса после включения питания, чтобы гарантировать переход логики и регистров в свое состояние по умолчанию. Аппаратный сброс можно осуществить автоматически, путем подключения RC-цепочки к выводу /RESET pin (см. рис. 9-1). Значения элементов цепочки должны быть такие, чтобы импульс лог. 0 был длительностью как минимум 2 мкс после того, как VDD достигнет своего рабочего напряжения, как это определено электрическими параметрами (tRL).
Рис. 9-1: Пример схемы организации сброса с помощью ввода /RESET. Примечания: (1) Диод D помогает быстро разрядить конденсатор, когда падает уровень напряжения VDD (выключение питания). [Режимы работы] У MCP2515 есть 5 режимов работы: 1. Configuration mode Рабочий режим выбирается через биты регистр CANCTRL.REQOP (см. во врезке описание регистра CANCTRL). Когда меняются режимы, то режим в действительности не поменяется, пока не завершатся все ожидающие передачи. Запрошенный режим может быть проверен чтением битов CANSTAT.OPMODE (см. во врезке описание регистра CANSTAT). Configuration Mode. Перед активизацией MCP2515 должен быть инициализирован. Это возможно только в режиме конфигурации MCP2515. Режим конфигурации автоматически выбирается при включении питания, сбросе, или в него можно войти из любого другого режима путем установки бит CANTRL.REQOP в значение 100. Когда осуществлен вход в режим конфигурации, все счетчики ошибок очищаются. Только в режиме конфигурации можно изменить следующие регистры: • CNF1, CNF2, CNF3 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-5, REQOP[2:0]: биты запроса смены режима работы (Request Operation mode). 000 установка Normal mode Все другие значения бит REQOP недопустимы, и не должны использоваться. После включения питания REQOP = 111. 4, ABAT: бит отмены всех ожидающих передач (Abort All Pending Transmissions. 1 запрос на отмену всех ожидающих передачи буферов. 3, OSM: бит однократного режима передачи (One-Shot mode). 1 разрешено. Для передачи сообщения будет предпринята только одна попытка, независимо от наличия ошибок. 2, CLKEN: бит разрешения вывода тактов CLKOUT (CLKOUT Pin Enable). 1 вывод CLKOUT разрешен. 1-0, CLKPRE[1:0]: биты управления прескалером CLKOUT (CLKOUT Pin Prescaler). 00 FCLKOUT = System Clock/1
7-5, OPMOD[2:0]: биты индикации текущего рабочего режима (Operation mode). 000 устройство находится в Normal mode 4 не реализован, читается как 0. 3-1, ICOD[2:0]: биты флагов кода прерывания (Interrupt Flag Code). 000 нет ожидающего обработки прерывания 0 не реализован, читается как 0. [Карта регистров] Адресация регистров 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.
Инструкция сброса 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).
Рис. 12-2. Инструкция чтения (READ). Инструкция READ RX BUFFER (рис. 12-3) предоставляет способ быстрой адресации для чтения буфера приема. Эта инструкция уменьшает затраты ресурсов, связанные с шиной SPI, до одного байта, содержащего в себе и команду, и адрес. Для байта команды имеется 4 возможных значения, определяющих установку указателя адреса. Как только байт команды отправлен, контроллер выдвигает наружу байты по заданному адресу регистра точно так же, как это было бы с инструкцией READ после получения байта адреса (т. е. также доступен последовательный доступ к регистрам). Инструкция READ RX BUFFER дополнительно снижает нагрузку на SPI автоматической очисткой связанного флага приема (CANINTF.RXnIF), когда /CS по окончании команды переходит в лог. 1.
Рис. 12-3. Инструкция чтения буфера приема (READ RX BUFFER). Инструкция записи начинается переводом вывода /CS в лог. 0. Затем посылается команда WRITE, за которой идет адрес и как минимум 1 байт записываемых данных. Можно записывать следующие друг за другом по адресу регистры, если продолжать выдвигать байты данных, пока /CS удерживается в лог. 0. Данные будут реально записываться в регистр по фронту нарастания SCK для бита D0. Если сигнал /CS перешел в лог. 1 до того, как загружены все 8 бит, операция записи будет прервана для этого байта данных, и ранее переданные байты окажутся при этом записанными. Подробную информацию о диаграммах сигналов последовательности записи см. на рис. 12-4.
Рис. 12-4. Инструкция записи байта (WRITE). Инструкция LOAD TX BUFFER (рис. 12-5) устраняет необходимость передачи 8-битного адреса, требуемого при обычной команде Write. Эта 8-битная инструкция быстро устанавливает указатель адреса в одно из 6 возможных значений, что позволяет загрузить адрес ID или данных для любого из 3 буферов передачи.
Рис. 12-5. Инструкция загрузки буфера передачи (LOAD TX BUFFER). Команда RTS может использоваться для инициирования передачи сообщения для одного или большего количества буферов передачи. Сначала, как обычно, вывод /CS переводится в лог. 0. Потом отправляется байт команды RTS. Как показано на рис. 12-6, последние 3 бита этой команды показывают, какой буфер (или буферы) передачи разрешены к отправке. Эта команда установит бит TxBnCTRL.TXREQ для соответствующего буфера (буферов). Одной командой можно установить любые из этих трех бит. Если команда RTS отправляется с nnn=000, то она будет проигнорирована.
Рис. 12-6. Инструкция запроса на передачу (REQUEST-TO-SEND, RTS). Команда READ STATUS позволяет одной инструкцией быстро получить доступ к часто используемым битам состояния для приема и передачи сообщения. MCP2515 выбирается переводом вывода /CS в лог. 0, затем посылается байт команды Read Status, как это показано на рис. 12-8. Как только был отправлен байт команды, MCP2515 вернет 8 бит данных, которые содержат состояние контроллера. Если после первого переданного байта будут посылаться дополнительные такты SCK, то MCP2515 продолжит выводить биты статуса, пока /CS удерживается в лог. 0 и поступают такты SCK. Каждый бит состояния, возвращенный этой командой, может также быть прочитан стандартной командой чтения Read с указанием соответствующего адреса.
Рис. 12-8. Инструкция чтения состояния контроллера (READ STATUS). Команда RX STATUS (рис. 12-9) используется для быстрого определения, какой фильтр пропустил сообщение, и сообщение какого типа было принято (standard, extended, remote). После отправки байта команды контроллер возвратит 8 бит данных, содержащие статус. Если будет выдано большее количество тактов после передачи 8 бит, то контроллер продолжит выводить те же биты статуса, пока /CS остается в лог. 0 и предоставляются такты SCK.
Рис. 12-9. Инструкция чтения состояния приема (RX STATUS). Команда BIT MODIFY предоставляет возможность установки или очистки отдельных бит в выбранном регистре статуса и управления. Эта команда доступна не для всех регистров, см. раздел "Карта регистров", чтобы определить, какие регистры можно использовать для этой команды. Примечание: выполнение команды Bit Modify на регистрах, которые не предоставляют функционал побитной модификации, будут работать так, как если бы была указана битовая маска FFh. Это позволит перезаписать регистр целиком, а не менять отдельные биты.
Рис. 12-7: Инструкция модификации бита (BIT MODIFY). Как обычно, устройство выбирается переводом /CS в лог. 0, и затем посылается команда Bit Modify. За этой командой идет адрес регистра, байт маски, и последним идет байт данных. Байт маски определяет, какие биты регистра будет разрешено изменить. Единица в маске позволит изменить соответствующий бит, а ноль не позволит. Байт данных определяет, какое значение будет записано в разрешенные для модификации биты. Единица в байте данных установит бит, и ноль сбросит бит - для тех бит, у которых маской было разрешено изменение (в соответствующем разряде маски стоит 1). Пример, как это работает, см. на рис. 12-1).
Рис. 12-1. Работа команды Bit Modify.
Рис. 12-10. Диаграмма сигналов на входе интерфейса SPI.
Рис. 12-11. Диаграмма сигналов на выходе интерфейса SPI. Примечание: подробную информацию о корпусах, маркировке и ревизиях кристаллов микросхемы MCP2515 см. в даташите [1]. Здесь MCP2515 подключен через SPI1, и обмен осуществляется простым методом, по опросу (без использования прерываний и DMA). Данные передаются стандартными пакетами CAN (без расширенных идентификаторов). На прием используются два буфера RXB0 и RXB1 (в режиме пролонгации содержимого RXB0 путем перемещения данных в RXB1). На передачу используется только один буфер TXB0, буферы передачи TXB1 и TXB2 не используются (так сделано для того, чтобы строго упорядочивать передачу пакетов).
[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_MASK (EXT_CAN_TX_BUFF_SIZE-1)
#define MCP_DESELECT() {MCP_port->PIO_SODR = MCP_CS_pin;} [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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
