Перейти к содержанию
    

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

А что мешает самому таймаут сделать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А что мешает самому таймаут сделать?

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

Не предусмотрено в апи linux Socket CAN. Изделие и драйвер должны работать в соответствии со стандартными апи.

Не предусмотрено в протоколе верхнего уровня Canopen, прикладной софт есть, обкатан и изменениям не подлежит.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Кстати

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

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

Реально Вы пробовали промоделировать такую ситуацию?

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

AN_InitStructure.CAN_ABOM = DISABLE;

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 насколько я помню в стандарте есть требования на количество ошибок в шине - и если perr больше чегото там (не помню но по моему порядка 10e-6) то такая шина считается неработоспособной и на нее не расчитывают

2 ничто не мешает (как вам написали выше работать по TXERR и RXERR) просто тупо их брасывая не забутьте только отменить передачу перед сбросом

3 ну а уж про таймауты это ваще дело что назывется ваше и вашей системы

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...