jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 22 часа назад, Arlleex сказал: Естественно, в жизни так делать не нужно (я про одинаковые ID) Почему? У меня в рабочем проекте есть такие передачи (обычный CAN, не FD). И даже много. Не вижу причин почему так нельзя делать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 1 час назад, jcxz сказал: Не вижу причин почему так нельзя делать. Смотря насколько сильно загружена шина сообщениями с одинаковыми ID от разных абонентов. Если не сильно или обмен спроектирован по какой-то временной диаграмме, где сообщения теоретически пересекаться по времени не должны, то проблем нет. Иначе же возможны коллизии в данных, с соответствующими разрушающими Error Frame и т.д. И чем чаще столкновения, тем больше этих Error Frame будет на шине. Чисто в теории можно настолько сильно забить шину, что некоторые узлы отвалятся в Bus Off, когда счетчик ошибок будет увеличиваться быстрее, чем уменьшаться успешной транзакцией. Не говорю, что вот прямо строго нельзя. Можно, но с определенными допущениями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 32 минуты назад, Arlleex сказал: Смотря насколько сильно загружена шина сообщениями с одинаковыми ID от разных абонентов. Если не сильно или обмен спроектирован по какой-то временной диаграмме, где сообщения теоретически пересекаться по времени не должны, то проблем нет. Иначе же возможны коллизии в данных Да при чём тут "коллизии данных"? Нет их. Протокол (прикладной, который ходит поверх CAN), как раз и рассчитан на то что будут (и должны быть обязательно! иначе он не будет работать) столкновения кадров с одинаковым ID. Именно на этих столкновениях основана работа протокола. В той теме, про арбитраж CAN, которая была тут пару лет назад, я как раз описывал как и зачем нужны такие кадры. Тогда это были планы по реализации, а сейчас - это уже давно реализовано и работает. А нужно для автоматического обнаружения, энумерации и последующего взаимодействия нескольких одинаковых устройств на шине, с заранее неизвестными уникальными ID. Для автоматического назначения им адресов. И ошибок на шине нет ни одной, при работе этого протокола. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 41 минуту назад, jcxz сказал: И ошибок на шине нет ни одной, при работе этого протокола. Значит после энумерации у Вас нет узлов, которые в рабочем режиме имеют одинаковые CAN-ID на передачу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 1 час назад, Arlleex сказал: Значит после энумерации у Вас нет узлов, которые в рабочем режиме имеют одинаковые CAN-ID на передачу. Нету "после" и "до". Нет "рабочего режима" и какого-то другого. Всё работает одновременно. Энумерация происходит непрерывно, циклически, всё время пока на шине присутствует "мастер энумерации". Давая возможность интерактивно в реальном времени обнаруживать вновь подключившиеся и отключившиеся устройства. Процесс энумерации идёт в одно и то же время с остальными процессами. Как например по Ethernet одновременно и не мешая друг другу ходят множество разных протоколов, так у меня по CAN - множество процессов/протоколов работают одновременно. Для энумерации просто выделен свой диапазон адресов, в котором она работает. Просто есть множество устройств на шине с уникальными 64-битными ID (заводские номера). Заранее не известными. И в какой-то момент, одно из этих устройств решает что оно "мастер". И запускает процесс энумерации. И продолжает его циклически до тех пор, пока считает себя мастером. Назначение роли "мастер" происходит динамически, может быть назначено любому устройству на шине в любой момент времени. Назначение происходит по внешнему сигналу (внешнему относительно CAN). Одновременно на шине может присутствовать только один мастер. Протокол также имеет средства разрешения ситуации 2-х одновременных мастеров на шине (просто оба блокируются пока не останется один). В любом случае - ошибок на шине нет ни при каких штатных ситуациях. Протокол их не генерирует. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба Еще раз: Вы пытаетесь мне сказать, что у Вас ни при каких обстоятельствах не бывает Error Frame на шине? Есть у Вас там верхние протоколы или нету - вопрос совершенно пока что вторичный. У Вас сколько девайсов на шине? Практически и теоретически. Вот если на шине 100 девайсов по запросу (для эксперимента это лучше) начнут швырять в шину фреймы с одинаковыми CAN-ID но разным data payload, вполне запросто можно добиться ситуации, когда куча девайсов на этой шине просто уйдут в Bus Off. Потому что, пытаясь отправить свои сообщения, они будут обнаруживать коллизии битов данных, прекращать передачу и формировать Error Frame, увеличивая на 8 счетчик ошибок. Далее девайсы снова попытаются отправить. Когда счетчик перевалит за > 127, Error Frame-ы будут отправлять только девайсы, чье состояние все еще Active Error. Но девайсы в состоянии Passive Error уже не будут отправлять Error Frame, а тупо будут инкрементировать счетчики ошибок, пока тот не перевалится за 255, переводя ноду в Bus Off. Соответственно, весь разговор в том и только в том, что обнаружение битовых ошибок в CAN - это вещь основополагающая, и в CAN FD должны быть те же самые механизмы. А вопрос был в том, почему в рекламных всяких бумажках фигурируют вбросы типа "CAN FD speed: up to 10Mbps with the same bus length as CAN 2.0B". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 17 минут назад, Arlleex сказал: Еще раз: Вы пытаетесь мне сказать, что у Вас ни при каких обстоятельствах не бывает Error Frame на шине? Ну почему. Бывают. По таким же причинам, как всегда - шумы, наводки, КЗ, неверно сконфигурированная скорость и т.п. Но нет ошибок вызываемых протоколом обмена. Т.е. - если шина чистая, без шумов, то и ошибок нет. Хоть сколько там девайсов (в пределах нагрузочной способности шины). Цитата Есть у Вас там верхние протоколы или нету - вопрос совершенно пока что вторичный. У Вас сколько девайсов на шине? Практически и теоретически. По ТЗ: до 33-х. Практически испытывал до 6-и (больше нет плат в наличии). Цитата Вот если на шине 100 девайсов по запросу (для эксперимента это лучше) начнут швырять в шину фреймы с одинаковыми CAN-ID но разным data payload Я знаю что такое "коллизии на шине" и как работает CAN. Не надо объяснять. Поэтому спроектировал протокол энумерации так, чтобы такие ситуации не возникали. И если я говорю, что ошибок нет - значит их нет (более того: у меня в составе ПО имеется диагностика с накоплением и отображением ошибок на шине. И она сразу показывает ошибки, когда они появляются). Вы просто забыли наверное ту тему, на которую я выше ссылался. В которой я подробно излагал как собираюсь построить протокол энумерации. И как обойтись без коллизий. Всё я там описывал. Долго там шло обсуждение.... Перечитайте свою отквоченную выше фразу. И подумайте немного дальше: если так, то Как сделать чтобы можно было передавать разные данные и без коллизий? Если разные payload вызывают ошибку? В этой фразе есть ключ к ответу. Ответ очень прост. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 3 hours ago, jcxz said: Да при чём тут "коллизии данных"? Нет их. Протокол (прикладной, который ходит поверх CAN), как раз и рассчитан на то что будут (и должны быть обязательно! иначе он не будет работать) столкновения кадров с одинаковым ID. я не сварщик, а маску нашел просто интересуюсь, так как когда-то сдал достаточно серьезный проект с CAN-ом, разобравшись с ним достаточно поверхностно - гештальт остался незакрытым :) как в данных (даже если предположить, что времянка идеальная и error frame-ов нет) передающее устройство узнает, что ему не удалось передать фрейм (то есть прошел фрейм от другого устройства с доминантным битом)? ну если в ID такое происходит - то арбитраж и ретрансмит, а тут как? или все-таки то устройство (с пассивным битом) должно выставить error frame и грохнуть эту транзакцию? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 4 минуты назад, yes сказал: как в данных (даже если предположить, что времянка идеальная и error frame-ов нет) передающее устройство узнает, что ему не удалось передать фрейм (то есть прошел фрейм от другого устройства с доминантным битом)? ну если в ID такое происходит - то арбитраж и ретрансмит, а тут как? А почему вопрос ко мне? У меня же такого не происходит. Узнать об ошибках можно также как всегда - при ошибках выставляются соответствующие флажки в регистрах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 35 минут назад, jcxz сказал: Как сделать чтобы можно было передавать разные данные и без коллизий? Если разные payload вызывают ошибку? Передавать с таким ID, который гарантированно не будет задействован при передаче сообщения другим девайсом на шине. Или же, если выделить всем уникальный CAN-ID невозможно, разделить передачи по времени. Сначала один передает, потом другой, и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 24 минуты назад, Arlleex сказал: Передавать с таким ID, который гарантированно не будет задействован при передаче сообщения другим девайсом на шине. По условию (в шину включаются произвольные, ранее не сконфигурированные устройства (только скорость по CAN выставлена одинаковой и резистор подтяжки отключен), отличающиеся только заводским номером (который также может различаться в разных группах бит)) - такого ID нету. Цитата Или же, если выделить всем уникальный CAN-ID невозможно, разделить передачи по времени. Сначала один передает, потом другой, и т.д. Нет сигнала, по которому можно разделить по времени. Да даже если был - как кто-то из устройств узнает, что ему нужно выходить, а другой в это время точно не выдет? Нет. Всё гораздо проще. В протоколе энумерации я просто передаю данные в поле CAN-ID. Если брать расширенный CAN-ID, то там 29 бит. Часть бит - собственно для адресации (для выделения адресного пространства для протокола энумерации), а часть - для передачи данных протокола энумерации. У меня для передачи данных используется насколько помню 18 бит. А поле данных всегда пустое. И использую remote frames (RTR). Так что - никаких ошибок в принципе быть не может. PS: Вобщем - с поиском на этом форуме туго. Искал ту тему. Но фиг что найдёшь. Помню только, что обсуждение шло "незадолго до" или "вскоре после", того как я реализовал этот механизм в своём устройстве. А реализовывал я его в мае 2020-го. Вот только что нашлось: Но по-моему это не полностью. Я где-то здесь подробно расписывал протокол. Если не изменяет память... а в этой теме - вкратце. Arlleex, Вы кстати, как видно участвовали в том треде. Должны бы помнить... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба Ну тогда причем здесь возможность передавать CAN-кадры с одинаковыми CAN-ID но разными данными (DLC != 0) разными абонентами на шине с гарантией отсутствия Error Frame? То, что в Вашей сети таких ситуаций нет и быть не может - это лишь следствие работы Вашего протокола обмена и энумерации. Вы работаете с CAN-шиной, абоненты которой Вам, скорее всего, априори известны все. Более того, предполагаю, что у всех девайсов поддержан Ваш протокол (может, девайсы все Вашего производства). Только вот я, например, вынужден иногда цеплять свои девайсы к CAN-сети, состав оборудования которой мне может быть вообще не известен. Соответственно, я не могу реализовывать протокол/методы энумерации, похожие на Ваш. Все, что мне дают - это, например, 1 CAN-ID, с которым мой девайс должен периодически выплевывать показания датчика. Никаких диапазонов CAN-ID, никаких возможностей для локальной энумерации между своими девайсами. Понимаете? Именно поэтому я и написал Цитата Естественно, в жизни так делать не нужно (я про одинаковые ID), но и исключать возможность такого рода событий не правильно. , акцентируя внимание как раз на том, что в общем случае не всегда можно быть уверенным, что в сети не будет нескольких девайсов, которые захотят передать данные с одинаковым CAN-ID но разным содержимым поля данных. Потому что это вызовет Error Frame. А если просто стоять на том, что в рабочей сети нельзя априори допускать ситуации, описанной выше, то можно было просто выкинуть нафиг флаг Bit Error из флагов статуса CAN-контроллера и молча рушить сообщение кадром ошибки. Или делать то же самое чуть позже (когда контроллер увидит расхождение в CRC, а механизм "bit checking" в поле данных вовсе можно было бы отключить). Стандарт CAN не запрещает испускать кадры с одинаковыми CAN-ID и разным полем данных разными CAN-нодами. Он имеет возможность обнаружить такую ситуацию. 1 час назад, jcxz сказал: Arlleex, Вы кстати, как видно участвовали в том треде. Должны бы помнить... Помню, конечно Но, опять же - в начале этого поста я описал суть проблемы (то что не всегда можно "откусить" диапазон CAN-ID для реализации собственных нужд). Ваш протокол построен так (насколько я понял), что в сети вообще не может произойти ситуации, когда 2 и более девайса одновременно отправят кадр данных с одинаковым CAN-ID но разными данными (именно данными в поле данных CAN Data Frame (DLC != 0)). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 9 минут назад, Arlleex сказал: Ну тогда причем здесь возможность передавать CAN-кадры с одинаковыми CAN-ID но разными данными (DLC != 0) разными абонентами на шине с гарантией отсутствия Error Frame? То, что в Вашей сети таких ситуаций нет и быть не может - это лишь следствие работы Вашего протокола обмена и энумерации. Вы работаете с CAN-шиной, абоненты которой Вам, скорее всего, априори известны все. Более того, предполагаю, что у всех девайсов поддержан Ваш протокол (может, девайсы все Вашего производства). Да, на этой шине только наши устройства с заранее известным протоколом. Но не вижу никаких проблем запустить его и на шине, где есть чужие устройства. Ведь для него просто нужно зарезервировать несколько адресов (или даже всего один на 11-битном ID). Так ведь для любой функции на CAN нужно резервировать адрес и если у Вас на одном адресе будут 2 разные функции - будет бардак и коллизии. Вобщем - нет никаких отличий от любой другой работы на CAN. 9 минут назад, Arlleex сказал: Только вот я, например, вынужден иногда цеплять свои девайсы к CAN-сети, состав оборудования которой мне может быть вообще не известен. Соответственно, я не могу реализовывать протокол/методы энумерации, похожие на Ваш. Почему? Эти ваши устройства занимают сразу все адреса и нет ни одного свободного? 9 минут назад, Arlleex сказал: Все, что мне дают - это, например, 1 CAN-ID, с которым мой девайс должен периодически выплевывать показания датчика. Никаких диапазонов CAN-ID, У меня на шине протокол энумерации занимет всего 4 адреса 11-битного CAN. Но при желании можно было бы упихнуть и в один адрес. 9 минут назад, Arlleex сказал: Стандарт CAN не запрещает испускать кадры с одинаковыми CAN-ID и разным полем данных разными CAN-нодами. Он имеет возможность обнаружить такую ситуацию. Вообще-то мой коммент: касался вашей конкретной фразы, про то что "нельзя сообщения с одинаковым ID". И был он о кадрах с пустым или одинаковым полем данных. С пустым - можно. С одинаковым - тоже можно. А как и для чего такие кадры нужны - это дело протокола. Вот и всё. 27 минут назад, Arlleex сказал: Ваш протокол построен так (насколько я понял), что в сети вообще не может произойти ситуации, когда 2 и более девайса одновременно отправят кадр данных с одинаковым CAN-ID но разными данными (именно данными в поле данных CAN Data Frame (DLC != 0)). Да, именно так. Сперва с помощью энумерации мастер узнаёт уникальные 64-битные UID всех сидельцев на шине. А потом обмен идёт с использованием этих UID только между мастером и любым из ведомых: Широковещательно всем рассылается мульти-сообщение, состоящее из множества CAN-сообщений. Все ведомые его принимают. А отвечает только один, таким же ответным мульти-сообщением. Здесь уже используются одни и те же CAN-ID (для передачи мульти-сообщений мастер-слэйв и обратно), но с временнЫм разделением: ни один слэйв по своей инициативе не выходит на связь, только мастер, а слэйвы выходят только в ответ на запросы мастера, в жёстко ограниченном временнОм окне после запроса мастера. Т.е. - опять никаких коллизий по данным не может быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Captain777 0 8 февраля, 2022 Опубликовано 8 февраля, 2022 (изменено) · Жалоба Я подключался на живом автомобиле к FD CAN. Там одновременно сосуществуют посылки стандартные и FD. Никто никому не мешает. FD принимает весь трафик, стандартный только стандартные посылки. Друг другу они не мешают. PS. Кому интересно - могу лог скинуть. Изменено 8 февраля, 2022 пользователем Captain777 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 180 8 февраля, 2022 Опубликовано 8 февраля, 2022 · Жалоба 44 минуты назад, jcxz сказал: Почему? Эти ваши устройства занимают сразу все адреса и нет ни одного свободного? Нет, конечно же. Мне по ТЗ, допустим, положено сколько-то CAN-ID для обозначения вполне конкретных данных. Допустим, выделяют 3 разных CAN-ID для выдачи моим устройством сообщений о состоянии датчиков 1, 2 и 3. И также выделяют 1 CAN-ID, чтобы мой девайс при приеме кадра с этим ID незамедлительно отправлял 3 кадра данных с датчиков. А в это время в другой конторе некий условный Петя делает другую железку с похожим функционалом и такой же диаграммой запросов/ответов. И с Петей мы должны в итоге подключить наши железки к одному "мастеру", тот выдает запрос, наши девайсы выплевывают показания датчиков. Только вот Петя CAN-ID свои рабочие не поправил и они частично или полностью совпали с моими. Через мгновение чей-то девайс в Bus Off (или оба сразу). Вот поэтому я и говорю, что "bit checking" должен быть не только в поле данных CAN 2.0B (в поле арбитража итак понятно), но и аналогично у CAN FD. Иначе какой смысл в Bit Error? 16 минут назад, Captain777 сказал: Друг другу они не мешают. CAN FD, как одним из пунктиков при разработке, и был продуман так, чтобы иметь определенную совместимость с сетями CAN 2.0B. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться