jcxz 184 29 мая, 2020 Опубликовано 29 мая, 2020 · Жалоба Имеем обычный CAN (не CAN-FD). Судя по разным описаниям поле DLC кадра может содержать значения в диапазоне 0...8. Также кое где встречал упоминания, что при прочих значениях DLC длина кадра считается == 8. Но не очень понятно: допустимо ли по стандарту в этом поле передавать значения >8 ? Попробовал (XMC4700) - значения >8 в DLC нормально передаются (вижу лог.анализатором) и нормально принимаются удалённой стороной. USB снифер показывает, что передаются совершенно нормальные кадры длиной ==8 байт. Так получается значит - можно? Или есть какие-то расширения стандарта, с которыми может быть конфликт? PS: Лишние 3 бита для данных в коротком CAN-кадре часто были бы весьма полезны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrew_Q 0 1 июня, 2020 Опубликовано 1 июня, 2020 (изменено) · Жалоба Из Wiki. It is physically possible for a value between 9–15 to be transmitted in the 4-bit DLC, although the data is still limited to eight bytes. Certain controllers allow the transmission or reception of a DLC greater than eight, but the actual data length is always limited to eight bytes. Ключевое слово: некоторые контроллеры допускают передачу. Изменено 1 июня, 2020 пользователем Andrew_Q Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 1 июня, 2020 Опубликовано 1 июня, 2020 · Жалоба Значит по идее на этих "некоторых контроллерах" можно сиё использовать. И не будет конфликтов с какими-то стандартами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 1 июня, 2020 Опубликовано 1 июня, 2020 · Жалоба Ну если вы только между "своими некоторыми контроллерами" связь держите, то под вашу ответственность можно. А если кто-то со стороны в вашей сети присутствует, или вы в чужую сеть входите - то лучше не рисковать. И c CAN FD могут возникнуть проблемы. Там это поле по полной используется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба On 5/29/2020 at 1:48 PM, jcxz said: PS: Лишние 3 бита для данных в коротком CAN-кадре часто были бы весьма полезны. а чем не устраивает использование длинного ID (29 vs 11 bit) для передачи пользовательской инфы на кадрах без данных? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба 6 минут назад, Doka сказал: а чем не устраивает использование длинного ID (29 vs 11 bit) для передачи пользовательской инфы на кадрах без данных? И длинные и короткие ID - используются. Вопрос был ближе к теоретической возможности экономии полосы пропускания - передать больше полезных бит на той же бодовой скорости. Как резерв на будущее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба On 5/29/2020 at 1:48 PM, jcxz said: Попробовал (XMC4700) - значения >8 в DLC нормально передаются (вижу лог.анализатором) и нормально принимаются удалённой стороной. USB снифер показывает, что передаются совершенно нормальные кадры длиной ==8 байт. очень сильно зависит от реализации IP-core CAN ctrl, даже может на разных ревизиях кремния одного и того же партнамбера поведение отличаться. т.е. ничто не мешает разработчику закодировать case в RTL так чтобы при записи в регистр длины значения >= 8, в DLC принудительно 8 записывалась также, если явно не указано в ISO стандарте на CAN, хорошим референсом может служить другой ISO - CAN conformance test suite, где расписан набор тестов, который должен пройти каждый новый кастомный контроллер CAN. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба On 6/1/2020 at 12:18 PM, Edit2007 said: А если кто-то со стороны в вашей сети присутствует, или вы в чужую сеть входите - то лучше не рисковать. есть немного потеоритизировать, то некоторые реализации контроллеров вполне могут (и имеют право) выставлять кадр ошибки при приеме DLC>8 (разработчики могут пожелать включить эту ситуацию в обработчик Form Error, например) ---- ЗЫЖ говорю это по опыту того, когда писали свой CAN с блекджеком и ТТ фичулями, многие моменты приходилось проговаривать с верификаторами: то, что не было явно прописано в спеке, надо было утвердить детерминированное поведение нашего ядра и внести в документацию на ядро. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба 28 минут назад, Doka сказал: очень сильно зависит от реализации IP-core CAN ctrl, даже может на разных ревизиях кремния одного и того же партнамбера поведение отличаться. Это настораживает... 10 минут назад, Doka сказал: есть немного потеоритизировать, то некоторые реализации контроллеров вполне могут (и имеют право) выставлять кадр ошибки при приеме DLC>8 (разработчики могут пожелать включить эту ситуацию в обработчик Form Error, например) Сеть у нас - внутренняя, в которой присутствуют исключительно только наши устройства на одном и том же МК. И протокол (поверх CAN) - свой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 13 июля, 2020 Опубликовано 13 июля, 2020 · Жалоба 3 minutes ago, jcxz said: Сеть у нас - внутренняя, в которой присутствуют исключительно только наши устройства на одном и том же МК. И протокол (поверх CAN) - свой. тогда можно отбросить сомнения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
