[Arlleex 165]

7 часов назад, girts сказал:

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

Вы про теплое и круглое. Какое отношение имеет моя формулировка про принятие всеми абонентами или никем к "отправленности" сообщения?

Цитата

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

Еще раз

Цитата

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

Если любой из абонентов при приеме фрейма обнаружил любую из ошибок (кроме ACK Error), он разрушит трафик отправкой Error Frame. И никто из других абонентов валидный кадр не примет.

Цитата

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

Все эти пространные обсуждения, что в CAN-е не должно быть мастера, обычно, быстро сводятся на нет, когда начинаешь по-настоящему работать с этой шиной. Ну назовите его "координатор сети", если удобно. Для сведения: в CAN-е даже специально заложен механизм удаленного запроса, принцип которого все тот же "запрос-ответ". Тот кто запрашивает - мастер/ведущий/инициатор как угодно. Когда надо логически адресовать девайсы на шине - без кооринатора не обойтись. Когда на шине какой-то датчик, который раз в секунду выплевывает данные - не вопрос, мастер, может, и не нужен. Только мир чуть сложнее, чем просто бездумно выплевывать кадры с каким-то темпом.

Цитата

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

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

Цитата

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

Девайсы в кан запросто можно втыкать на горячую, или они могут подключаться/отключаться программно динамически в процессе работы. Переконфигурироваться, пока остальные работают штатно. Это - нормальный процесс, который не должен вообще никаким боком затрагивать штатный обмен и генерировать мусор с коллизиями и т.д. Очень жаль, что это для Вас не очевидно - для дома где-то оно еще прокатит, в пром вас не пустят.

[Arlleex 165]

8 часов назад, =AK= сказал:

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

Никаких косвенных признаков - признаки самые прямые - как только любой из абонентов увидел любую ошибку (кроме ACK Error, и ошибки Bit Error при арбитраже), он отправляет разрушающий трафик Error Frame. Этот Error Frame содержит последовательность битов, которая однозначно  будет трактоваться всеми приемниками как Stuff Error (а в большинстве случаев еще и Bit Error). Все участники, принявшие ошибку, точно так же начнут генерировать Error Frame. Все участники как собаки в деревне - одна начала гавкать - другие подхватили.

Цитата

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

Способ кодирования реального CAN позволяет онаружить битовое расхождение даже в случае, если все поля данных или ID были бы равны 0 (доминантными). Без Bit Stuffing, разумеется, передатчик такого фрейма никогда не узнал бы о коллизиях, потому что их по-определению быть не может. Но над CAN-ом подумали, прежде чем реализовывать и внедрять в пром и тем более в автомобильную отрасль, где на нем висят блоки, напрямую влияющие на безопасность водителей.

[jcxz 225]

9 часов назад, =AK= сказал:

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

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

Вроде как очевидно о какой задержке речь: Сейчас результат решения "отправится кадр сейчас или нет" определяется уже в конце передачи CAN-ID + пара_бит. Соответственно - начиная с этого момента отправляющая сторона уже может считать кадр отправленным. И например - начинать готовить новый кадр на передачу; или готовиться к приёму ответа (если таковой ожидается). С этого момента может освободить память, занимаемую отправляемым кадром и использовать её для других нужд. 

Если же арбитраж шёл бы по всему кадру, то такой момент времени наступал бы гораздо позже - после полного завершения отправки всего кадра.

 

Если будет понятнее по аналогии с UART, то: Когда записывать следующий байт в TX-буфер UART: после получения флага "буфер передатчика пуст" или после "сдвиговый регистр передатчика пуст"? Стандартно - по первому флагу. Но можно действовать и по второму флагу, но тогда вероятность межсимвольных дырок в передаваемом потоке будет гораздо выше. Здесь (в CAN) то же самое. Только разница во временах значительно больше.

 

Также и в CAN - если бы арбитраж шёл по всему кадру, то у отправителя было бы очень мало времени для подготовки нового кадра. (Если по каким-либо причинам невозможно готовить новый кадр при неотправленном предыдущем) А значит - вероятность межкадровых дырок в сплошном потоке кадров выросла бы. Т.е. - упала бы средняя скорость потока данных.

9 часов назад, girts сказал:

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

Ок. Не нравится аналогия с дверью+пальцем, тогда аналогия со смартфоном: Вот предположим - разработчики вашего смартфона - ваши единомышленники. Причём все - всех компонентов смартфона. А значит - иногда у вас на экране выводится какой-то мусор, иногда из динамика валит шум, иногда звонить отказывается. Ну а на ваше недовольство его работой, разработчики также вам скажут: "ну какие проблемы? Чего тебе трудно ещё раз попробовать позвонить? или ещё раз перегрузить телефон? или батарейку вынуть/вставить - трудно что-ль? Телефон же не сгорел, чего же страшного?" 

