根据 Olin Lathrop 的建议，我将扩展位填充。

CAN 使用 NRZ 编码，因此对长时间运行的 1 或 0 不满意（它失去了对时钟边缘应该在哪里的跟踪）。它通过位填充解决了这个潜在的问题。发送时，如果遇到连续 5 个 1 或 0，则插入另一个极性的位，接收时，如果遇到 5 个连续 1 或 0，则忽略后续位（除非该位与前一个相同位，在这种情况下，它会发出错误标志）。

如果您为测试数据发送全零或全一，则 64 个相同位的字符串将导致插入 12 个填充位。这会将总帧长度增加到 140 位，最佳情况下的帧速率为 874 帧/秒。如果数据位与 CRC 的 MSB 相同，您将在那里获得另一个填充位，并且帧速率下降到 868 帧/秒。如果 CRC 长时间运行 1 或 0，则会进一步降低帧速率。同样的考虑也适用于您的标识符。

总共 16 个填充位将产生 850.3 帧/秒的理想帧速率，因此您应该考虑一下。一个快速的测试是使用具有交替位的测试数据，看看你的帧速率会发生什么。

您可以构建的最小 2.0a（标准）帧是 47 位...您可以构建的最小 2.0b（扩展）帧是 67 位...包括 3 位帧间距，不包括位填充...理论上我们可以建造一个永远不会塞满的框架；实际上，位填充会发生很多！

CANBus 2.0a/b 的最大波特率为 1Mbit。
在 1Mb/S 时，单个（显性/隐性）位的长度为 1uS，即。0.000'001 S
因此，一个 67 位帧 [最小的理论2.0b 帧] 将需要 67uS 来传输 - 在另一个（67 位）帧可能被传输之前。
1'000'000 / 67 给出 14,925 个完整帧（+ 下一帧的 25 位）

当您以该速度的 1/8 运行时，您最多可以获得 1/8 的数据包
14'925 / 8 = 1'865 帧/秒 @125Kb

当您使用所有 64 位（8 字节）数据时，假设您没有通过连续 1 或 0 的字符串触发位填充“错误”
1'000'000 / (67 + 64) = 7'633
7' 633 / 8 = 954

这也是假设你的接线是完美的。您的 CAN 总线是否由 120 欧姆 UTP 电缆制成并在两端进行电容去耦？或者是一些随机线，一端有一个 120 欧姆的电阻？

总的来说，我会说你做得很好，可以获得理论最大吞吐量的 90%。

Olin 对位填充以及如何对理论 CAN 吞吐量产生不利影响的描述是正确的。可以进一步降低实际吞吐量的另一件事是延迟。即使您的 CAN 控制器能够实现 100% 的总线利用率，主处理器也可能无法以该速率处理 Tx 和/或 Rx。这可能是处理器速度慢和/或实现 CAN 堆栈的固件效率低下的结果。

从接收者的角度来看，另一个有趣的问题是

最坏情况下的最大帧传输频率是多少？

对于这种情况，可能会忽略填充位，因为它们会使频率降低。

.

只看标准标识符框架：

对于数据长度 1，您必须计算

55 位（最小开销 + 8 个数据位 + 3 个接口空间）

--> 1 Mbit 的最大帧频率约为18181.8/s (1/0.000055)

对于数据长度 0（也可以是信息），您必须使用

47 位（最小开销 + 3 个接口空间）

--> 1 Mbit 的最大帧频率约为21276.6/s (1/0.000047)