[galjoen 0]

Анализируют ли стандартные CAN анализаторы ID и принятые данные, точнее ту часть данных и ту часть ID которые были приняты до установки доминанты (ошибки битстаффинга), в сети другими устройствами? Это чтобы по ID узнать полудохлый блок в сети.

Если таких анализаторов нет, то есть какая то микросхема CAN интерфейса, которая точно позволяет это делать - pdf на неё смотрел, но тогда это мне не нужно было. А сейчас её тип вылетел из головы.

А CAN интерфейс у МК - сильно упрощённый. На мой взгляд, навряд ли у какого из МК с CAN такая возможность есть. Но если есть, то это тоже вариант.

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

[novikovfb 17]

Подниму вопрос. Есть ли мониторы, позволяющие протоколировать битые кадры и кадры, которые никто не принял? Периодически затыкается связь на шине, судя по симпомам - какое-то устройство забивает шину высокоприоритетными кадрами, марафоновский монитор ничего не фиксирует.

[yes 5]

естественно есть - видел у Lecroy-а например. есть всякие специализированные софты и т.д.

но в простых "кэн снифферах", типа марофоновского нет такой возможности - там микроконтроллер стоит, битые фреймы никак не принимаются

 

можно самому написать на ПЛИСине - есть проект opencan на опенкоресах - клон SJA1000, впринципе, можно расковырять

более быстрый и дешевый вариант - купить китайский USB логический анализатор, с него сливать в ПК, а там своим скриптом проанализировать

 

[net 0]

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

так как данные надо выбрать при приходе следующего пакетта

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

и вам это мало поможет

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

и этого когото вы никогда не узнаете при анализе шины

 

и не забутьте еще о возможности 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 5]

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

 

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

 

просто в контроллере обычно FIFO на 2-3 CAN сообщения, и в это FIFO попадает только то, что прошло acceptance filter, то есть было принято полностью.

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

 

 

[syoma 1]

Вроде как у некоторых контроллеров (помомему STM32F10X) даже если нога настроена на CAN прием, можно спокойно читать ее состояние из программы. Поэтому я бы написал простенькую логгер-программу, которая бы постоянно со скоростью хотя бы раз в 5 больше скорости CANа семплировала состояние этой ноги и пихала в буфер. И если CAN-контроллер генерит прерывание по ошибке - в буфере будут лежать последние принятые биты перед ошибкой.

Это в идеале. Сам не проверял.

 

Еще можно по прерыванию ошибки можно дергать какой-нибудь свободной ногой МК и по ней синхронизировать осциллограф, подключенный к CANу. Ну а потом глазками вычислять ID.

[net 0]

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

 

просто в контроллере обычно 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" хотели под интелектуальный генератор помех задействовать - но пока со всем разбирались пришли к выводу что все это шорох орехов

и надо просто правильно делать железо и писать программы

и никаких снифферов не нужно

[геннадий75 1]

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

CAN.rar

[novikovfb 17]

моя проблема решилась совсем другим способом: одно из устройств на шине из-за разгильдяйства разработчика на 2-3 секунды выставляло доминантный уровень (сделали CAN на ПЛИС, пока не запрограммируется - держит "0").

Изменено 7 октября, 2015 пользователем novikovfb

[net 0]

моя проблема решилась совсем другим способом: одно из устройств на шине из-за разгильдяйства разработчика на 2-3 секунды выставляло доминантный уровень (сделали CAN на ПЛИС, пока не запрограммируется - держит "0").

примените драйвера с отключаемым тайм аутом и вообще проблем не будет - а то так и будете виснуть

 

[net 0]

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

в битом кадре данные читаются - если у вас 0 то вы не доделали программу чтения битых кадров

 

[геннадий75 1]

в битом кадре данные читаются - если у вас 0 то вы не доделали программу чтения битых кадров

Программа считывает весь идущий поток данных, и уже его пытается собрать в CAN сообщения. Даже одиночный ноль на шине я увижу, также видно битые сообщения , видно правильно посчитан CRC если неверно программа покажет правильный, видно подтвердили другие блоки сообщение или нет ,сколько единиц между пакетами, также если приходят одинаковые CAN сообщения в правом окне программы не появляются . В правом окне видны только новые CAN сообщения, именно это помогало выдернуть из потока нужное CAN сообщение.