"Не выпала монетка - кидай ещё раз".   А если разработчики вашего авто такие же? Не побоитесь садиться в него??

 

PS: Но почему-то халтурщики и кое-какеры возмущаются, когда сталкиваются с чужой халтурой. Сами же халтурить считают нормальным. Почему так??....

[girts 9]

1 hour ago, Arlleex said:

Способ кодирования реального CAN позволяет онаружить битовое расхождение даже в случае, если все поля данных или ID были бы равны 0 (доминантными). Без Bit Stuffing, разумеется, передатчик такого фрейма никогда не узнал бы о коллизиях, потому что их по-определению быть не может. Но над CAN-ом подумали, прежде чем реализовывать и внедрять в пром и тем более в автомобильную отрасль, где на нем висят блоки, напрямую влияющие на безопасность водителей.

А вот давайте найдём хоть одну автомобильную имплементацию, где ID задаются на горячую и где позволено обновлять прошивки на ходу или допускается хотсвап или внезапное обнаружение вновь подключенных устройств?
ОК, допустим - прицепы и тому подобное. Но там строго регламентировано стандартом как они общаются. Это скорее девайс есть, или его нет.

Да, режим программирования.
Но это уже никак не штатная работа системы, и не допускается исполнение сего при движении, это скорее исключение. 
Динамическое назначение адресов - ну, что то близко к тому встречалось только в VAG TP - да и то это предопределённые ID на которые уходит коммуникация по "обоюдному согласию".
Кстати, есть ещё вариант GM, когда в момент программирования вся шина уходит на повышенную скорость (х 3), всё лишнее отпадает, и два устройства спокойно общаются между собой. 

Да и что там происходит на аппаратном уровне, должно мало волновать, ибо тут вроде как весь кипиш из за предположения, что все неотконфигурированные абоненты могут передавать на одном и том же ID?
Вероятность лобового столкновения двух бомжей на велосипедах в песках сахары ничтожно мала. Да и событие сиё ну никак неприведёт к глобальной катастрофе. 

А коллизии - ну, если на одних и тех же проводах спокойно уживаются стандартный CAN и CAN-FD одновременно, то... давай уж развивать теории как это вообще представляется возможным.


 

[girts 9]

1 hour ago, jcxz said:

PS: Но почему-то халтурщики и кое-какеры возмущаются, когда сталкиваются с чужой халтурой. Сами же халтурить считают нормальным. Почему так??....

Наезд?

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

Лирическое отступление - 

Купил как то филипсовское кухонное устройство с выходом в сеть год назад.
Вместо того, чтобы просто вбить адреса, пароли, явки - оно как то вот по умному, через приложение на телефоне. Сначала коннектится с блютузом к телефону, потом через это всё как то лезет в сеть.
После 2-х часов экспериментов оказалось, что скрытый SSID сети ей не по душе, и именно в момент конфигурации.
Включил, отконфигурировал, опять выключил в рутере. А дальше уже сия хрень работает автономно без проблем с тех пор.
В инструкции не намёка, ничего.
IOT, ёпт его в качель!

А ведь так просто было бы - предусмотреть пару полей, где в рукопашную вбить SSID, пароли, адреса - конфиг в ручную.

Правильно сделанное изделие имеет кнопу ВКЛ/ВЫКЛ и рычаг БОЛЬШЕ/МЕНЬШЕ.
А вы всё усложняете як бы на благо человека.

 
 

[=AK= 15]

2 hours ago, Arlleex said:

Никаких косвенных признаков - признаки самые прямые - как только любой из абонентов увидел любую ошибку (кроме ACK Error, и ошибки Bit Error при арбитраже), он отправляет разрушающий трафик Error Frame. Этот Error Frame содержит последовательность битов, которая однозначно  будет трактоваться всеми приемниками как Stuff Error (а в большинстве случаев еще и Bit Error). Все участники, принявшие ошибку, точно так же начнут генерировать Error Frame. Все участники как собаки в деревне - одна начала гавкать - другие подхватили.

А как борются с сумасшедшим узлом, который посылает Error Frame на все сообщения?

2 hours ago, Arlleex said:

Способ кодирования реального CAN позволяет онаружить битовое расхождение даже в случае, если все поля данных или ID были бы равны 0 (доминантными). Без Bit Stuffing, разумеется, передатчик такого фрейма никогда не узнал бы о коллизиях, потому что их по-определению быть не может.

