[参考译文] LP-AM243：AM2434 GPIO 延迟

您好 Andre、

您能否共享同一个用例？ 您还可以使用 PRU 来切换 GPIO，而不是 R5内核吗？

谢谢、此致、
Aakash

Aakash、

   我们知道 PRU 可以对切换 GPIO 进行快速响应。 目的是了解从 R5F 写入 GPIO 设置/输出寄存器到信号实际变化电平的延迟。  客户需要了解限制。 我认为这不是不合理的要求。  

AM2434 R5F 的运行速度@800MHz 1.25ns、GPIO FCLK 为125MHz 8ns。  CPU 向 GPIO 信号变化写入 GPIO 设置寄存器的184ns 结果是否合理？   

此致

Andre

安德烈曾、您好！

切换功能不在 TCM 中。 请检查您的地图文件。 您可以尝试修复该问题并重试吗？

此致、
Aakash

阿克桑

   我已仔细验证测试代码。 编译器选项会导致问题。 我将优化级别更改为"无"。 代码现在被放置到 TCMA 中。

但是、结果与原始结果几乎相同。

这不会让我感到意外。  这是一个非常简单的测试程序、它仅切换 GPIO。 指令缓存后、它们不会成为缓存之外的受扰对象。 只要高速缓存始终命中、性能就应该与将它们放入 TCMA 相同。

GPIO 延迟如此长有何理想原因？ FAST 编译器选项为什么会忽略代码段分配？

此致

Andre  

您好 Andre、

我想它来自 GPIO 输出。 您能否 使用 DPL 函数：CycleCounterP_getCount32来测量* GPIO1_8_SET_ADDRESS = GPIO1_8_MASK 的执行时间。

实际上、您所获得的范围捕获已得到某种程度的确认、 ** GPIO1_8_CLEAR_ADDRESS = GPIO1_8_MASK"或"* GPIO1_8_SET_ADDRESS = GPIO1_8_MASK"花费了大约184ns (从高到低或从低到高)。

我听说 PRU-ICSSG GPIO 比 SOC GPIO 具有更好的性能(更短的延迟和更高的确定性)。 如果 GPIO 性能对系统至关重要、您可能需要考虑 PRU-ICSS GPIO。  

此致、

Ming

明

 目的是了解从 R5F 写入 GPIO 设置/输出寄存器到信号实际变化电平的延迟。  使用   CycleCounterP_getCount32只能获取执行的循环指令。  它不能表示 GPIO 延迟。  

AM2434 R5F 的运行速度@800MHz 1.25ns、GPIO FCLK 为125MHz 8ns。  CPU 向 GPIO 信号变化写入 GPIO 设置寄存器的184ns 结果是否合理？   

184ns 与数据表规格相差很远。  与3.6ns + 0.975*8ns 相比，它几乎比规格高10倍。 100Mhz 的 C2K 可在最大25MHz (40ns)时切换 GPIO、请参阅以下规格。 MSP430FR 约为16MHz。  2.71Mhz 似乎与 AM2434的速度不匹配。

您能否再次确认 AM243x 上的 GPIO 延迟是否正确？ 如果是、请告知 数据表中的参数是否正确？ 如何测量它？

此致

Andre

您好 Andre、

我们认为额外的延迟184ns-18.6ns = 165.4ns 最类似于中断延迟、因为  GPIO_bankIsrFxn 中的"* GPIO1_8_SET_ADDRESS = GPIO1_8_MASK"可能会导致另一个 GPIO 中断。 是否可以在未启用 GPIO 中断的情况下测试 GPIO 输出？

此致、

Ming

明

  该测试代码使用 while 循环来测试 GPIO 切换。 测试代码仅切换 GPIO、未启用任何中断。 请勿与其他讨论主题混用。

 根据您的信息184ns 与规格18.6ns 相差很远。 我们想知道为什么？ 以及如何获得此类结果。

此致

Andre

明

  BTW、即 LP-AM263x 上的相同测试、GPIO 延迟仅显示~35ns。 因为我在 TRM 或数据表中找不到 GPIO 模块的 FICLK、结果看起来更合理。  

我可以帮您检查为什么 AM243x 上的 GPIO 延迟如此长？

此致

Andre

安德烈曾、您好！

我们有 一个测量 GPIO 延迟的实验结果。  AM243x-EVM 上的数据大约为130ns。 我建议您更改项目中的一些 MPU 设置以查看改进。

禁用外设 MMR 的严格排序配置(默认情况下由 MCU SDK 针对4G 外设空间完成)。 这将允许 R5F 执行流水线优化。 这可以通过 MPU 配置为此选择高级配置并将 TEX 用作0和可缓冲(B) 1高速缓冲(C) 0来完成。

我们将在内部进行同步、并在下周之前回来、对数据表提供的数字进行一些更新。

谢谢、此致、
Aakash

Aakash、

  感谢您的回答。 我听从您的建议 并修改了 MPU 设置。  

因此、最小延迟变为6ns。 但是、GPIO 的时序不可预测。 最长时间为160ns、是它们最小时间的10倍。

我使用调试模式并将代码加载到器件中、以检查修改后的 MPU 设置与修改后的 MPU 设置之间的差异。  装配体显示它们是相同的。 您可以看到这两个文件：strongly_ordered.txt 和 mpu_optimized.txt

e2e.ti.com/.../strongly-ordered.txte2e.ti.com/.../mpu_5F00_optimized.txt

R5F 流水线会产生很大的影响。  

但是、对于 I/O 区域、我认为严格排序是强制性的。  没有严格排序的访问 I/O、我们无法优化管道

我建议我们表示 GPIO 规格的测试条件、并在   数据表中提供有关管道优化影响的一些注意事项。

此致

Andre

您好 Andre、

以下是我们的软件开发团队提供的答案：

------

来自 R5F 的 GPIO 访问延迟为130ns。 您可以通过禁用外设 MMR 的严格排序配置(默认情况下由 MCU SDK 针对4G 外设空间完成)来提高写入延迟。 这将允许 R5F 执行流水线优化。

这可以通过 MPU 配置为此选择高级配置并将 TEX 用作0和可缓冲(B) 1高速缓冲(C) 0来完成。

如果存在这种低延迟要求、则可能需要结账 ICSS GPI 和 GPO 引脚、您可以在此处以4ns (@ 250MHz)和3ns (@ 333MHz)的粒度进行轮询。

------

此致、

Ming

明

  是否可以提供测试条件，如编译器选项、代码段位置.........  还是测试代码达到130ns？

我们希望在这一领域重现这种情况。 谢谢。

此致

Andre

Aakash、

   我将向您发送另一封邮件、说明客户为何关心此讨论。  如果某些信息不适合在此处发布、我们还倾向于在内部发布、并仅向 NDA 客户披露。