Должны быть такие средства, надо штудировать доку по реализации CAN в этом МК.
Но не обязательно после вывода из BUS_OFF будут продолжены попытки передачи, ее надо инициировать.

Господа!
Кто-нибудь может разместить на форуме программы на Си,
реализующие обмен по CAN-интерфейсу?
Особенно интересуют варианты
для 16-разрядных МП фирм ST и Infineon.
Хочется посмотреть как эту задачу решают другие программисты.

Для 16-ти битников у меня нет, но могу дать драйвера для 51 (с внешним SJA1000 и внутренним CC03).
Но там и так все просто - положил в буфер, запустил передачу. Либо - разрешил прием, ждеш готовности, считываешь сообщение из буфера - проще не куда.

На все подобное добро тут места не хватит...
В инете просто море подобных вещей, устанешь перебирать.
Приведу одну сслку:
http://www.vscp.org/

И для С166 думаю можно найти...

А сколько в этом проекте CAN-конроллеров подключено в сеть ?

А что, это может иметь значение?
У нас цифровая коммутационная станция с внутристанционной сигнализацией по CAN (т.е. внутри одного каркаса) - модулей десяток-полтора, скорость мегабит.
Плюс система мониторинга - тут уже метров несколько десятков отвод (для перехода в PC - преобразователь CAN-USB).
Плюс еще по электровозу (другая разработка) - там тоже пара десятков устройств на шине.
Да еще всякое.

Это имеет значение, т. к. если в сети достаточно большое число контроллеров, то придётся сделать усложнённую программу(надо будет менять ID, продумать их распределение и т. д.).

- "Одношлейфовая" сеть на драйверах типа TJA1050 ограничивается их нагрузочной способностью - около 100 узлов, теоретическое ограничение - разрядность ID.
- Распределение ID зависит от его разрядности, 11/29 бит.
- У контроллера может быть несколько ID (для разных типов сообщений).
- В ID можно "вставлять данные" для увеличения количества данных в сообщении или уменьшения времени передачи - только ID, часть бит в котором выделены под данные.
- "Менять ID" приемных слотов не стоит, чревато потерей данных, их надо настраивать при старте контроллера или системы.

Так что думать надо в любом случае...

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

Поделитесь, пожалуйста, каким отладчиком в Keil пользуютесь. Тоже занимаюсь отладкой сети на AT89C51CC03 в Keil c помощью ISD51. Виснет через каждые 2 минуты, прерывания CAN вообще перестают с ним работать, приходится через опрос флага!

Использую Keil Monitor-166 Driver(Monitor Configuration - Monitor in ROM).
Отлаживаю программу для CAN-контроллера встроенного в МК C167 Infineon.

Остаётся только завидовать . Flashmon так и не удалось настроить, останов не работал совсем. Может у кого получилось использовать Flashmon для СС03?

Не пойму чему завидовать...
ИМХО: Подглядывалка в виде монитора не панацея при отладке, тем более в реальном времени т.к. ни чем не лучше обычного симулятора. В реальном времени даже аппаратные отладочные средства зачастую бессильны.

Сформируйте "свою" и "читаемую" информацию, направьте в свободный последовательный интерфейс и читайте простым терминалом, толку будет больше.

К сожалению, текстовыми сообщениями не обойтись. А вот без отладчика CC03 сложно было бы использовать вообще. Документация на него ужасная, лучше самому изучить изменение регистров на реальном железе в реальной программе.

Обойтись можно двумя кнопками и двумя лампочками
Зачем же вы взяли такой дорогой МК да еще и без документации?!

Изучать поведение регистров надо в специальной программе, если уж на то пошло. Изучили, записали и вперед.
А в реальной программе все нюансы можно выгребать долго, т.к. тонкости могут встречаться в нескольких местах, накладываться друг на друга, да и сама "реальная программа" может быть создана с принципиальными ошибками т.к. разрабатывалась по ошибочной документации.