Размышления на тему блокировки CAN bus Опции

[_3m]

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

Рассмотрим случай 1: ретрансмисии + bus-off
Есть узлы 1 и 2, они обмениваются пакетами в обе стороны, т.е
1<---->2. Других узлов нет.
Теперь внешним воздействием (придурки!) во время работы кабель разрывается, причем так что шина на стороне 1 оказывается оборвана и на стороне 2 закорочена, т.е так:
1----X |----2.
На узле 1 возникает No ack error, которая приведит к ретрансмиссии.
Узел 2 преходит в Bus-off.
В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.
Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность.
Теперь 1 флудит ретрансмиссиями а 2 пытается выполнить процедуру bus-off recovery для которой требуется 128*11 рецессивных бит. Очевидно что 2 никогда не выйдет из bus-off а 1 никогда не получит ack. Глухой завис. А теперь представим что узел 1 физически или организационно недоступен. Все, можно стреляться.

Случай 2: проблема приоритетов
При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю.
Использовать режим обработки передающих мэйлбоксов с учетом приоритета id в общем случае невозможно потому что протокол высокого уровня ожидает поступление пакетов в определенном порядке и драйвер физики менять этот порядок не имеет права.

[galjoen]

В реализациях передатчиков я ни разу не видел таймаут на передачу

Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать.
А что мешает самому таймаут сделать?

[_3m]

Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать.
А что мешает самому таймаут сделать?

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

[MALLOY2]

Случай 2: проблема приоритетов

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

[galjoen]

Меняется только кан контроллер и драйвер.

Вот пусть драйвер и проинициализирует контроллер в режим TTCAN, и никаких автоматических повторов уже не будет.

[syoma]

В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.

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

Кстати

Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность.

Как вы предлагаете восстановать кабель, предварительно не убрав КЗ с узла 2? За 128*11 бит это надо слишком быстрым быть. То есть при восстановлении кабеля узел 2 должен уже восстановиться и все пройдет пучком.
Реально Вы пробовали промоделировать такую ситуацию?

Случай 2: проблема приоритетов
При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю.

Эта проблема старая. Чтобы этого не было CAN реально нельзя загружать на больше, чем 30-50% пропускной способности. Это писали еще на заре CANостроения.

[vptr]

...На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.

По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается.

[syoma]

По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается.

Я это тоже сначала хотел предложить, но по даташиту пробежался и не нашел там такого. Зато прерываний - по любому чиху есть.

[vptr]

Я это тоже сначала хотел предложить, но по даташиту пробежался и не нашел там такого. Зато прерываний - по любому чиху есть.

Давно это было... Режим настраивается

Код

AN_InitStructure.CAN_ABOM = DISABLE;

Для STM32F407 при DISABLE передача останавливалась.

[net]

1 насколько я помню в стандарте есть требования на количество ошибок в шине - и если perr больше чегото там (не помню но по моему порядка 10e-6) то такая шина считается неработоспособной и на нее не расчитывают
2 ничто не мешает (как вам написали выше работать по TXERR и RXERR) просто тупо их брасывая не забутьте только отменить передачу перед сбросом
3 ну а уж про таймауты это ваще дело что назывется ваше и вашей системы