А кто нибуть встречал МК с CAN, и DMA Опции

[-=Sergei=-]

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

[ValeraK]

Ктонибуть встречал МК с CAN и DMA.

В сторону 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

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

[-=Sergei=-]

Еще вопросы.

Сколько приоритетов сделать на отсылку сообщений?
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, или ктонить видел интересные особенности в других реализациях ?

[Mos]

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

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

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

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

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

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

[sobr]

Кроме того, если контроллер спит, то никто не гарантирует, что первое сообщение, принятое во время сна, будет принято корректно...

Более того, первое сообщение разбудет контроллер, но сообщение будет ОБЯЗАТЕЛЬНО потеряно.