[jcxz 184]

22 часа назад, Arlleex сказал:

Естественно, в жизни так делать не нужно (я про одинаковые ID)

Почему? У меня в рабочем проекте есть такие передачи (обычный CAN, не FD). И даже много. Не вижу причин почему так нельзя делать.

[Arlleex 131]

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

Не вижу причин почему так нельзя делать.

Смотря насколько сильно загружена шина сообщениями с одинаковыми ID от разных абонентов. Если не сильно или обмен спроектирован по какой-то временной диаграмме, где сообщения теоретически пересекаться по времени не должны, то проблем нет. Иначе же возможны коллизии в данных, с соответствующими разрушающими Error Frame и т.д. И чем чаще столкновения, тем больше этих Error Frame будет на шине. Чисто в теории можно настолько сильно забить шину, что некоторые узлы отвалятся в Bus Off, когда счетчик ошибок будет увеличиваться быстрее, чем уменьшаться успешной транзакцией.

Не говорю, что вот прямо строго нельзя. Можно, но с определенными допущениями.

[jcxz 184]

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

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

Да при чём тут "коллизии данных"? Нет их. Протокол (прикладной, который ходит поверх CAN), как раз и рассчитан на то что будут (и должны быть обязательно! иначе он не будет работать) столкновения кадров с одинаковым ID. Именно на этих столкновениях основана работа протокола. В той теме, про арбитраж CAN, которая была тут пару лет назад, я как раз описывал как и зачем нужны такие кадры. Тогда это были планы по реализации, а сейчас - это уже давно реализовано и работает.

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

[Arlleex 131]

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

И ошибок на шине нет ни одной, при работе этого протокола.

Значит после энумерации у Вас нет узлов, которые в рабочем режиме имеют одинаковые CAN-ID на передачу.

[jcxz 184]

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

Значит после энумерации у Вас нет узлов, которые в рабочем режиме имеют одинаковые CAN-ID на передачу.

Нету "после" и "до". Нет "рабочего режима" и какого-то другого. Всё работает одновременно. Энумерация происходит непрерывно, циклически, всё время пока на шине присутствует "мастер энумерации". Давая возможность интерактивно в реальном времени обнаруживать вновь подключившиеся и отключившиеся устройства. Процесс энумерации идёт в одно и то же время с остальными процессами. Как например по Ethernet одновременно и не мешая друг другу ходят множество разных протоколов, так у меня по CAN - множество процессов/протоколов работают одновременно. Для энумерации просто выделен свой диапазон адресов, в котором она работает. Просто есть множество устройств на шине с уникальными 64-битными ID (заводские номера). Заранее не известными. И в какой-то момент, одно из этих устройств решает что оно "мастер". И запускает процесс энумерации. И продолжает его циклически до тех пор, пока считает себя мастером.

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

[Arlleex 131]

Еще раз: Вы пытаетесь мне сказать, что у Вас ни при каких обстоятельствах не бывает 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 184]

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

Еще раз: Вы пытаетесь мне сказать, что у Вас ни при каких обстоятельствах не бывает Error Frame на шине?

Ну почему. Бывают. По таким же причинам, как всегда - шумы, наводки, КЗ, неверно сконфигурированная скорость и т.п. Но нет ошибок вызываемых протоколом обмена. Т.е. - если шина чистая, без шумов, то и ошибок нет. Хоть сколько там девайсов (в пределах нагрузочной способности шины).

Цитата

Есть у Вас там верхние протоколы или нету - вопрос совершенно пока что вторичный. У Вас сколько девайсов на шине? Практически и теоретически.

По ТЗ: до 33-х. Практически испытывал до 6-и (больше нет плат в наличии).

Цитата

Вот если на шине 100 девайсов по запросу (для эксперимента это лучше) начнут швырять в шину фреймы с одинаковыми CAN-ID но разным data payload

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

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

Перечитайте свою отквоченную выше фразу. И подумайте немного дальше: если так, то Как сделать чтобы можно было передавать разные данные и без коллизий? Если разные payload вызывают ошибку? В этой фразе есть ключ к ответу. Ответ очень прост.    

[yes 5]

3 hours ago, jcxz said:

Да при чём тут "коллизии данных"? Нет их. Протокол (прикладной, который ходит поверх CAN), как раз и рассчитан на то что будут (и должны быть обязательно! иначе он не будет работать) столкновения кадров с одинаковым ID.

я не сварщик, а маску нашел

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

как в данных (даже если предположить, что времянка идеальная и error frame-ов нет) передающее устройство узнает, что ему не удалось передать фрейм (то есть прошел фрейм от другого устройства с доминантным битом)?

ну если в ID такое происходит - то арбитраж и ретрансмит, а тут как?

или все-таки то устройство (с пассивным битом) должно выставить error frame и грохнуть эту транзакцию?

[jcxz 184]

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

как в данных (даже если предположить, что времянка идеальная и error frame-ов нет) передающее устройство узнает, что ему не удалось передать фрейм (то есть прошел фрейм от другого устройства с доминантным битом)?

ну если в ID такое происходит - то арбитраж и ретрансмит, а тут как?

А почему вопрос ко мне? У меня же такого не происходит.

Узнать об ошибках можно также как всегда  - при ошибках выставляются соответствующие флажки в регистрах.

[Arlleex 131]

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

 Как сделать чтобы можно было передавать разные данные и без коллизий? Если разные payload вызывают ошибку?

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

[jcxz 184]

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

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

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

Цитата

Или же, если выделить всем уникальный CAN-ID невозможно, разделить передачи по времени. Сначала один передает, потом другой, и т.д.

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

 

Нет. Всё гораздо проще. В протоколе энумерации я просто передаю данные в поле CAN-ID. Если брать расширенный CAN-ID, то там 29 бит. Часть бит - собственно для адресации (для выделения адресного пространства для протокола энумерации), а часть - для передачи данных протокола энумерации. У меня для передачи данных используется насколько помню 18 бит. А поле данных всегда пустое.

И использую remote frames (RTR).

Так что - никаких ошибок в принципе быть не может.

 

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

Вот только что нашлось: 

 

Но по-моему это не полностью. Я где-то здесь подробно расписывал протокол. Если не изменяет память... а в этой теме - вкратце.

Arlleex, Вы кстати, как видно участвовали в том треде. Должны бы помнить...  

[Arlleex 131]

Ну тогда причем здесь возможность передавать 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 184]

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]

Я подключался на живом автомобиле к FD CAN. Там одновременно сосуществуют посылки стандартные и FD. Никто никому не мешает. FD принимает весь трафик, стандартный только стандартные посылки. Друг другу они не мешают.

PS. Кому интересно - могу лог скинуть.

Изменено 8 февраля, 2022 пользователем Captain777

[Arlleex 131]

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.