Arlleex 183 16 августа Опубликовано 16 августа · Жалоба 7 часов назад, girts сказал: ИМХО неверно. Сообщение считается отправленным, если приём подтвердил хотя бы один абонент. Вы про теплое и круглое. Какое отношение имеет моя формулировка про принятие всеми абонентами или никем к "отправленности" сообщения? Цитата А дошло ли оно в читабельном виде до конца линии, никому не известно. Еще раз Цитата В кане либо все правильно принимают фрейм, либо никто никак. Если любой из абонентов при приеме фрейма обнаружил любую из ошибок (кроме ACK Error), он разрушит трафик отправкой Error Frame. И никто из других абонентов валидный кадр не примет. Цитата То, что создавал BOSCH - вообщем то под чуть под другие задачи. И уже изначально наличие всего одного мастера и множества слейвов как то не совсем по КАНовски. Ибо идеология подразумевает, что все вещают для всех, и только тогда это всё имеет смысл. Все эти пространные обсуждения, что в CAN-е не должно быть мастера, обычно, быстро сводятся на нет, когда начинаешь по-настоящему работать с этой шиной. Ну назовите его "координатор сети", если удобно. Для сведения: в CAN-е даже специально заложен механизм удаленного запроса, принцип которого все тот же "запрос-ответ". Тот кто запрашивает - мастер/ведущий/инициатор как угодно. Когда надо логически адресовать девайсы на шине - без кооринатора не обойтись. Когда на шине какой-то датчик, который раз в секунду выплевывает данные - не вопрос, мастер, может, и не нужен. Только мир чуть сложнее, чем просто бездумно выплевывать кадры с каким-то темпом. Цитата Аналогия неуместна. Скорее, если кинул монету, и не выпала решка, кидаешь ещё раз. Монете по барабану. Не провода же режутся (прищемляются дверю). В данном случае у игрока есть счетчик попыток, и если ему не везет слишком интенсивно, ему затыкают рот и отбирают монетку. Силой. Цитата да и штатная работа != момент конфигурации. Девайсы в кан запросто можно втыкать на горячую, или они могут подключаться/отключаться программно динамически в процессе работы. Переконфигурироваться, пока остальные работают штатно. Это - нормальный процесс, который не должен вообще никаким боком затрагивать штатный обмен и генерировать мусор с коллизиями и т.д. Очень жаль, что это для Вас не очевидно - для дома где-то оно еще прокатит, в пром вас не пустят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 183 16 августа Опубликовано 16 августа · Жалоба 8 часов назад, =AK= сказал: Побочным эффектом является то, что узлы, испортившие друг другу поля данных, знают об этом, а вот все остальные узлы - вообще говоря нет, только по косвенным признакам. И если так неудачно сложится, что результирующее сообщение окажется валидным CAN сообщением (назовем его "монстр"), то последствия могут быть плачевными. Никаких косвенных признаков - признаки самые прямые - как только любой из абонентов увидел любую ошибку (кроме ACK Error, и ошибки Bit Error при арбитраже), он отправляет разрушающий трафик Error Frame. Этот Error Frame содержит последовательность битов, которая однозначно будет трактоваться всеми приемниками как Stuff Error (а в большинстве случаев еще и Bit Error). Все участники, принявшие ошибку, точно так же начнут генерировать Error Frame. Все участники как собаки в деревне - одна начала гавкать - другие подхватили. Цитата Если узел передает одни доминантные уровни, его фрейм не будет испорчен, он ничего не узнает о коллизии. В случае реальных данных всегда есть вероятность, что один из узлов передаст свой фрейм неиспорченным и не узнает о коллизии. Соответственно, педалировать на некий "детерминизм" не приходится. Способ кодирования реального CAN позволяет онаружить битовое расхождение даже в случае, если все поля данных или ID были бы равны 0 (доминантными). Без Bit Stuffing, разумеется, передатчик такого фрейма никогда не узнал бы о коллизиях, потому что их по-определению быть не может. Но над CAN-ом подумали, прежде чем реализовывать и внедрять в пром и тем более в автомобильную отрасль, где на нем висят блоки, напрямую влияющие на безопасность водителей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 16 августа Опубликовано 16 августа · Жалоба 9 часов назад, =AK= сказал: Если бы арбитраж происходил по всему кадру, узлы должны были бы ждать завершения передачи каждого кадра, чтобы определить, кто выигрывает арбитраж. Это увеличило бы задержки в сети, особенно в случаях, когда длина кадра велика. Все-таки чего-то я в CAN не понимаю. О каких "задержках" идет речь? Арбитраж ведь ведется в реальном времени. Определился победитель в начале кадра, в середине или в конце, это ни на что не влияет и никаких задержек не создает. Вроде как очевидно о какой задержке речь: Сейчас результат решения "отправится кадр сейчас или нет" определяется уже в конце передачи CAN-ID + пара_бит. Соответственно - начиная с этого момента отправляющая сторона уже может считать кадр отправленным. И например - начинать готовить новый кадр на передачу; или готовиться к приёму ответа (если таковой ожидается). С этого момента может освободить память, занимаемую отправляемым кадром и использовать её для других нужд. Если же арбитраж шёл бы по всему кадру, то такой момент времени наступал бы гораздо позже - после полного завершения отправки всего кадра. Если будет понятнее по аналогии с UART, то: Когда записывать следующий байт в TX-буфер UART: после получения флага "буфер передатчика пуст" или после "сдвиговый регистр передатчика пуст"? Стандартно - по первому флагу. Но можно действовать и по второму флагу, но тогда вероятность межсимвольных дырок в передаваемом потоке будет гораздо выше. Здесь (в CAN) то же самое. Только разница во временах значительно больше. Также и в CAN - если бы арбитраж шёл по всему кадру, то у отправителя было бы очень мало времени для подготовки нового кадра. (Если по каким-либо причинам невозможно готовить новый кадр при неотправленном предыдущем) А значит - вероятность межкадровых дырок в сплошном потоке кадров выросла бы. Т.е. - упала бы средняя скорость потока данных. 9 часов назад, girts сказал: Аналогия неуместна. Скорее, если кинул монету, и не выпала решка, кидаешь ещё раз. Монете по барабану. Не провода же режутся (прищемляются дверю). Ок. Не нравится аналогия с дверью+пальцем, тогда аналогия со смартфоном: Вот предположим - разработчики вашего смартфона - ваши единомышленники. Причём все - всех компонентов смартфона. А значит - иногда у вас на экране выводится какой-то мусор, иногда из динамика валит шум, иногда звонить отказывается. Ну а на ваше недовольство его работой, разработчики также вам скажут: "ну какие проблемы? Чего тебе трудно ещё раз попробовать позвонить? или ещё раз перегрузить телефон? или батарейку вынуть/вставить - трудно что-ль? Телефон же не сгорел, чего же страшного?" "Не выпала монетка - кидай ещё раз". А если разработчики вашего авто такие же? Не побоитесь садиться в него?? PS: Но почему-то халтурщики и кое-какеры возмущаются, когда сталкиваются с чужой халтурой. Сами же халтурить считают нормальным. Почему так??.... 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба 1 hour ago, Arlleex said: Способ кодирования реального CAN позволяет онаружить битовое расхождение даже в случае, если все поля данных или ID были бы равны 0 (доминантными). Без Bit Stuffing, разумеется, передатчик такого фрейма никогда не узнал бы о коллизиях, потому что их по-определению быть не может. Но над CAN-ом подумали, прежде чем реализовывать и внедрять в пром и тем более в автомобильную отрасль, где на нем висят блоки, напрямую влияющие на безопасность водителей. А вот давайте найдём хоть одну автомобильную имплементацию, где ID задаются на горячую и где позволено обновлять прошивки на ходу или допускается хотсвап или внезапное обнаружение вновь подключенных устройств? ОК, допустим - прицепы и тому подобное. Но там строго регламентировано стандартом как они общаются. Это скорее девайс есть, или его нет. Да, режим программирования. Но это уже никак не штатная работа системы, и не допускается исполнение сего при движении, это скорее исключение. Динамическое назначение адресов - ну, что то близко к тому встречалось только в VAG TP - да и то это предопределённые ID на которые уходит коммуникация по "обоюдному согласию". Кстати, есть ещё вариант GM, когда в момент программирования вся шина уходит на повышенную скорость (х 3), всё лишнее отпадает, и два устройства спокойно общаются между собой. Да и что там происходит на аппаратном уровне, должно мало волновать, ибо тут вроде как весь кипиш из за предположения, что все неотконфигурированные абоненты могут передавать на одном и том же ID? Вероятность лобового столкновения двух бомжей на велосипедах в песках сахары ничтожно мала. Да и событие сиё ну никак неприведёт к глобальной катастрофе. А коллизии - ну, если на одних и тех же проводах спокойно уживаются стандартный CAN и CAN-FD одновременно, то... давай уж развивать теории как это вообще представляется возможным. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба 1 hour ago, jcxz said: PS: Но почему-то халтурщики и кое-какеры возмущаются, когда сталкиваются с чужой халтурой. Сами же халтурить считают нормальным. Почему так??.... Наезд? За то "умные люди" создают всякие умные аппликации по настройке оборудования нажатием одной кнопы, которые работают только в идеальной среде и в ими же созданных благоприятных условиях. Лирическое отступление - Купил как то филипсовское кухонное устройство с выходом в сеть год назад. Вместо того, чтобы просто вбить адреса, пароли, явки - оно как то вот по умному, через приложение на телефоне. Сначала коннектится с блютузом к телефону, потом через это всё как то лезет в сеть. После 2-х часов экспериментов оказалось, что скрытый SSID сети ей не по душе, и именно в момент конфигурации. Включил, отконфигурировал, опять выключил в рутере. А дальше уже сия хрень работает автономно без проблем с тех пор. В инструкции не намёка, ничего. IOT, ёпт его в качель! А ведь так просто было бы - предусмотреть пару полей, где в рукопашную вбить SSID, пароли, адреса - конфиг в ручную. Правильно сделанное изделие имеет кнопу ВКЛ/ВЫКЛ и рычаг БОЛЬШЕ/МЕНЬШЕ. А вы всё усложняете як бы на благо человека. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 августа Опубликовано 16 августа · Жалоба 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 241 16 августа Опубликовано 16 августа · Жалоба 1 час назад, girts сказал: А вот давайте найдём хоть одну автомобильную имплементацию, где ID задаются на горячую и где позволено обновлять прошивки на ходу или допускается хотсвап или внезапное обнаружение вновь подключенных устройств? а чего её искать? В прошлом проекте как раз такой транспорт и разработали - электро-микроавтобус. И он уже несколько лет как прошёл гос.регистрацию и катается по дорогам в нескольких автопарках. Там все ID раздаются динамически, мастером. Включился девайс - и тут же получил свой ID. После прохождения энумерации. И обновление прошивок - в том числе через этот же протокол. 1 час назад, girts сказал: Вероятность лобового столкновения двух бомжей на велосипедах в песках сахары ничтожно мала. Вероятность столковения двух самолётов воздухе - ещё на порядки меньше. Тем не менее зачем-то создаются сложные и дорогостоящие системы управления воздушным движением. Думаете - нафик они нужны? 1 час назад, girts сказал: А коллизии - ну, если на одних и тех же проводах спокойно уживаются стандартный CAN и CAN-FD одновременно И что? Какое это имеет отношение к преднамеренно создаваемым коллизиям? 21 минуту назад, girts сказал: Купил как то филипсовское кухонное устройство с выходом в сеть год назад. Вместо того, чтобы просто вбить адреса, пароли, явки - оно как то вот по умному, через приложение на телефоне. Сначала коннектится с блютузом к телефону, потом через это всё как то лезет в сеть. И как это оправдывает ваше желание халтурить с CAN??? непонятно.... 9 минут назад, =AK= сказал: Для меня неочевиден ответ на вопрос, можно ли одновременно передать два кадра с одинаковыми приоритетами и разными данными, но при этом коллизия не будет обнаружена никем кроме передающих узлов. Вы бы тогда хотя-бы попробовали что-ль. И на практике бы убедились что это невозможно. Чем сто сообщений писать.... 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба 1 minute ago, jcxz said: а чего её искать? В прошлом проекте как раз такой транспорт и разработали - электро-микроавтобус. И он уже несколько лет как прошёл гос.регистрацию и катается по дорогам в нескольких автопарках. Там все ID раздаются динамически, мастером. Включился девайс - и тут же получил свой ID. После прохождения энумерации. И обновление прошивок - в том числе через этот же протокол. Один? Это типа как "свой автомобиль я собрал в ванной". Кустарное производство Кулибиных. Не аргумент. Госрегистрация - тем более. Если вы ещё и таким образом создавали общение с ABS и писали программы под оного, то становится страшно - дайте маршруты и график передвижения сего творения местной инженерии, и я буду категорически избегать сих участков дорог в определённых промежутках времени. Quote Вероятность столковения двух самолётов воздухе - ещё на порядки меньше. Тем не менее зачем-то создаются сложные и дорогостоящие системы управления воздушным движением. Думаете - нафик они нужны? Последствия вашего примера - летальны и потери невозвратимы. Аналогия неуместна, два! Quote И что? Какое это имеет отношение к преднамеренно создаваемым коллизиям? Ну вот тут уже камень в ваш огород. Чем отличается фрейм CAN от CAN-FD? Для того и другого - обратное видится как чисто испорченные данные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба 48 minutes ago, =AK= said: Для меня неочевиден ответ на вопрос, можно ли одновременно передать два кадра с одинаковыми приоритетами и разными данными, но при этом коллизия не будет обнаружена никем кроме передающих узлов. CRC в конце сообщения. Если и данные и ляжут друг на друга, то вряд ли будут признаны валидными и будет новая попытка трансляции... Если делать серьёзную систему и предотвратить её от возможности иньекции ложных сообщений / подмены или контроля непринятых сообщений, где это критично - в данных обычно ставят счётчик и при надобности ещё какую то контрольку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 16 августа Опубликовано 16 августа · Жалоба 38 минут назад, girts сказал: Один? Много. 38 минут назад, girts сказал: Кустарное производство Кулибиных. Может не будем болтать о том, о чём не имеем понятия и высасывать из пальца? И кстати - человек забивающий на корректную работу интерфейса, делающий тяп-ляп "авось заработает, а если не заработает - передёрните питание ещё раз", ещё говорит о "кустарщине".... 38 минут назад, girts сказал: Аналогия неуместна, два! Ясно с вами всё. Халтурщики неистребимы. 17 минут назад, girts сказал: CRC в конце сообщения. Если и данные и ляжут друг на друга, то вряд ли будут признаны валидными и будет новая попытка трансляции... Халтура! Не узнаёте себя? 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба Just now, jcxz said: Много. И где они? Стоят "на запасных путях в депо"? Из всех тех, про которых я вкурсе, реально употребимого мало, это чисто распил денег еврофондов под "зелёнорадужный" курс во имя нашего светлого будущего. Но если это то, про что я думаю, то там хоть все критические системы остались нетронутыми, как с завода автобусиков. И добавление электрической тяги вместо дизеля - это НЕ создание чего то кардинально нового, а просто надстройка. Называть это "создать систему на ровном месте" как то чуть преувеличение. 8 minutes ago, jcxz said: Ясно с вами всё. Халтурщики неистребимы. Именно. И всё горе от ума! 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 16 августа Опубликовано 16 августа · Жалоба 16 minutes ago, jcxz said: Халтура! Не узнаёте себя? О! На обидчивых воду возят! Креативы пошли, это хорошо! А в креативах рождается истина, и они толкают на размышления. Так по вашему, совмещение CAN и CAN-FD - тоже халтура, нее? Только от товарища Роберта по фамилии BOSCH? ЗЫ: если чисто лично, то я бы такую систему, какая тут рассматривается, в таком виде не делал бы вообще. Так что кто тут халтурит вопрос спорный, видимо всё зависит скорее от копромиссов между религиозными убеждениями и жаждой наживы индивидуума. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 августа Опубликовано 16 августа · Жалоба 1 hour ago, jcxz said: Вы бы тогда хотя-бы попробовали что-ль. И на практике бы убедились что это невозможно. Чем сто сообщений писать.... Есть большая разница между "на практике убедиться" и "теоретически невозможно". Вам жизни не хватит, чтобы на практике убедиться, что стая обезьян, хаотически стучащая по клавишам пишущей машинки, способна или неспособна рано или поздно напечатать "Войну и мир". 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 августа Опубликовано 16 августа · Жалоба 2 hours ago, girts said: CRC в конце сообщения. Именно это я и имел ввиду, говоря о том, что прочие узлы узнают о коллизии разве что по косвенным признакам. А в случае когда CRC остался неизменным - вообще не узнают. И не надо мне парить мозги мнимым "детерминизмом". Реальным доводом может быть "низкая вероятность", но желательно с цифрами, а не "на арапа". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 183 16 августа Опубликовано 16 августа · Жалоба 3 часа назад, girts сказал: А коллизии - ну, если на одних и тех же проводах спокойно уживаются стандартный CAN и CAN-FD одновременно, то... давай уж развивать теории как это вообще представляется возможным. Уживаются они потому, что правильно парсят контрольные управляющие поля в пределах и за полем арбитража, чтобы уметь отличить FD и CAN2.0B. И поэтому при передаче данных CAN FD, обычный CAN-контроллер какого-либо узла просто не слушает эти биты данных. Вы же в курсе, надеюсь, что у CAN FD только поле данных передается на повышенной скорости? Не задумывались, почему биты управления (все остальные) должны быть на той же битовой скорости, что и все другие абоненты стандартного CAN? 2 часа назад, =AK= сказал: А как борются с сумасшедшим узлом, который посылает Error Frame на все сообщения? Он не сможет слать Error Frame до бесконечности. По достижению счетчика кан-контроллер увидит, что что-то идет не так, и отправляться будет уже не флаг активной ошибки (Active Error Flag), который рушит трафик на шине, а флаг пассивной ошибки: трафик он не рушит, а молча увеличивает счетчик ошибок, пока узел не дойдет до Bus Off, и замолкнет навеки (ну, вывести его из этого коматоза можно программно). Цитата Правильно ли я понял, что CAN полагается робастным за счет того, что пользователь отделен от реально происходящего на шине некой аппаратно реализованной прослойкой CAN? Она делает bit-stuffing и следит на нестыковками. Поэтому если пользователь и "сошел с ума" и посылает все биты доминантными, на шине не все биты не будут доминантнми, эта прослойка вставит рецессивный бит посля каждых 5 доминантных. Именно так! Цитата Если есть второй узел, который не проиграл арбитраж, чем гарантируется наличие коллизий? Ведь может так совпасть, что второй узел тоже транслирует рецессивный уровень данных в тот момент, когда первый узел транслирует рецессивный бит по причине байт-стаффинга? Бит-стаффинг всего лишь предотвращает большую длительность "не переключения" шины. Передавая много единичек подряд (или нулей), схеме синхронизации не за что зацепиться, поэтому бит-стаффинг вставляет инверсию бита. Все узлы "следят", чтобы в пределах передачи кадра не было ошибки бит-стаффинга, т.е. если хоть один девайс видит, что на шине начат фрейм, и где-то в его середине пролетело 5 одинаковых битов, он немедленно "ворвется на танцпол" и отправит Error Frame, который порушит трафик. Но узел на шине, как правило, не один - вместе с ним все, кто увидили такое, тоже начнут рушить трафик. Это все аппаратно - программист этим не управляет. Он кладет данные в буфер и жмакает бит "отправить", следя за флагами статуса отправки (были ли ошибки, и т.д.). Цитата Для меня неочевиден ответ на вопрос, можно ли одновременно передать два кадра с одинаковыми приоритетами и разными данными, но при этом коллизия не будет обнаружена никем кроме передающих узлов. Нет, такой вариант немедленно приведет к коллизии и в итоге фрейм не получит никакой из абонентов, а те, кто его передавали, зафиксируют ошибку передачи. Поэтому: без 146% гарантий, что несколько девайсов не будут формировать кадров с одним ID но разными данными в одно и то же время, коллизии имеют место быть. Разнесите транзакции по времени - и пожалуйста, хоть 100 устройств могут слать кадры с одним ID но разными данными. Коллизий не будет. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться