[FAQ] [参考译文] 【常见问题解答】AM2634：以最短的 CS 置为无效时间从 AM263x SPI 从器件发送大量数据

admin

Other Parts Discussed in Thread: SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1618756/faq-am2634-sending-large-amounts-of-data-from-an-am263x-spi-slave-with-minimal-cs-deassertion-time

器件型号： AM2634
主题： SysConfig 中讨论的其他器件

在本常见问题解答中、我将介绍一种方法、在保持片选 (CS) 置为无效时间最短的情况下、从 AM263x SPI 从器件传输大量数据。

3 个月前

0 admin 3 个月前

TI__Guru**** 2774745 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

问题说明：

请考虑 SPI 主器件和 SPI 从器件之间的典型命令响应通信模型。假设主器件发送命令并预期相应响应之间的延迟非常小、约为几微秒。

在这种情况下、从动器件很难：

在主器件启动响应接收之前、准备响应数据并调用 MCSPI_LLD_READWRITE () API。因此、从器件可能未及时就绪、从而导致时序违规或数据传输无效。

我在一个内部工程中遇到了这一要求、因为时间限制非常严格、只留下很少的裕度。

实施的方法（非常规但有效）：

为了解决这一问题、我采取了一种非常规但实际的做法：

我从从从器件端主动调用 MCSPI_LLD_readwrite () API、从而提前有效地启动 SPI 通信。
启动通信后、我修改了已传递到读写 API 的 TX 缓冲区内容、假设更新的数据将传输到主器件。

这种方法显著减少了从器件侧的响应准备时间、并有助于满足严格的时序要求。

发现的问题

通过这种方法、我观察到：
主器件仅从第 32 个字节开始接收到有效数据。
前 32 个字节已损坏或包含过时的数据。

根本原因分析：
在进行详细的调试后、已确定根本原因如下：
每个 MCSPI 实例都有一个具有 64 帧的内部 FIFO。
此 FIFO 被平均分配：
TX 需要 32 个帧
RX 32 个帧
调用 MCSPI_LLD_READWRITE () 时、TX FIFO 会立即用 TX 缓冲区的前 32 个字节填充（与 SysConfig 中配置的触发电平无关）。
API 调用后对 TX 缓冲区所做的任何修改都不会反映在已填充的 FIFO 中。
因此、主器件接收到前 32 个字节的过时数据、只有 FIFO 耗尽后传输的数据才反映更新的 TX 缓冲区内容。

解决方案：
解决方案是禁用内部 MCSPI FIFO、以便直接从 TX 缓冲区中提取数据、而不是预加载到硬件 FIFO 中。
遗憾的是、SysConfig 中没有直接用于禁用 MCSPI FIFO 的选项。因此、需要对驱动器级进行小幅修改：
在 MCSPI_setPeripheralFifoConfig () API 中：
注释掉启用 TX FIFO 和 RX FIFO 的两行。

这些线路负责启用两侧的 FIFO 操作、禁用这些线路可防止硬件预加载过时的 TX 数据。
结果
进行此修改后：
我能够将大量数据从 SPI 从器件传输到主器件。
数据准备时间显著缩短。
在前 32 个字节中观察到的损坏被完全消除。
使用
有关更多详细信息、请参阅随附的 SPI 主从示例工程、这些工程演示了此行为和所需的驱动程序更改。

为了执行该测试、我在 AM263x 板中取了 MCSPI 外部环回示例。在这里、我们取 msg 大小为 400 字节、并且 CMD 和 MSG 之间的 CS 置为无效时间仅为 5us：