[jcxz 226]

59 минут назад, girts сказал:

2) и что? Если правильно помню, арбитраж работает не только на ID, но и на весь пакет.

Неправильно помните. Только на ID + несколько стартовых бит заголовка кадра.

59 минут назад, girts сказал:

Если девайс раз в 5 секунд орёт в шину чем то низкоприоритетным что ему треба конфиг имхо ничего страшного нет.

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

А если при этом по шине ещё и штатный обмен идёт? Да ещё довольно интенсивно? То вероятность коллизий получите весьма высокую.

59 минут назад, girts сказал:

Ну ОК, допустим, пакет испортился - и что? через рандомное время повторная попытка, делов то....

Если вам дверью прищемило палец - и что? Через рандомное время ведь всё равно заживёт. Так и здесь. С таким подходом конечно - какая разница? А в нормально разработанном девайсе не должно быть коллизий, возникающих при штатной работе девайса в идеальных условиях. Если девайс генерит коллизии при штатной работе в идеальных условиях - такой девайс годится только в мусорку. Имхо.

59 минут назад, girts сказал:

Сообщать раз в 10мс что появился новый девайс - смысла не особо. 

Всё зависит от задачи. Где-то и раз в час можно новые двеайсы обнаруживать, а где-то это слишком долго.

59 минут назад, girts сказал:

И даже если про тот аппаратный вариант, что посылка в слоте пытается повторно попасть в шину до полного успеха и ACK, так это тоже отключаемо и можно (и может и нужно) софтварно это всё обработать. 

Зачем выдумывать кривые варианты, если для такого есть нормальное решение? Без коллизий и прочего непотребства? Обсуждали ведь уже ранее...

И здесь у Arlleex протокол вообще не про это.

3 минуты назад, Arlleex сказал:

Очень плохо, что возникающие коллизии в шине для Вас норма.

[=AK= 15]

On 7/11/2024 at 4:21 AM, jcxz said:

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

Ужас какой.

6 minutes ago, Arlleex said:

У вас неправильные сведения со всеми вытекающими. Для понимания, почему сделано так, а не этак, понимать, как работает CAN, жизненно важно.

Очень плохо, что возникающие коллизии в шине для Вас норма. Благо бош заложил счетчики ошибок.

Я с CAN-ом не работал и до сих пор пребывал в невинной уверенности, что CAN-это CSMA/CA, т.е. в нем коллизий быть не должно. Правда, меня смущало, что арбитраж проводится только в начале сообщения, а не на всей его длине, как дОлжно было бы сделать.

[Arlleex 165]

17 минут назад, =AK= сказал:

Правда, меня смущало, что арбитраж проводится только в начале сообщения, а не на всей его длине, как дОлжно было бы сделать.

Не должно, зачем? Я больше скажу: бошу честь и хвала, что не сделал так.

[=AK= 15]

16 minutes ago, Arlleex said:

Не должно, зачем? Я больше скажу: бошу честь и хвала, что не сделал так.

А за что "честь и хвала", в чем преимущество? Арбитраж по всему телу сообщения - это честный CSMA/CA, а частичный арбитраж - это какая-то помесь CSMA/CA и CSMA/CD, "ни два, ни полтора" (с). Нафиг надо коллизии обрабатывать, если можно сделать, чтобы их вообще не было?

[Arlleex 165]

4 минуты назад, =AK= сказал:

А за что "честь и хвала", в чем преимущество? Арбитраж по всему телу сообщения - это честный CSMA/CA, а частичный арбитраж - это какая-то помесь CSMA/CA и CSMA/CD, "ни два, ни полтора" (с).

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

[=AK= 15]

5 minutes ago, Arlleex said:

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

Пардон, это и есть CSMA/CA, "Collision Avoidance", в этом отличие от CSMA/CD, "Collision Detection". Но при CSMA/CA коллизий на шине нет и быть не может. Почему тогда вы ведете речь о "возникающих коллизиях в шине" и "счетчиках ошибок"?

[Arlleex 165]

21 минуту назад, =AK= сказал:

Почему тогда вы ведете речь о "возникающих коллизиях в шине" и "счетчиках ошибок"?

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

Цитата

