[galjoen 0]

Желательно cделать режим прослушивания

+1

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

[sobr 0]

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

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

[Mos 0]

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

 

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

[-=Sergei=- 0]

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

Все остальное противоречит основым постулатам CAN.

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

 

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

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

 

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

 

- есть разрешение принимать собственные пакеты

- есть разрешение подтверждать ACK на собственные пакеты

- есть режим только слушать линию

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

 

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

[Mos 0]

...имеет ли смысл закладывать скорост работы более 1 Мбит/с...

 

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

 

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

 

В принципе с частотой процессора до 80 МГц, можно сделать до 10 Мбит/с...

 

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

 

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

 

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

 

...и без приемопередатчиков...

 

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

 

...сделать надежное соединение точка-точка...

 

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

Применять хабы в кэне - признак дурного тона :)

[syoma 1]

А вот помомему, то что спрашивал автор топика: http://www.freescale.com/files/microcontro...2XDFAMILYPP.pdf

Там есть XGATE модуль - тот-же DMA, который сопрягается также и с CAN модулем.

Похоже на то что вас интересует?

[-=Sergei=- 0]

А вот помомему, то что спрашивал автор топика: http://www.freescale.com/files/microcontro...2XDFAMILYPP.pdf

Там есть XGATE модуль - тот-же DMA, который сопрягается также и с CAN модулем.

Похоже на то что вас интересует?

 

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

 

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

 

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