[参考译文] AM2434：DO 寄存器读取延迟改善

您好螺栓、

该线程当前分配给另一个团队成员、该团队成员将从 R5F/MCU+端进行注释。 我将在 PRU 方面进行评论。

PRU 读取/写入延迟

您的用例是什么？

PRU C 编译器可以选择进行优化（更多的优化通常可以提高代码效率，但编译器也更有可能以意想不到的方式在某些指令执行中移动。 生成的汇编指令仍将执行您在 C 中编程的操作，但顺序不太可能符合读者的期望）。

如果这是对时间敏感的操作、我通常建议直接使用汇编语言进行编程、因为这样您就可以准确控制 PRU 内核在每个单个时钟周期执行的操作。 客户通常也使用 C 语言编写代码、然后将其时序敏感型函数编程为汇编语言。

更多有关 PRU 读取/写入延迟的信息 、

请参阅  
【常见问题解答】PRU：如何计算读取和写入延迟？

团队和我正在编写测试以重新验证所有信息、这些信息最终将发布到 新的 OpenPRU 存储库中。 然后、我们将 于 2026 年刷新旧的 PRU 读取延迟应用手册。

对于未来的读者、请随时创建新的 e2e 主题来询问我们是否有更新。

有关在 AM243x 上开始开发 PRU 的更多信息 、

请参阅 AM243x Academy 的新 PRU 模块。

仍在积极写入 PRU Academy。 我是主要作者。 如果您有任何问题或反馈、请单独创建一个 e2e 主题、稍后将返回给我。

此致、

Nick

对于未来的读者、Bolt 创建了几个相关的 e2e 螺纹。 我们可能会尝试将这个 e2e 主题保留为重点介绍 R5F 内核读取和写入、并在其他主题上讨论详细的 PRU 概念：

PRU C 代码与汇编代码：
AM2434：PRU - C 代码应用建议

有关 PRU XFR2VBUS 的更多信息
AM2434：PRU 应用 — XFR2VBUS 优化

此致、

Nick

您好、Nick、

感谢您的答复。

关于 PRU 部分、我将继续关注其他线程中的更新。

• AM2434：PRU - C 代码应用建议
• AM2434：PRU 应用 — XFR2VBUS 优化

对于此主题、我将继续等待有关优化 R5F 寄存器读取/写入延迟的说明。

此致
螺栓

尊敬的专家：

关于 R5F 寄存器读取/写入延迟改进、您有任何建议或更新吗？

此致
螺栓

Swargam、  

这是已备案的 TI EP FAE。  

此 e2e 帖子有关寄存器读取/写入延迟（包括 R5F 和 PRU）的两个部分。  

Nick 已回复了 PRU 部分、目前需要您帮助来评论 R5F 部分。  

新的 MCU SDK 似乎可以改善寄存器读取/写入延迟、我们预计团队会深入了解客户如何减少 FSI 寄存器访问的读取/写入延迟。  

您可以建议对 SDK 9.02 进行改进吗？  

Br、Rich

Swargam、  

这是 MCU SDK 的一部分吗？

您可以评论 R5F 部分吗？  

Br、Rich

你好

我们目前正在使用以下方法进行寄存器读取/写入操作。 此方法是否也有效？

上表中提到的函数从存储器地址执行直接读取/写入。

请参阅下图。

]新 MCU SDK 似乎可以改善寄存器读取/写入延迟、我们预计团队会深入了解客户如何减少 FSI 寄存器访问的读取/写入延迟。[/报价]

客户获得的延迟数字是多少？ 这里的要求是什么？

他们是在哪个配置文件中构建示例？ 是发布还是调试？

正在使用哪些优化级别？

此致、

Tushar

尊敬的 Tushar：

感谢您的答复。

HW_RD_REG16()和HW_WR_REG16()函数的基本实现当前与您描述的方法相同。

客户获得了哪些延迟数字？ 此处的要求是什么？

有关此主题，请参阅之前的讨论主题 — AM2434：如果可能、减少 FSI 寄存器读取/写入延迟 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛。 我在下面添加了一个屏幕截图以供参考。 我们的主要目标是使读/写延迟与 F28386 的延迟保持一致。

