Утилита Candump не печатает лидирующие нули для длины данных на не-FD кадрах?

Question

Я пишу драйвер CAN и хочу настроить некоторые тесты для него. У меня есть простая программа эхо (принимает банку кадра и возвращает его обратно). я использую can-utils для этого и будет использовать cangen чтобы сгенерировать случайные данные, зарегистрируйте их, затем убедитесь, что кадры были получены и возвращены.

Кажется, что все работает, но от Candump есть какое-то раздражающее поведение. При отправке не-FD кадров он не печатает начальный ноль для DLC. Смотрите здесь (сообщения отправляются, а затем отображается сообщение - да, я знаю, что не следует использовать тот же идентификатор узла, чтобы повторить это, только для целей тестирования):

candump can0
#can FD frames (11 and 29 bit ids)
  can0  033FABCD  [04]  DE AD BE EF #sent
  can0  033FABCD  [04]  DE AD BE EF #echoed
  can0       277  [04]  DE AD BE EF
  can0       277  [04]  DE AD BE EF
#non-FD frames sent (11 and 29 bit ids)
  can0       277   [4]  DE AD BE EF #sent
  can0       277  [04]  DE AD BE EF #echoed
  can0  077AFFFF   [4]  DE AD BE EF
  can0  077AFFFF  [04]  DE AD BE EF

И FD, и не-FD кадры имеют 4-битный DLC, поэтому я не уверен, почему он будет напечатан по-разному. Мы отправляем только FD, поэтому отраженный кадр имеет формат FD и печатается начальный ноль.

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

Answer 1

Нет, это намеренно различать классические кадры CAN [x] и CAN FD [xx] в удобочитаемом выводе. Вопрос не в том, будет ли DLC (4 бита на физическом уровне) одинаковым, поскольку мы всегда работаем с информацией о реальной длине, а не с DLC на уровне сокетов. И когда оба имеют 5 байтов, вы не сможете их различить.

Btw. Ваш драйвер CAN, похоже, имеет проблему, когда эхо-кадр всегда имеет тип CAN FD - независимо от того, что было отправлено (Classic CAN / CAN FD) ...