Jump to content
    

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Цитата

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

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

Цитата

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

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

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

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

Share this post


Link to post
Share on other sites

3 hours ago, jcxz said:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Цитата

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

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

 

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

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

Ну тогда причем здесь возможность передавать 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, Вы кстати, как видно участвовали в том треде. Должны бы помнить...

Помню, конечно:smile: Но, опять же - в начале этого поста я описал суть проблемы (то что не всегда можно "откусить" диапазон CAN-ID для реализации собственных нужд). Ваш протокол построен так (насколько я понял), что в сети вообще не может произойти ситуации, когда 2 и более девайса одновременно отправят кадр данных с одинаковым CAN-ID но разными данными (именно данными в поле данных CAN Data Frame (DLC != 0)).

Share this post


Link to post
Share on other sites

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

Ну тогда причем здесь возможность передавать CAN-кадры с одинаковыми CAN-ID но разными данными (DLC != 0) разными абонентами на шине с гарантией отсутствия Error Frame? То, что в Вашей сети таких ситуаций нет и быть не может - это лишь следствие работы Вашего протокола обмена и энумерации. Вы работаете с CAN-шиной, абоненты которой Вам, скорее всего, априори известны все. Более того, предполагаю, что у всех девайсов поддержан Ваш протокол (может, девайсы все Вашего производства).

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

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

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

Почему? Эти ваши устройства занимают сразу все адреса и нет ни одного свободного?  :shok:

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

Все, что мне дают - это, например, 1 CAN-ID, с которым мой девайс должен периодически выплевывать показания датчика. Никаких диапазонов CAN-ID,

У меня на шине протокол энумерации занимет всего 4 адреса 11-битного CAN. Но при желании можно было бы упихнуть и в один адрес. :wink:

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

Стандарт CAN не запрещает испускать кадры с одинаковыми CAN-ID и разным полем данных разными CAN-нодами. Он имеет возможность обнаружить такую ситуацию.

Вообще-то мой коммент: 

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

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

Ваш протокол построен так (насколько я понял), что в сети вообще не может произойти ситуации, когда 2 и более девайса одновременно отправят кадр данных с одинаковым CAN-ID но разными данными (именно данными в поле данных CAN Data Frame (DLC != 0)).

Да, именно так.

Сперва с помощью энумерации мастер узнаёт уникальные 64-битные UID всех сидельцев на шине. А потом обмен идёт с использованием этих UID только между мастером и любым из ведомых: Широковещательно всем рассылается мульти-сообщение, состоящее из множества CAN-сообщений. Все ведомые его принимают. А отвечает только один, таким же ответным мульти-сообщением. Здесь уже используются одни и те же CAN-ID (для передачи мульти-сообщений мастер-слэйв и обратно), но с временнЫм разделением: ни один слэйв по своей инициативе не выходит на связь, только мастер, а слэйвы выходят только в ответ на запросы мастера, в жёстко ограниченном временнОм окне после запроса мастера. Т.е. - опять никаких коллизий по данным не может быть.

Share this post


Link to post
Share on other sites

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

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

Edited by Captain777

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...