[参考译文] RTOS/AM5728：IPU 上的 GPIO 中断延迟

你好。

我可以使用 TI 的 PDK 驱动程序(无裸机版本)在 IPU 上运行在 TI RTOS 下的独立执行过程中、提供示波器拍摄的一些屏幕截图：

这是8个 GPIO8.20脉冲(黄色)期间的概述、下面是更详细的图片：

您可以看到、I2C 事务在 GPIO8.20的下一个上升沿之前完成、并且在高优先级任务的竞赛中、所有事务都在运行、该任务将等待 GPIO ISR 回调发布的事件。

我有其他主要显示 I2C 活动与 GPIO 中断的延迟的跟踪、我可以通过以下方式进行总结：

1)裸机 I2C 驱动器+ ISR (这意味着调用 ISR 中 I2C 事务的子集)：延迟~ 3us

2)裸机 I2C 驱动程序+ SWI：延迟~ 9us

3) TI 的多线程安全 I2C 驱动程序+高优先级任务(处理程序任务)：延迟~ 14us

无论如何、在没有 Linux+IPC 的 TI RTOS 下、我从未看到过 Lo2报告的问题。

此致、

Scianni Vincenzo  

尊敬的 Rex：

我们运行的是 SDK 04.01.00.06 (ti-processor-sdk-linux-am57xx-evm-04.01.00.06)。

通过 IPC 发送一些基本 MessageQ 消息：

我们在 DSP (1个内核)<-> Linux (2个 A15)和 IPU (1个双 M4)和 Linux (2个 A15)之间进行了 IPC 设置。 未使用 IPU2和 DSP2。

DSP 和 Linux 之间的 IPC 不是很活跃：DSP 上只有一个每秒发送一次活动消息的空闲循环。 DSP 休眠的其余时间。

IPU1通过 IPC 发送一些状态消息、但不会太多。

在 Linux 主机上、除了我们的应用程序外、没有太多活动、CPU 负载小于5%。 它启动外部传感器(在 GPIO8上为 IPU 生成中断)。

没有其他活动的应用程序(没有矩阵启动器、没有 Web 服务器...)

此致、

环路2.

我们在 https://e2e.ti.com/support/embedded/linux/f/354/p/582007/2197295上遇到类似的问题 、不确定您是否可以尝试将 IPU 放在 DeepSleep 上 、如果这 有帮助吗？

此致、Eric

尊敬的 Eric：

应用程序持续运行一些代码、并具有一个高优先级线程来处理由中断触发的操作。 将 IPU 置于深度睡眠状态对于此设置并不是很有用。
与正在运行的 IPU (其中调度程序可能需要暂停正在运行的任务)相比、如果 IPU 从深度睡眠模式唤醒(因为它始终是相同的流)、我可以想象到抖动更小。
对于此用例、抖动不是问题、但总延迟是问题。 (最坏情况抖动和最坏情况延迟之和)

在原始帖子中、我们有500-700us 的延迟、我们通过将未使用的 IRQ 路由到 IPU 来"修复"它。 对于我们的用例、它现在足够快、并且抖动在合理的边界内(就我现在可以说的那样)。

无法理解500-700us 延迟原因、是因为缺少时钟配置？ 交叉开关的硬件问题？


此致、
环路2.

尊敬的 Rex：

在 devicetree (整个组)中禁用 GPIO8。 Linux 不使用任何 GPIO8信号、它们仅供 IPU 使用。 两个 GPIO8中断都路由到 IPU、而不是 A15。

我们不会错过中断、但 IPU 上的 GPIO 中断具有非常高的延迟。

作为权变措施、我们配置 IRQ 交叉开关以将 GPIO8的两个中断都分配给 IPU。 延迟要好得多、但仍然有很多抖动。

此致、

低