Ктонибуть встречал МК с CAN и DMA.
Так что бы именно CAN передавал/принимал пакеты в/из ОЗУ напрямую через ДМА.
Или уважаемые Донны считают CAN с DMA излишеством ?

Как это поможет работе в CAN сети?

Удобно, когда в контроллере CAN имеется много слотов (чем больше, тем лучше, в некоторых МК Fujitsu имеется по 128 слотов) и осуществляется аппаратная фильтрация пакетов по этим слотам. На слот или их группу вешается обработчик, который выполняет необходимые операции.
DMA же пользуют, когда необходимо тупо переложить блок данных из одного места(потока) в другое и только потом его программно "отфильтровать" и приступить к обработке в фоновой программе.
Т.е. DMA необходим CAN контроллеру, у которого один слот на прием (без фильтра) и один на передачу.

Еще в CAN имеются вторичные данные (счетчик ошибок и сбоев в шине), что с ними делать DMA при нештатных ситуациях на шине?

Я посмотрел существующие аналоги с Cortex-M3. У STM всего - 3 слотов на отправку, 6 на прием (если я правильно понял), у Лиминари 32 слота. Физически эта память находится в контроллере CAN, и отображается в область переферии, причем у STM - это регистровая память, т.е. на триггерах построенная, у лиминари - отдельный блок SRAM. И то и другое занимает много места на кристалле. Например у меня в 1886ВЕ5 6 буферов сообщений - это 60% всего контроллера CAN.

Сейчас я хочу сделать МК как минимум с 2 отдельными CAN контроллерами, и в каждом минимум по 16 слотов, даже точноее сказать в 16 программируемых подканалах отправки и приема сообщений. В самом контроллере CAN только 2 буфера - на прием и на отправку.

Отправка.
1. В произвольном месте памяти создаем сообщение (причем это будет строго выравненная по ячейкам Си-шная структура)
2. В подканале N контроллера CAN задем указатель на структуру, приоритет отправки и разрешение отправки.
3. Контроллер CAN как сочтет возможным начать отправку через DMA загружает это сообщение в буфер отправки и отсылает
4. При успешной отправке ядру прерывание от N подканала.

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

Прием.
1. Для полдканалов указываем области куда переписывать сообщения.
2. Получили сообщение
3. В зависимость от фильтра (на каждый подканал свой отдельный фильтр+маска) выбираем какой из подканалов готов принять принять это сообщение
4. Через DMA переписываем в ОЗУ сообщение, при этом DMA может быть зациклен в размере сообшения и тогда следующее сообщение этого подканала перезапишет только что принятое, либо зациклен в некой в более большой области и тогда будет некая FIFO очередь сообщений данного подканала.
5. Как сообщение переписано может быть прерывание или нет.

Пример работы.
Делаем подканал 5 на прием сообщений о температуре. Строгий фильтр только от дачика температуры
DMA циклим на размере одного сообщения, при приеме никаких прерываний, и разрешаем перезаписывать сообщения. Таким образом по зараеннее известному адресу в ОЗУ всегда хранится последнее сообщение о температуре. И ядро совершенно не занимается обработкой такого рода сообщений и если ему нужна температура он лезет уже не к CAN, а к заранее извесному адресу по которому хранится автоматически обнавляемая температура.

Ну типа что то так.
Основная же всех изысков - это уменьшить размер блока CAN более эффективно использовать ОЗУ (правда опять таки конфликты при одновременном доступе ущерб с другой стороны).

сории за русский язык.

Это локомотивы CAN индустрии? ;)
Инфо: МК Fujitsu применяют в Subaru, CAN встраивается в МК Fujitsu уже около 10 лет.


Если имеется полноценный CAN, то в такоком случае он работает совершенно параллельно и не тормозит CPU при операция DMA. В программе достаточно просто сделать обертку или нечто подобное и обращаться напрямую в слот CAN (который будет "обновляться" при приеме следующего пакет), в котором должна лежать все та же текущая температура.

Так что пример не в пользу применения DMA, плюсов не вижу, скорее наоборот, только накладные расходы и усложнения.

сейчас глянул Fuji, судя по описанию в MB96300 стоит ядро CAN один в один с Luminary.

Цель еще раз повторюсь - уменьшить размер блока CAN, убрать оттуда всю память сообщений и использовать для этого ОЗУ. Правда пока еще нет объективных данных во что это у меня выльется в DMA контроллере. Так что вот думаю....

Для сведенья

Xilinx имплементация

