[参考译文] TCAN4550：TCAN4550 最大帧速率查询和测试结果

您好 Joe、

与 TCAN4550 的所有通信都是通过 SPI 总线进行的、因此、在确定可支持的最大 CAN 总线吞吐量时、它将成为总体限制因素。  需要考虑几个因素：

• 处理（发送或接收）来自 TCAN4550 MRAM 缓冲区空间的 CAN 消息并读取/写入任何所需的寄存器以发起消息发送或确认已接收消息等所需的总时间  SPI 速度、SPI 事务之间的空闲时间等需要针对每个应用确定、并且特定于处理器/固件。
• 需要通过 SPI 总线为每个 CAN 消息传输的数据量
• CAN 消息的比特率、决定了每个位的时间量（位周期）
• RX 和 TX FIFO、队列和缓冲区配置、以及在消息数据丢失之前可以在存储器中保存多少条消息。
• CAN 总线上的消息优先级状态、尤其是在高总线负载下、由于 CAN 总线仲裁协议、这些负载可能导致消息传输延迟。
• 等
• 由于 MCU 固件执行其他操作、SPI 读取/写入事务之间的空闲时间。  （SPI 总线效率）
• SPI 数据包内的空闲时间、例如 CS 下降低电平与时钟/数据开始之间的时间、数据位内数据字节或字之间的任何空闲时间、以及时钟/数据结束与 CS 信号再次拉高之间的时间。  该器件使用 32 位数据字、但 SPI 驱动程序可能一次仅支持 8 或 16 位、从而使整个数据包具有较小的时间延迟。

通常、SPI 通信所需的时间比实际的 CAN 消息传输所需的时间更长、因此不太可能支持 100%的 CAN 总线负载。  但是、如果 100%加载的时间很短、那么具有足够大的 RX FIFO 就可以将消息存储到存储器中。  只要 CAN 消息的总数小于通过 SPI 处理这些消息所需的时间、就不会出现问题。   

但是、如果 CAN 消息到达速度快于 MCU 通过 SPI 处理它们的速度、则会导致溢出情况、并且 CAN 消息数据将丢失。  同样、由于将消息加载到 MRAM 缓冲区并通过 SPI 写入启动发送所需的时间、发送路径可能会受到限制。

同时发送和接收 CAN 消息也会使 RX 和 TX 缓冲器之间的 SPI 总线分时。   

处理器控制 SPI 通信、因此结果可能会有所不同、最好通过使用逻辑分析仪或其他方法监控 SPI 通信来测量完成一个完整的发送和接收 CAN 消息所需的时间、以确定检测新消息到达（中断或寄存器读取）所需的时间读取 RX FIFO 状态寄存器以确定缓冲区位置、计算或查找 MRAM 地址、 读取数据、然后确认已读取缓冲区、以清除该缓冲区并使用新消息再次使用。  同样、将消息写入 TX 缓冲区所需的时间、设置该消息的 TXBAR 位等

此致、

Jonathan

您好 Joe、

该驱动程序有两个版本、您在使用内核 5.10 时使用初始版本进行测试、在使用内核 6.1 时使用修订版本进行测试。   

我的专业知识是 TCAN4550、而不是 Linux、或者首先包含修订版驱动程序的内核版本、但为了获得出色性能、我建议使用较新版本。

TCAN4550 SPI 协议在单个 SPI 读取/写入事务中支持多个数据字。  标头字包含一个长度字段、用于指示器件在此事务中应等待多少个 32 位数据字、如果大于 1、则地址是起始地址、器件会从标头中给定的地址开始将所有数据返回或写入存储器或寄存器。

初始 SPI 驱动器仅使用单字 SPI 读取/写入事务、该事务对于单个寄存器读取/写入是正常的、但在将大量 RX/TX 消息数据传递到 MRAM 缓冲区和从 MRAM 缓冲区流出时无法实现高效。  每个消息数据字都需要一个新的地址标头字和一个片选线路的切换、这为整个过程增加了额外的时间。

对驱动程序进行了修订、以尽可能优化 SPI 吞吐量并减少发送和接收 CAN 消息所需的总时间。  这涉及更改 SPI 驱动程序、以便在可能的情况下使用多字读取/写入支持、并消除驱动程序中存在的任何其他进程低效率问题。  此修订后的驱动程序随后被上传到内核中、并且可能是您在 6.1 中看到的版本、这就是您看到性能提高的原因。

您可以在以下文档中找到有关该器件以及 MCAN 配置和操作的更多信息。

TCAN45xx 软件用户指南 （链接）

MCAN 用户手册 （链接）

此致、

Jonathan