指令延迟\ 处理器	TMS320F28386D CPU	AM2434 CPU	AM2434 PRU
每个寄存器的读取延迟 (us)	0.02.	0.09.	0.33
每个寄存器的写入延迟 (us)	0.01	0.01	0.02.

此外、在前面的讨论主题 AM2434：DO 寄存器读取延迟在 MCU+ SDK 09.01.00 中改善 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛中 提到、将 SDK 更新到版本 9.1 或更高版本可以改善读取/写入延迟（如下图所示）。 您能否证实此陈述是否准确？ 如果有改进、您是否还能分享有关减少延迟的量化数据或数字？

[引述 userid=“16414" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1597208/am2434-do-registers-read-latency-improve/6197184

他们是在哪个配置文件中构建示例？ 是发布还是调试？

正在使用哪些优化级别？

[/报价]

另有关此主题，请参阅之前的讨论主题 — AM2434：问题。AM2434 编译器和优化设置，提高执行效率 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛。 我们的当前配置基于发行版构建、R5F 优化设置设置为"s"。 如果您有任何专门针对读/写延迟优化的建议、如果您也可以提供相应的编译器配置设置、我们将不胜感激。

此致
螺栓

您好、

指定的专家不在办公室、请期待收到延迟的回复。

此致、

Vaibhav

高螺栓、

[报价 userid=“549268" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1597208/am2434-do-registers-read-latency-improve/6200885

每个寄存器的读取延迟 (us)

0.02.

0.09.

0.33

[/报价]

在此处读取哪个寄存器？

它位于主域还是 MCU 域中？ 从哪个内核读取该信号？

内核以什么频率运行？

我可以看到您在上面分享的表格对两种不同的 CPU 架构进行了比较。 (C2000 和 AM243x)。

此致、

Tushar

尊敬的 Tushar：
很抱歉耽误了回复。

此处正在阅读哪个寄存器？

FSI 寄存器读取/写入，您可以参考 —  AM2434：如果可能、减少 FSI 寄存器读取/写入延迟 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

它位于主域还是 MCU 域中？

FSI 模块在主域中。

从哪个内核读取此内容？

AM24x- CPU：R5F0_0
AM24x- PRU：PRU-ICSSG0 - PRU0 - PRU
F28386 - CPU1

内核以什么频率运行？

AM24x- CPU：800MHz  
AM24x- PRU：333MHz  
F28386 - CPU1 : 200MHz

此致
螺栓

高螺栓、

我尝试使用 AM64x MCU+SDK v11.02、我的代码平均需要 0.11us 来读取 FSI0 模块的 TX_FRAME_CTRL 和 RX_FRAME_INFO 寄存器。

R5F 内核在 800MHz 处运行、读取上述寄存器的函数保存在 TCMA 存储器中。

这些数字是在工程的发布版本中获取的。 我没有看到 0.9us 的读取延迟。 请告诉我们是否需要读取特定寄存器。

此致、

Tushar

尊敬的 Tushar：

参考 AM2434：如果可能、减少 FSI 寄存器读取/写入延迟 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

对 FSI 模块的读取和写入说明如下。

指令延迟\ 处理器	TMS320F28386D CPU	AM2434 CPU	AM2434 PRU
读取 每个寄存器的延迟 (us)	0.02.	0.09.	0.33
每个寄存器的写入延迟 (us)	0.01	0.01	0.02.

 测得的读取时间为 0.09µs 、而不是您之前提到的 0.9µs。 我们期望将其降低至大约 0.02µs 。

但是、根据您提供的测试数据、测量值为 0.11µs 、这似乎表明较新的 SDK 不会改善读/写延迟。 这种理解是否正确？

如果是这样、我们可能会问为什么之前有  指示该 SDK 版本的信息（AM2434：在 MCU+ SDK 09.01.00 中 DO REGISTERS READ LATENCY INXIME — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛） 9.02 或更高版本 会改善读/写延迟吗？ 这是否意味着相应的优化项目尚未实施、或者是否与不同的改进范围相关？

感谢您的澄清和支持。

此致
螺栓