часть контроллера CAN реализующая протокол - 252 триггера, 998 Slices
буфер на одно сообщение - 131 триггер, 284 Slices - умножить на 6, 9, 16 или 32
общее управление - 113 триггеров, 155 Slices
промежуточный буфер - 108 триггеров, 96 Slices
фильтер на одно сообщение - 32 триггера, 40 Slices

т.е. при 16 буферах, блок состоит на ~70% из буферов, при 32 буферах - на 85%.
Пойду смотерть сколько займет отдельное ОЗУ такого размера....

Это не единственный вариант CAN контроллера у MB9X.
Свежими (из малышек) так же можно считать MB90F352, MB91F272.

dsPIC33, PIC24H

ОК, с DMA разобрались, будет своя локальная память.
Вопрос второй.

А зачем вообще 32, или даже 128 буферов.
Могу ли я все сообщения складывать в общую длинную FIFO и в теле каждого сообщения указывать какому фильтру оно соответсвовало. Или же есть какой либо тайный смысл в аппаратном расскладывании сообщений по буферам, задавая для каждого буфера маску ?

Встречал и такой и такой варианты, как посоветуете сделать ?

Не совсим понял как в теле сообщения указывать?

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

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

Или же в зависимости от того какая маска совпала я укладываю принятый пакет в ту или иную область (собственно сам буффер) и уже от того в какой области лежит сообщение программа знает какой маске он соответствует.

Как разумней всего сделать ?

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

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

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

В сторону ADI blackfin 537 не смотрели?

• Conforms to the CAN 2.0B (active) standard
• Supports both standard (11-bit) and extended (29-bit) identifiers
• Supports data rates of up to 1Mbit/s
• 32 mailboxes (8 transmit, 8 receive, 16 configurable)
• Dedicated acceptance mask for each mailbox
• Data filtering (first 2 bytes) can be used for acceptance filtering (DeviceNet™ mode)
• Error status and warning registers
• Universal counter module
• Readable receive and transmit pin values

В этом семействе есть микроконтроллеры и с внутренним флэш.

Еще вопросы.

Сколько приоритетов сделать на отсылку сообщений?
1. Т.е. как минимум из буфера с меньшим порядковым номером сообщение уйдет раньше.
2. Стоит ли добавлять еще приоритеты ? и сколько их сделать 0, 1 или 0, 1, 2, 3


Как правильно сделать отправку нескольких сообшений в следующей ситуации.

1. Началась отправка сообщения 1
2. В это время подготовили еще одно сообщение 2 для отправки
3. Приозошла ошибка, или наш передатчик проиград арбитраж и отправка сообщения 1 прекратилась.
4. Разрешилась проблема иои приняли приоритетный пакет
5. Сам вопрос, какое сообщение слать 1 или 2, если например у сообщения 2 больший приоритет ?

Стоит ли делать error managment ?
Т.е. заложить механизмы выдергивания контроллера из BusOff программно, а не путем как описано в спецификации типа куча 11111 получить. Или например запретить переходить в Passiv Error и всегда быть активным ?

Сделать ли просыпание по передаче по CAN, но просыпаться мы будем на любое сообщение, даже если в конечном итоге мы его отбросим. Ядро должно будет снова усыпить CAN контроллер?


Вообщем, каму каких еще фичей не хватает в CAN, или ктонить видел интересные особенности в других реализациях ?

Приоритетность == CAN ID, а уже только потом порядковый номер слота.
Все остальное противоречит основым постулатам CAN.


Опять же Приоритетность == CAN ID


Желательно, но не обязательно.


Не совсем понял, как это просыпание по передаче?
Кто и кого послал?


Желательно cделать режим прослушивания и разнообразные виды loopback (удобно для проверки, отладки и т.п.)

Я так понял, имеется ввиду, передача осуществилась к НАМ (т.е. произошел приём).

Моё мнение, тут м.б. 2 варианта:

1) Усыплять контроллер не нужно. Т.к. этим должна управлять система Power Management, а не КЭН.
Power Management не должна знать о логике работы КЭН-контроллера.

Кроме того, если контроллер спит, то никто не гарантирует, что первое сообщение, принятое во время сна, будет принято корректно (т.к. при усыплении контроллера есть смысл усыпить и трансивер). Обычно (на сколько я понял) когда трансивер спит, передатчик вообще отключён, а приёмник находится в "медленном" режиме и он может распознать факт активности на шине, но не обязательно корректно принять пакет.

2) Если и делать то опционально. Т.е. отключаемо.