Анализатор ошибок в CAN сети., Анализ ID у битых сообщений. Опции

[galjoen]

Анализируют ли стандартные CAN анализаторы ID и принятые данные, точнее ту часть данных и ту часть ID которые были приняты до установки доминанты (ошибки битстаффинга), в сети другими устройствами? Это чтобы по ID узнать полудохлый блок в сети.
Если таких анализаторов нет, то есть какая то микросхема CAN интерфейса, которая точно позволяет это делать - pdf на неё смотрел, но тогда это мне не нужно было. А сейчас её тип вылетел из головы.
А CAN интерфейс у МК - сильно упрощённый. На мой взгляд, навряд ли у какого из МК с CAN такая возможность есть. Но если есть, то это тоже вариант.
Или уж свой самодельный CAN на базе ATmega48 доработать? Там это легко делается, но с передачей полученной информации проблема.

[net]

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

и не забутьте еще о возможности 1: Listen Only Mode -- the controller gives no acknowledgment on CAN, even if a
message is successfully received. Messages cannot be sent, and the controller
operates in “error passive” mode. This mode is intended for software bit rate
detection and “hot plugging

[yes]

битые кадры принимаются любым контроллером там только два раза придется принимать по прерываниям

а это проверяли или предполагаете?

просто в контроллере обычно FIFO на 2-3 CAN сообщения, и в это FIFO попадает только то, что прошло acceptance filter, то есть было принято полностью.
я специально не смотрел, но впечатление такое, что ничего в этом фифо нету по error-у. да и прерывание по ошибке не на всякий битый фрейм генерируется (это для LPC и STM CAN контроллеров)

[net]

а это проверяли или предполагаете?

просто в контроллере обычно FIFO на 2-3 CAN сообщения, и в это FIFO попадает только то, что прошло acceptance filter, то есть было принято полностью.
я специально не смотрел, но впечатление такое, что ничего в этом фифо нету по error-у. да и прерывание по ошибке не на всякий битый фрейм генерируется (это для LPC и STM CAN контроллеров)

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

все(сниффер) сделано на lpc 2294 двумя каналами смотрит в can шину и одним can на pc где производится разбор полетов

на шину вешается два can потому что 1 can работает в only listen mode - чтобы ничего не портить в работе шины
а 2 can подключается если нужно чтото сгенерить в шину

3 can пересылает все на pc где все протоколируется и смотрится в удобном виде и через него же задается режим генерации нужных пакетов в шину если нужно

битые пакеты прекрасно протоколируются(через два прерывания)


4 "can" хотели под интелектуальный генератор помех задействовать - но пока со всем разбирались пришли к выводу что все это шорох орехов
и надо просто правильно делать железо и писать программы
и никаких снифферов не нужно