Пардон, это и есть CSMA/CA, "Collision Avoidance", в этом отличие от CSMA/CD, "Collision Detection". Но при CSMA/CA коллизий на шине нет и быть не может.

Это не так. В кане коллизии физически реальны за счет конструкции драйвера приемопередатчика. Вопрос протокола - как их обрабатывать. При арбитраже кан контроллер отключает активацию ошибок bit error, а за пределами арбитража включает.

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

[=AK= 15]

44 minutes ago, Arlleex said:

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

Непонятно. Если битовый компаратор CSMA/CA "видит ошибку", это значит, что он проиграл арбитраж. После чего он обязан прекратить передачу. Трафик при этом не нарушается.

Зачем нужно было ограничивать арбитраж только полем CAN ID, вместо того, чтобы продолжать его на все сообщение? В чем преимущество частичного CSMA/CA по сравнению с полным CSMA/CA?

Каким образом при этом "разрушается всем трафик", ведь он перестал передавать в рецессивном состоянии? Никто ничего не заметит, кроме него самого.

 

44 minutes ago, Arlleex said:

 Счетчики ошибок сделаны как раз на случай, если особо "вумный" разработчик решит плюнуть на всех и создавать коллизии на ровном месте, что в промавтоматике должно быть недопустимо. Он их создаст, но ограниченное количество, потом кан контроолер аппаратно прекратит сей акт террора.

Опять непонятно. Если на аппаратном уровне реализована CSMA/CA  на всем теле сообщения, то никакой "вумный разработчик" ничего с этим поделать не сможет - коллизий не будет.

Зачем в CAN в процессе передачи сообщения сделан переход от CSMA/CA к CSMA/CD?

Если "вумный разработчик" будет гнать сообщения из одних только доминантных уровней, его собственный контроллер CAN не сможет обнаружить, что он сошел с ума:

-- на полях CAN ID он как минимум не проиграет арбитраж
-- на остальных полях его доминантные уровни пересилят всех других, поэтому его собственный контроллер CAN не увидит никаких коллизий

[Arlleex 165]

1 час назад, =AK= сказал:

Непонятно. Если битовый компаратор CSMA/CA "видит ошибку", это значит, что он проиграл арбитраж. После чего он обязан прекратить передачу. Трафик при этом не нарушается.

Это только для поля CAN-ID. Арбитраж по CAN-ID (а не по всему сообщению) сделан для быстрого выявления победителя при передаче.

Цитата

Зачем нужно было ограничивать арбитраж только полем CAN ID, вместо того, чтобы продолжать его на все сообщение? В чем преимущество частичного CSMA/CA по сравнению с полным CSMA/CA?

Представьте: передает узел различные данные, и за счет различия в битах данных приоритет кадра постоянно меняется. Это недопустимо в CAN. Арбитраж необходим для приоритетного предоставления среды передачи кадрам, у которых ID имеет меньшее числовое значение. Этим гарантируется детерминизм среды и доставки кадров узлам.

Цитата

Каким образом при этом "разрушается всем трафик", ведь он перестал передавать в рецессивном состоянии? Никто ничего не заметит, кроме него самого.

Контроллер CAN отправляет "неправильный" набор битов, который намеренно вызывает коллизию битов, так называемый Error Frame.

Цитата

Опять непонятно. Если на аппаратном уровне реализована CSMA/CA  на всем теле сообщения, то никакой "вумный разработчик" ничего с этим поделать не сможет - коллизий не будет.

Для мысленного эксперимента, где арбитраж происходил бы не только по CAN ID, а вообще по всем битам фрейма, представьте, как поляжет вся сеть, если такой вумный разработчик забагует в своем ПО и начнет слать CAN ID == 0 и все поля данных == 0. Практически не сунуться другим кадрам в соответствии с правилами приоритетов.

Цитата

Зачем в CAN в процессе передачи сообщения сделан переход от CSMA/CA к CSMA/CD?

Для обнаружения коллизий участниками сети, сообщения узлу, генерирующему эти коллизии, о том, что ему бы заткнуться, и затыкания забагованного узла.

Цитата

Если "вумный разработчик" будет гнать сообщения из одних только доминантных уровней, его собственный контроллер CAN не сможет обнаружить, что он сошел с ума:

Не сможет, CAN-контроллер кодирует 5 подряд идущих доминантных битов бит-стаффингом в 1 рецессивный бит (и наоборот) для самосинхронизации.

