[参考译文] TCAN4550-Q1：在 CAN 消息传输中观察到延迟

尊敬的 Jonathan：

是的、这是关于吞吐量问题、比如当我们执行单个 CAN 传输时、我们得到大约7.5k 毫秒/秒、但如果我们执行2个 CAN 同时传输、我们得到大约4K 毫秒/秒的每一个 CAN、但我们希望在这种情况下都有7.5k。

此外、我们进行了 SPI 开发测试、以在未连接任何 CAN 收发器的情况下单独检查 SPI 的性能、我们发现单次 SPI 传输和两次 SPI 同时传输期间的时序是相同的、因此对于这种同时情况、SPI 具有传输这些数据的能力、这是在单次传输中完成的。 另外、在我们的处理器方面询问这种情况时、他们会说这取决于驱动程序的设计、能够处理多个器件。

那么、您是否可以提出任何建议来帮助我们解决此问题？

谢谢！

此致、

Ankita

您好 Ankita、

虽然您尚未直接确认这一点、但处理器似乎一次只能通过 SPI 为一个 TCAN4550提供服务。  如果单个设备可以传输7.5k 毫秒/秒、而添加第二个设备时两个设备的总合并毫秒/秒大致相同、并且每个设备的消息计数约为消息计数的一半。

为了更大限度地提高 CAN 消息吞吐量、您需要优化 SPI 通信并尽可能减少空闲时间和不必要的位。

• 最大化 SPI 比特率可减少位周期并缩短每个 SPI 事务的总时间
• 尽可能使用多字 SPI 读取/写入事务来减少32位字 SPI 标头的数量(读取/写入操作码+地址+长度)
• 缩短 SPI 事务之间的空闲时间
• 减少或消除 SPI 事务中的任何空闲时间。
  • 片选下降低电平与 SCLK/数据开始之间的时间
  • 最后一个 SCLK/数据位和片选上升高电平之间的时间
  • 在来自处理器或驱动程序的 SCLK/Data 部分中的任何时间、都只能一次处理减少的位数(例如8或16位)。  TCAN4550以32位字运行、每个 SPI 事务至少为64位
• 消除任何不必要的 SPI 寄存器或 MRAM 活动。  使用您需要的功能、但消除您不需要的功能。  例如、如果您实际上没有使用 TX 事件 FIFO 来跟踪发送的消息、则不要将其配置为使用、否则只需要额外的 SPI 活动来处理和处理此 FIFO 及其相关的任何中断。 等
• 使用多字 SPI 读取/写入特性还允许在单个极长 SPI 事务中处理连续存储器中的多个 CAN 消息 RX/TX 缓冲器。  例如、设置 RX FIFO 水线位将使您能够一次读取多个 RX 消息缓冲区、然后发出单个 SPI 写入命令来确认所有消息都已被读取、而不是单独读取和确认每条 RX 消息。

我希望这些对于如何优化性能是有益的建议。

此致、

Jonathan

您好、

Tao Pei 说：

f 单个设备可以传输7.5k msg/秒、添加第二个设备时、两个设备的总合并 msg/秒大致相同、每个设备的消息数大约为一半。

这是否意味着无论单个 CAN 吞吐量是什么、如果我们添加另一个 CAN、两个 CAN 会给出单个 CAN 给出的结果、而在每个 CAN 中都是一半？

此致、

Ankita

不、我只是查看您的数字、了解您报告处理器的功能。  TCAN4550彼此独立运行、只要处理器将消息加载到 TX 缓冲区元素中并设置 TXBAR 寄存器中的相应位以发起传输、就会根据仲裁规则在 CAN 总线上发送消息。

可能有两个限制因素：

1. 处理器可能无法通过单独的 SPI 接口以全速率为两个 TCAN4550器件提供服务、这可能会导致每个 TCAN4550器件的总体 CAN 消息吞吐量降低。
2. CAN 总线负载可能开始饱和、仲裁规则可能开始限制每个 TCAN4550可以发送的消息总数、因为它现在必须与额外的 TCAN4550器件进行仲裁、也尝试同时在总线上发送。

我无法明确说明您的处理器、但一般来说、两个 TCAN4550将使处理器所需的工作量加倍、并可能导致 CAN 消息吞吐量降低。

同样、添加第二个 TCAN4550并期望其也传输7.5k msg/秒意味着 CAN 总线需要支持15k msg/秒、否则 CAN 协议将成为限制因素。  可支持的 CAN 消息的最大数量将随每条消息的比特率和数据长度字段而变化。  您的 CAN 总线是否有足够的带宽或裕度来支持15k msg/sec？  如果不是、这可能是因为您为每个 TCAN4550器件降低了毫秒/秒的速率。

此致、

Jonathan