Ктонибуть встречал МК с 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) Если и делать то опционально. Т.е. отключаемо.

+1
И чтобы ошибка отсутствия подтверждения ACK в этом режиме корректно устанавливалась. Чтоб в этом режиме можно было узнать реально-то был-ли ACK на шине или нет. В смысле сделать не так, как это сделано у AT90CAN128. Ну и с ошибками битстаффинга также.

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

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

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

По поводу режимов отладки

- есть разрешение принимать собственные пакеты
- есть разрешение подтверждать ACK на собственные пакеты
- есть режим только слушать линию
- есть режим внутрикристальной закоротки RX-TX, работать на себя без внешнего приемо-передатчика.

И еще, имеет ли смысл закладывать скорост работы более 1 Мбит/с. В принципе с частотой процессора до 80 МГц, можно сделать до 10 Мбит/с и без приемопередатчиков сделать надежное соединение точка-точка внутри модуля ?

На практике - врядли. Но если это не сложно сделаь, то было бы очень интересно (чисто с научной точки зрения). Главное, чтобы это небыло в ушчерб возможности точно выставлять скорость в диапазоне от 5 килобит до 250 , а то и до 1 мбит.

Скорость выше 1 мбит может быть задействована только "внутри одного шкафа" - это точно.



Простите, но немогу понять, как?

Ведь 80 Мгц / 20 тактов на бит = 4 мегабита (кстати, тоже отличная скорость для эксперементов).

20 тактов потому, что у Вас на каждый бит - по 10 временных интервалов. На каждом интервале Вам необходимо определять фронт. т.е. как минимум по 2 такта.



В данном случае, проблема высоких скоростей КЭНа заключается не в трансиверах, а в скоросте распространения электрического сигнала в физической среде (для витой пары 0.66С - 0.75С, где С - скорость света).



Для КЭНа это редко бывает актульно. Всётаки идеология шины...
Применять хабы в кэне - признак дурного тона

А вот помомему, то что спрашивал автор топика: http://www.freescale.com/files/microcontro...2XDFAMILYPP.pdf
Там есть XGATE модуль - тот-же DMA, который сопрягается также и с CAN модулем.
Похоже на то что вас интересует?

Спасибо, посмотрел.

Изначально была идея минимизировать объем памяти в нутри контроллера CAN за счет использования системной памяти и DMA. В конце концов после долгих баданий внутри разработчиков, решили от этого отказаться. Т.е. память 32-х буферов будет реализована внутри контроллера CAN. А DMA сможет в нее лазить на общих основаниях, если конечно это будет интересно разработчику.

Сейчас контроллер сделал. Через месяца два начнем подсоедениять к процессору, вот тогда и станет ясно, что да как. А пока я перехожу в USB OTG разработчиков.