Цитата

-- на остальных полях его доминантные уровни пересилят всех других, поэтому его собственный контроллер CAN не увидит никаких коллизий

В CAN так и должно быть - если узел отправляет ID с одними доминантами (т.е. CAN ID == 0x0), то этот кадр считается самым приоритетным, его никто не сможет перебить.

[jcxz 226]

1 час назад, =AK= сказал:

Зачем нужно было ограничивать арбитраж только полем CAN ID, вместо того, чтобы продолжать его на все сообщение?

Вот мнение Всемирного Разума по вашему вопросу:

Цитата

вопрос:

Почему арбитраж в CAN производится только по указанным полям, а не по всем полям кадра (в том числе - почему арбитраж не производится по полю данных)?

ответ:

Арбитраж в CAN-сети производится только по полям идентификатора (ID) и связанным с ним полям (RTR и IDE) по нескольким важным причинам:

1. Цель арбитража — определение приоритета передачи:

• Основная цель арбитража в CAN — это определение приоритета сообщений при одновременной попытке передачи несколькими узлами. Идентификатор (ID) сообщения является ключевым полем, которое определяет этот приоритет. Сообщение с наименьшим идентификатором имеет наивысший приоритет.
• Поле данных не связано с приоритетом сообщения. Оно содержит саму полезную информацию, и его значение не должно влиять на право передачи сообщения.

2. Минимизация задержек и сложностей в системе:

• Арбитраж производится в начале передачи сообщения, чтобы минимизировать задержки и обеспечить быстрый выбор узла, который будет передавать данные.
• Если бы арбитраж производился по полю данных, система была бы вынуждена ждать окончания передачи поля данных, что увеличило бы задержки и усложнило процесс арбитража. Время на передачу данных, особенно если их много, могло бы стать критическим, нарушая требования к реальному времени, которые часто предъявляются к CAN-сетям.

3. Стабильность и предсказуемость работы сети:

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

4. Разделение функций:

• В CAN-сети каждое поле имеет свою конкретную функцию. Поле идентификатора отвечает за приоритет и адресацию, а поле данных — за перенос информации. Разделение этих функций позволяет системе работать более эффективно и структурированно.
• Вмешательство поля данных в процесс арбитража нарушило бы это четкое разделение и привело бы к увеличению сложности протокола.

5. Аппаратные ограничения:

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

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

Целых 5 пунктов!  

Цитата

вопрос:

Как думаешь - полезно было бы выполнять арбитраж по всему кадру CAN?

ответ:

Арбитраж по всему кадру CAN был бы не только сложным, но и менее эффективным по сравнению с текущей системой. Ниже приведены основные аргументы против этого:

1. Увеличение задержек:

• Если бы арбитраж происходил по всему кадру, узлы должны были бы ждать завершения передачи каждого кадра, чтобы определить, кто выигрывает арбитраж. Это увеличило бы задержки в сети, особенно в случаях, когда длина кадра велика.
• CAN используется в системах реального времени, где минимальные задержки критичны, например, в автомобильных системах управления. Увеличение времени на арбитраж негативно сказалось бы на быстродействии всей сети.

2. Усложнение реализации:

• Арбитраж по всему кадру усложнил бы алгоритмы CAN-контроллеров и увеличил бы их стоимость. Более сложный арбитраж потребовал бы большего объема аппаратных ресурсов, что противоречит цели CAN как простого и эффективного протокола для встраиваемых систем.
• Особенно это затруднит работу устройств с ограниченными вычислительными и энергетическими ресурсами, где минимизация затрат и простота реализации важны.

3. Нарушение предсказуемости работы сети:

• Одним из ключевых преимуществ CAN является предсказуемость передачи сообщений. Идентификатор (ID) определяет приоритет сообщения, и это позволяет проектировать системы с учетом критичности данных. Если арбитраж зависел бы от всех полей, поведение сети стало бы менее предсказуемым, поскольку приоритет сообщений мог бы изменяться в зависимости от содержимого кадра.
• Это особенно важно в системах, где определенные сообщения должны передаваться с высоким приоритетом, например, экстренные сообщения в автомобилях или промышленных системах.

4. Снижение эффективности передачи данных:

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

