[参考译文] DRA821U：GPIO 输出值更改/MCSPI 配置性能

您好的团队、  

有任何更新吗？

-卢克

您好 Junbok、

他们使用示波器和其他一些工具(如 VxWorks 系统查看器)测量了延迟。

我必须强调的是、他们的 SPI 没有问题、它工作正常。 它们的开销有问题。 访问控制和状态寄存器需要很多时间。 例如、包括 CS ON 和 CS OFF 在内的整个过程大约需要8-9us、而 SPI 传输只需要2.5us (32位传输12.5MHz)。

也存在 GPIO 问题。 例如、他们有一个使用 JTAG 协议的英特尔卡塞播放器代码。 播放器控制连接到 JTAG 时钟和数据线的 GPIO 引脚。 当他们在旧芯片上使用此代码时、该过程花费的时间几乎减少了两倍。

此致、

Luke

您好的团队、

我知道可能有许多请求、但我们能否获得一些反馈、了解导致上述功能的原因？  
-卢克

Luke、  

我将向 SPI 专家请教一些有关分析 SPI 初始化延迟的帮助信息。

Junbok、

谢谢、但 这里真正关心的是切换 GPIO 引脚的时间量。 他们修改了 GPIO 驱动程序、以便仅在状态发生变化时访问 GPIO 引脚。 这在某种程度上掩盖了问题、但实际上并没有什么帮助。

此致、

Luke

您好：

事件 CPU 内核 和 软件 用于控制 GPIO 吗？   这是 Linux、FreeRTOS 还是其他系统？  似乎很可能正在使用的软件栈可能会增加开销和/或正在使用的 CPU 可能无法完全计时。  所有内核都提供 JTAG 工具可以使用的硬件跟踪功能。 只需简单地"逐步"执行 GPIO 切换 C/C++函数、即可完整跟踪所执行的所有指令及其完成时间。   在描述的例子中、您可能会由于软件开销而看到许多意外的指令正在执行。  

在对 GPIO 进行读写的情况下、Junbok 提到 IO 空间的往返时间(启动请求、数据、响应)"触摸"花费~300nS。  如果您的代码对未缓存的 IO 地址进行多次访问、那么在1uS 的时间内累积指令似乎不难相信。  "重磅"GPIO 库可能会读取块以确保其已启用、然后读取/写入以设置 GPIO 方向、再读取(要获取当前值、请应用掩码)、然后写出值。   ETM 跟踪"完全"发生的事情将会显示正在发生的事情。 如果是 A72、CPU 可能能够从本地缓存中淘汰许多@2GHz 的指令、但如果它通过总线并与可能正在运行20MHz (甚至重新同步到32KHz 去抖)的 IO 块通信、则根据设计、它需要更长的时间。

使用的软件、实际指令数以及"where"和相对时钟速度(源<->互连<->模块)都很重要。