Правильно ли я понял, что CAN полагается робастным за счет того, что пользователь отделен от реально происходящего на шине некой аппаратно реализованной прослойкой CAN? Она делает bit-stuffing и следит на нестыковками. Поэтому если пользователь и "сошел с ума" и посылает все биты доминантными, на шине не все биты не будут доминантнми, эта прослойка вставит рецессивный бит посля каждых 5 доминантных.

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

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

[jcxz 225]

1 час назад, girts сказал:

А вот давайте найдём хоть одну автомобильную имплементацию, где ID задаются на горячую и где позволено обновлять прошивки на ходу или допускается хотсвап или внезапное обнаружение вновь подключенных устройств?

а чего её искать? В прошлом проекте как раз такой транспорт и разработали - электро-микроавтобус. И он уже несколько лет как прошёл гос.регистрацию и катается по дорогам в нескольких автопарках.

Там все ID раздаются динамически, мастером. Включился девайс - и тут же получил свой ID. После прохождения энумерации. И обновление прошивок - в том числе через этот же протокол.

1 час назад, girts сказал:

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

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

Думаете - нафик они нужны?

1 час назад, girts сказал:

А коллизии - ну, если на одних и тех же проводах спокойно уживаются стандартный CAN и CAN-FD одновременно

И что? Какое это имеет отношение к преднамеренно создаваемым коллизиям?

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

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

И как это оправдывает ваше желание халтурить с CAN??? непонятно....

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

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

Вы бы тогда хотя-бы попробовали что-ль. И на практике бы убедились что это невозможно. Чем сто сообщений писать....

[girts 9]

1 minute ago, jcxz said:

а чего её искать? В прошлом проекте как раз такой транспорт и разработали - электро-микроавтобус. И он уже несколько лет как прошёл гос.регистрацию и катается по дорогам в нескольких автопарках.

Там все ID раздаются динамически, мастером. Включился девайс - и тут же получил свой ID. После прохождения энумерации. И обновление прошивок - в том числе через этот же протокол.

Один? Это типа как "свой автомобиль я собрал в ванной". Кустарное производство Кулибиных.
Не аргумент.
Госрегистрация - тем более.
Если вы ещё и таким образом создавали общение с ABS и писали программы под оного, то становится страшно - дайте маршруты и график передвижения сего творения местной инженерии, и я буду категорически избегать сих участков дорог в определённых промежутках времени. 

Quote

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

Думаете - нафик они нужны?

Последствия вашего примера - летальны и потери невозвратимы.
Аналогия неуместна, два!

Quote

И что? Какое это имеет отношение к преднамеренно создаваемым коллизиям?

Ну вот тут уже камень в ваш огород. Чем отличается фрейм CAN от CAN-FD?
Для того и другого - обратное видится как чисто испорченные данные.

[girts 9]

48 minutes ago, =AK= said:

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

CRC в конце сообщения.
Если и данные и ляжут друг на друга, то вряд ли будут признаны валидными и будет новая попытка трансляции... 

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

[jcxz 225]

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

Один?

Много.

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

Кустарное производство Кулибиных.

Может не будем болтать о том, о чём не имеем понятия и высасывать из пальца?

И кстати - человек забивающий на корректную работу интерфейса, делающий тяп-ляп "авось заработает, а если не заработает - передёрните питание ещё раз", ещё говорит о "кустарщине"....  

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

Аналогия неуместна, два!

Ясно с вами всё. Халтурщики неистребимы.  

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

CRC в конце сообщения.
Если и данные и ляжут друг на друга, то вряд ли будут признаны валидными и будет новая попытка трансляции... 

Халтура!

Не узнаёте себя?  

[girts 9]

Just now, jcxz said:

Много.

И где они? Стоят "на запасных путях в депо"?

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

 

8 minutes ago, jcxz said:

Ясно с вами всё. Халтурщики неистребимы.  

Именно.
И всё горе от ума!

[girts 9]

16 minutes ago, jcxz said:

Халтура!

Не узнаёте себя?  

О!
На обидчивых воду возят!
Креативы пошли, это хорошо! 
А в креативах рождается истина, и они толкают на размышления.

Так по вашему, совмещение CAN и CAN-FD - тоже халтура, нее? Только от товарища Роберта по фамилии BOSCH?
 

ЗЫ: если чисто лично, то я бы такую систему, какая тут рассматривается, в таком виде не делал бы вообще. Так что кто тут халтурит вопрос спорный, видимо всё зависит скорее от копромиссов между религиозными убеждениями и жаждой наживы индивидуума. 

 

[=AK= 15]

1 hour ago, jcxz said:

Вы бы тогда хотя-бы попробовали что-ль. И на практике бы убедились что это невозможно. Чем сто сообщений писать....

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