0

我正在编写一个 CAN 驱动程序并想为它设置一些测试。我有一个简单的回显程序（接受一个罐头框架并将其回显）。我正在使用can-utils它，并将用于cangen生成随机数据，记录它，然后确保接收到帧并回显。

一切似乎都在工作，但 candump 有一些令人讨厌的行为。发送非 FD 帧时，它不会为 DLC 打印前导零。请参阅此处（发送消息，然后回显消息 - 是的，我知道它不应该使用相同的节点 ID 回显，这仅用于测试目的）：

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 格式并打印前导零。

显然我可以解决这个问题，但这种行为有点烦人。有谁知道这里可能出了什么问题？

4

1 回答 1

1

不，这是有意区分人类可读输出中的经典 CAN [x] 和 CAN FD [xx] 帧。DLC（物理层上的 4 位）是否相同不是问题，因为我们总是使用真实长度信息而不是套接字级别的 DLC。当两者都是 5 个字节时，您将无法区分它们。

顺便提一句。您的 CAN 驱动程序似乎有问题，当回显帧始终是 CAN FD 类型时 - 无论已发送什么（经典 CAN / CAN FD）...

于 2019-08-26T08:03:56.840 回答