Что-то по errata список багов довольно внушительный.
Вообще с ним работать можно реально?
Ну фильтры там не работаеют, wake up и т.п., конечно хреново, но просто можно не пользовать и анализировать все программно, но вот последний баг что-то меня совсем удручил
"Messages might not be received correctly if during a CAN Transmission the CAN bus arbitration is lost to another CAN node."
Вообще, нужен неразлапистый ARM с CAN, не более QFP64. У Atmel нету, у филипса х.з., можно ли пользовать, у кого есть?

Подниму тему еще раз.
Реально кто-либо запускал проект с CAN на LPC?
Все ли баги, описанные в errata реально обходятся?

в RTX есть драйвера в исходниках з- я думаю все должно работать
собираюсь попробовать эту штуку - примерно через месяц

Мы сделали уже три модуля. Реализовали на нем почти CANopen. Работает. Фильтры действительно не используем. Программист Эрраты как-то обошел. Так-что не бойтесь.

Я использовал LPC2129, работал он норамально
но особого трафика по CAN не было, и кстати errata был намного меньше, посмотрел свежий действительно впечатляет.
Скорее всего баг с arbitration lost проявляется очень редко.
Все остальные легко обходятся.

Кстати фильтры прекрасно работают! И в ерр ата указан баг только для FULL CAN режима и то легко обходится.

Есть еще у ST арм с CAN STR712 например. (тоже 64 ноги)
http://mcu.st.com/mcu/modules.php?name=mcu...TR712FR2&FAM=86

Фильтры можено реализовать программно, это не проблема, меня волнует вот этот баг:
"Messages might not be received correctly if during a CAN Transmission the CAN bus arbitration is lost to another CAN node."
Может кто объяснит подробно, что это есть и с чем его едят?
Work-around прочитал, но хотелось бы услышать мнение, если кто уже обходил этот баг.



Да, такой у меня есть. У него правда есть несколько мелких неудобств, типа нет встроенного осцииллятора, нужно только внешний генератор вешать.
Но сейчас меня интересует наоборот толстый uC и с 3 CAN молулями и EMI, смотрю LPC2294.
Может еще кто присоветует ARM с тремя CAN?

Вот это самый страшный баг! Если вдруг одновременно начнет пердавать филипс и кто то еще - возникнет arbitration lost, но один их пакетов который имеет наименьший приоритет проходит (dominant bit у него раньше), так вот филипс его выкидывает (похоже).
Рекоминдация по обходу конечно идиотская! они рекомендуют делать Self Reception Request (т.е заодно и все свои пакеты принимать) и к тому же свои пакеты еще и фильтр не должен выкидывать!



Есть TMS с 3 CAN
http://focus.ti.com/docs/prod/folders/prin...s470r1b768.html

и STR73x тоже с 3 CAN

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


На эти у меня чего то не стоит. Какие-то мутные.


А эти слишком новые, вроде только где-то только в анонсах встречал. Или реально уже есть в продаже?

Примерно так, судя по описанию в ERRATA
честно говоря когда я начинал с LPC2129 этого errata не было и я не знал про этот баг и в общем с этой проблемой не столкнулся.


Да это хорошее замечание! Они наверное поэтому и не пользуются у нас особой популярностью.
Но вот на семинаре по MSP430 про них немного зашла речь... говорят у них ядро вылизано и глюков нет.


Похоже что нет
а ведь у них и питание 5 V! что иногда довольно интересно.

Кстати у моторолы (точнее Freescale) есть серия MAC7xxx - АРМ7 с кучей вкусностей, включая CAN... Питание 3.3 или 5 вольт.

Сейчас в стадии прогона находится система, в которую входят и устройства на LPC2129. Также на линии висят узлы на MB90F497 и SJA1000 - всё прекрасно работает.
Раньше использовали SJA1000, поэтому переползать на LPCx было несложно. CAN функционирует, фильтры работают. Вы наверное имели в виду баг с неработоспособностью фильтров в FullCAN mode и рекомендацией реализовывать это программно - но без FullCAN можно жить, в остальном соответствует документации.
PS - гонял линию с большой загрузкой - больше 60% от теоритической полной пропускной способности на разных скоростях, и при просмотре статистики узлов видно, что имеет место быть потеря пакетов. Процент очень маленький, порядка сотых долей %, но бывает. Правда, у нас такие ситуации отрабатываются вышележащим протоколом с повторной передачей.

Сообщение отредактировал Pugachyov - Jun 6 2006, 16:00

По моему вы както не правильно понимаете этот пункт Errata.
Т.е. LPC-CAN не принимает пакет от другого узла выйгравший arbitration если он (LPC-CAN) в то-же время пытался передать пакет. При этом retransmit своего пакета вяко будет. Всё это если передача без Self Reception Request

Баг конечно неприятный, но work-around вполне приемлимый.
Все пакеты передаёте с Self Reception Request.
Если у вас ID передаваемых и принимаемых пакетов не пересекаются то Acceptance Filter устраняет всё что надо. В противном случае - ДА, надо програмно отсеивать, но с третьей стороны програмно оно как правило и так отсеивается (парсится).

В общем у меня 2292 вполне работает. Раньше и 3 передатчика работали вместе, пока в errata о них не появилось бага.

Вот руки дошли поднимать CAN на 2294.
Более вдумчиво перечитал errata, и вроде сейчас она не внушает какого-то большого ужаса. Но не понятен баг CAN.5

CAN.5 Handling Reset Mode and Abort Transmission
Introduction: In Reset Mode, the CAN operations are disabled and writable registers can be written. If an Abort Transmission command is issued then a pending transmission request is cancelled if not already in progress.

Problem: Normal operation cannot be resumed after reset or abort transmission without using one of the workarounds below.

Может кто-то прокомментировать, в чем этот баг выражается? И кто как понимает условия его возникновения?
Предложенные способы решения мне как-то не очень нравятся и имеют определенные недостатки.

То есть правильно ли я понимаю, что вышеозначенная проблема проявляется именно при остановке передачи фрейма CAN, и не будет проявляться при установке RESET mode, если или Abort Transmission, если в текущий момент кадров на передачу в буфере нет?