_3m 5 12 апреля, 2013 Опубликовано 12 апреля, 2013 · Жалоба Реализую драйвер линукс 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 0 12 апреля, 2013 Опубликовано 12 апреля, 2013 · Жалоба В реализациях передатчиков я ни разу не видел таймаут на передачу Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать. А что мешает самому таймаут сделать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 5 12 апреля, 2013 Опубликовано 12 апреля, 2013 · Жалоба Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать. А что мешает самому таймаут сделать? Мешает то что изделие должно работать в существующем окружении где таймауты не предусмотрены в принципе, ретрансмиссии используются. Не предусмотрено в апи linux Socket CAN. Изделие и драйвер должны работать в соответствии со стандартными апи. Не предусмотрено в протоколе верхнего уровня Canopen, прикладной софт есть, обкатан и изменениям не подлежит. Меняется только кан контроллер и драйвер. Исходя из этого действия драйвера должны быть прозрачными для софта и не затрагивать трафик насколько это возможно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость MALLOY2 12 апреля, 2013 Опубликовано 12 апреля, 2013 · Жалоба Случай 2: проблема приоритетов Так у строена шина, что бы не терять пропускную способность при колизиях, мы полатим тем что есть вероятность того, что сообщения с низким приоритетом никогда не будут переданы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 12 апреля, 2013 Опубликовано 12 апреля, 2013 · Жалоба Меняется только кан контроллер и драйвер. Вот пусть драйвер и проинициализирует контроллер в режим TTCAN, и никаких автоматических повторов уже не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 17 апреля, 2013 Опубликовано 17 апреля, 2013 · Жалоба В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно. Посмотрите стандарт CAN, что касается менеджмента ошибок на шине. Там очень хороший диагностический механизм и драйвер должен его использовать. Можно и прерывание сдлеать и счетчик ошибок опрашивать. В любом случае бесконечная ретрансмиссия отображается счетчиком и на это надо реагировать. Кстати Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность. Как вы предлагаете восстановать кабель, предварительно не убрав КЗ с узла 2? За 128*11 бит это надо слишком быстрым быть. То есть при восстановлении кабеля узел 2 должен уже восстановиться и все пройдет пучком. Реально Вы пробовали промоделировать такую ситуацию? Случай 2: проблема приоритетов При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю. Эта проблема старая. Чтобы этого не было CAN реально нельзя загружать на больше, чем 30-50% пропускной способности. Это писали еще на заре CANостроения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vptr 0 18 апреля, 2013 Опубликовано 18 апреля, 2013 · Жалоба ...На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно. По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 18 апреля, 2013 Опубликовано 18 апреля, 2013 · Жалоба По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается. Я это тоже сначала хотел предложить, но по даташиту пробежался и не нашел там такого. Зато прерываний - по любому чиху есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vptr 0 18 апреля, 2013 Опубликовано 18 апреля, 2013 · Жалоба Я это тоже сначала хотел предложить, но по даташиту пробежался и не нашел там такого. Зато прерываний - по любому чиху есть. Давно это было... Режим настраивается AN_InitStructure.CAN_ABOM = DISABLE; Для STM32F407 при DISABLE передача останавливалась. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
net 0 19 апреля, 2013 Опубликовано 19 апреля, 2013 · Жалоба 1 насколько я помню в стандарте есть требования на количество ошибок в шине - и если perr больше чегото там (не помню но по моему порядка 10e-6) то такая шина считается неработоспособной и на нее не расчитывают 2 ничто не мешает (как вам написали выше работать по TXERR и RXERR) просто тупо их брасывая не забутьте только отменить передачу перед сбросом 3 ну а уж про таймауты это ваще дело что назывется ваше и вашей системы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться