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

[syoma]

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

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

Кстати

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

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

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

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