5. Отсутствие значимой выгоды:

• Арбитраж по данным кадра не приносит значимой выгоды с точки зрения приоритизации сообщений. Поле данных не влияет на важность сообщения, оно лишь передает содержимое. Фокус на арбитраже по идентификатору сообщения — это оптимальное решение, позволяющее управлять приоритетами без лишних накладных расходов.
• Важно разделять задачи: арбитраж должен определять, кто имеет право передавать данные, а не оценивать содержимое этих данных.

Заключение:

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

[Arlleex 165]

6 часов назад, jcxz сказал:

Вот ещё вопрос: Раз цель - чтобы "сторонний разработчик не вдавался в детали", то почему нет компонента, выдающего прогнозируемую загрузку шины?

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

[jcxz 226]

1 минуту назад, Arlleex сказал:

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

Эх - боитесь вы юзверя, боитесь!  

[Arlleex 165]

6 минут назад, jcxz сказал:

Эх - боитесь вы юзверя, боитесь!  

На то есть причины)) Не каждый юзверь весьма адекватен, поэтому стараюсь с ними не контактировать напрямую

[=AK= 15]

9 hours ago, jcxz said:

Вот мнение Всемирного Разума по вашему вопросу:

Целых 5 пунктов!  

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

Все-таки чего-то я в CAN не понимаю. О каких "задержках" идет речь? Арбитраж ведь ведется в реальном времени. Определился победитель в начале кадра, в середине или в конце, это ни на что не влияет и никаких задержек не создает. Наоборот, если арбитраж идет только в начале и при равных приоритетах два узла портят друг другу данные, вот это создаст задержку - эту ошибку надо обработать и потратить время на две повторных передачи, плюс, вероятно, на две рандомные задержки, чтобы избежать повторной коллизии.

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

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

Это можно было бы сделать и другим способом. Например, вести арбитраж CSMA/CA на всем кадре, но сделать его "двухступенчатым". В начале кадра узлы, проигравшие арбитраж, затыкаются и молчат до самого конца кадра. А узлы, проигравшие арбитраж в оставшейся части кадра, помалкивают до самого последнего бита кадра (или до первого бит-интервала за пределами кадра), в котором они устанавливают доминантный уровень. Этот бит - "жалоба". Узел, выгравший арбитраж, обязан выставить рецессивный уровень в этом бите. Таким образом все узлы смогут узнать о "коллизии", но при этом самой коллизии не будет и передавать повторно ничего не требуется. Никаких "монстров" тоже не возникнет.

10 hours ago, Arlleex said:

Для мысленного эксперимента, где арбитраж происходил бы не только по CAN ID, а вообще по всем битам фрейма, представьте, как поляжет вся сеть, если такой вумный разработчик забагует в своем ПО и начнет слать CAN ID == 0 и все поля данных == 0. Практически не сунуться другим кадрам в соответствии с правилами приоритетов.

Для обнаружения коллизий участниками сети, сообщения узлу, генерирующему эти коллизии, о том, что ему бы заткнуться, и затыкания забагованного узла.

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

[girts 9]

10 hours ago, Arlleex said:

В кане либо все правильно принимают фрейм, либо никто никак.

ИМХО неверно.
Сообщение считается отправленным, если приём подтвердил хотя бы один абонент.

А дошло ли оно в читабельном виде до конца линии, никому не известно.

То, что создавал BOSCH - вообщем то под чуть под другие задачи. И уже изначально наличие всего одного мастера и множества слейвов как то не совсем по КАНовски. Ибо идеология подразумевает, что все вещают для всех, и только тогда это всё имеет смысл. 

 

 

11 hours ago, jcxz said:

Если вам дверью прищемило палец - и что? Через рандомное время ведь всё равно заживёт. Так и здесь. С таким подходом конечно - какая разница? А в нормально разработанном девайсе не должно быть коллизий, возникающих при штатной работе девайса в идеальных условиях. Если девайс генерит коллизии при штатной работе в идеальных условиях - такой девайс годится только в мусорку. Имхо.

Аналогия неуместна.
Скорее, если кинул монету, и не выпала решка, кидаешь ещё раз.
Монете по барабану.
Не провода же режутся (прищемляются дверю).

да и штатная работа != момент конфигурации.