[volod_ua 0]

Нужна помощь. Кто роботал с CAN. Кто какой протокол использивал...или проще свой залабадь.

[KRS 0]

А для чего вам нужен CAN ?

сколько устройств будет на шине, какая скорость нужна, какие данные будут пердаваться?

 

можно и свой протокол, если будут только ваши устройства сидеть.

 

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

 

На CAN128 CAN отлично рабоатет и довольно удобная реализация!

[volod_ua 0]

А девайсов будет гдето до 128 ...да можеш поделеся как обрабативать ошибки тоисть что немогу понять как определить что msg не пошол или что случилось с шиной...так вроде начал писать свой протокол тоже всьо ок...а вот только с ошибками немогу розобраться кто за что должен отвечать...да тоже использую At90Can128 хорошоя штучка

[KRS 0]

А девайсов будет гдето до 128 ...да можеш поделеся как обрабативать ошибки тоисть что немогу понять как определить что msg не пошол или что случилось с шиной...так вроде начал писать свой протокол тоже всьо ок...а вот только с ошибками немогу розобраться кто за что должен отвечать...да тоже использую At90Can128 хорошоя штучка

 

CAN достаточно надежная шина. поэтому в реализации лучше учитивать то что ошибок практически не будет.

 

Обработка ошибок довольно проста.

1. Надо псати состояние шины в общем (ERROR PASSIVE, BUS OFF), для простоты можно пасти только BUS OFF и например перегружать контроллер в этом случае.

 

2. Ошибки на прием пакета я игнорирую (пусть разбирается контроллер который посылал пакет)

 

3. При отправке (проще использовать только один майл бокс на отправку) надо установить таймаут и елси пакет не отправился (скорее всего не куому принимать) надо тромознуть отправку, когда майлбокс освободится можно узнать произошла отправка или нет.

 

И если нужен полный контроль всех данных то надо надо в протоколе предусмотреть пакет подтверждения получения

[volod_ua 0]

Хорошо а ошибки арбитража тоисть когда два посилают одновремена... кто за етим следит ...само железо...да зачем нужен пакет TX_REMOTE и чем он отличається...

[KRS 0]

Хорошо а ошибки арбитража тоисть когда два посилают одновремена... кто за етим следит ...само железо...да зачем нужен пакет TX_REMOTE и чем он отличається...

 

Да за арбитражем, следит железо.

 

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

 

Ремот фреймы хорошит для пассивной системы, которая по запросу работает и если данные в пакетах не объеденяются. присовил каждой функцее свой ID и нужны данные отапрвляешь REMOTE фрейм с данным ID

 

 

 

Новообще если трафик напряженный, на мой взгляд проще REMOTE фреймы не использовать, а пердавать данные по событию.

[spf 0]

Хорошо а ошибки арбитража тоисть когда два посилают одновремена... кто за етим следит ...само железо...да зачем нужен пакет TX_REMOTE и чем он отличається...

Матчасть нужно знать ;-)

Желательно спецификацию почитать, хотябы для общего представления о том что применяете.

 

http://www.can-cia.de

Кое-что на русском есть на http://www.gaw.ru

[volod_ua 0]

А извините за наглость но может у кавота найдеться специвикация протокола типа DeviceNet,CanOpen или других протоколов ...

[TMX 0]

Можно посмотреть метапротокол CAN Kingdom.

спецификация