[参考译文] AM6442：CODESYS 性能问题

admin

Guru**** 2378650 points

Other Parts Discussed in Thread: AM6442, SK-AM64B

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1487627/am6442-codesys-performance-problems

器件型号：AM6442
Thread 中讨论的其他器件： SK-AM64B

2025年3月26日编辑

工具/软件：

Sitara 团队大家好。

我的客户已经开发了基于 AM6442的小型 PLC、运行 CODESYS 作为 EtherCAT 主站。

它们试图通过 AM6442实现出色的 CODESYS EtherCAT 性能(最大周期时间)。
首先、我将在随附的演示文稿中描述问题、然后介绍我们采取了哪些措施来提高周期时间绩效。

e2e.ti.com/.../4863.CODESYS-Performance.pptx

一些基本信息：
对于我们的测试、我们使用 SK-AM64B 板 SK-AM64B 评估板|德州仪器 TI.com
我们将使用 Yocto 基于 SDK 09.02.00构建自定义固件、并添加了 RT 补丁。

root@plcnext：~# uname -A
Linux plcnext 6.1.83-rt28-ti-RT-g96b0ebd82722 #1 SMP_RT Preempt_RT、5月13日、星期一、23：06：24 UTC、2024 AArch64 GNU/Linux

我们使用非常简单的 CODESYS 工程、几乎没有代码、只推荐用于跟踪。 EtherCAT 主站正在运行并循环地与 Beckhoff EK1100和 EL2252交换过程数据。
我们有用于 CODESYS 许可的 USB 软件狗。

这是 CODESYS 工程：
e2e.ti.com/.../3324.Trace_5F00_demo.project

目标是在 SoftMotion 中以1 usec 1毫秒周期时间旋转10个伺服驱动器。

这是可能的吗？

您是否看到了用于提高 CODESYS Max 的其他措施？周期时间？

此致
Manuel

6 个月前

0 admin 6 个月前

TI__Guru**** 2378650 points

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

您好 Manuel、

线程所有者将在3月的剩余时间内离开办公室。如果您没有收到回复、请在4月初对该线程执行 ping 操作。

此致、

Nick

0 admin 6 个月前

TI__Guru**** 2378650 points

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

您好：

我还指给客户这一类似主题： (+) PROCESSOR-SDK-AM64X：XDP 支持-处理器论坛-处理器- TI E2E 支持论坛

遗憾的是、将 ksoftirqs 优先级更改为 FIFO 52 并未改善最大周期时间。

您能帮助调试这种原因吗？

此致
Manuel

0 admin 6 个月前

TI__Guru**** 2378650 points

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

您是否联系过 CODESYS？对于1GHz 双核 A53、其预期性能是多少？逐步了解他们和他人拥有的所有指导：

https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_performance_optimization_linux.html

https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux

Unknown 说：
我们有用于 CODESYS 许可的 USB 软件狗。

延迟异常值很可能与 USB 和 CodeMeter CODESYS 使用的许可证服务器有关。您是否在没有使用 USB 的情况下运行相同的设备？其他许可方法、或者仅演示版本不需要 USB。在我们的 CODESYS 测试运行中、我们看到的最糟糕的是许可基础设施和相关的 USB 驱动程序。

您使用 AM6442是否有特定原因？要运行 CODESYS、我建议使用 https://www.ti.com/product/DRA821U 、 https://www.ti.com/product/AM62P 或 https://www.ti.com/product/AM67 。即使不调整 RT Linux 安装程序、这些功能也会显著改善。

Pekka

0 admin 6 个月前

TI__Guru**** 2378650 points

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

[引述 userid="486414" url="~/support/processors-group/processors---internal/f/processors---internal-forum/1487627/am6442-codesys-performance-problems

目标是在 SoftMotion 中以1 usec 1毫秒周期时间旋转10个伺服驱动器。

这是可能的吗？

[/报价]

很好的澄清、我假设是1毫秒。理论 EtherCAT 最佳性能为31.25us (微秒)。请参阅 https://www.ibv-augsburg.de/downloads/icECAT_EtherCAT_AM64x.pdf 、其中显示了 Master_Stack_Benchmark R5内核上100us 周期时间基准测试的细分。您还将看到500us A53 Linux 结果、因此、假设正确调整了设置、则可能出现1ms EtherCAT 主站。

Pekka

0 admin 6 个月前

TI__Guru**** 2378650 points

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

客户已在没有 USB 加密狗的情况下测试了许可、但结果没有太大变化。

这是通过 USB 许可：

这不包括：

如果他们使用自己的环境和工具链重新编译 CODESYS、会有什么不同吗？

此致
Manuel

0 admin 6 个月前

TI__Guru**** 2378650 points

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

第一个问题 CODESYS 说什么？

第二个问题为什么是 AM64x？这是 TI 产品系列中功能更强大的器件的原因。在所有 TI AM6x 产品系列中、AM64x A53 Linux 性能是最差的。

Unknown 说：
如果他们使用自己的环境和工具链重新编译 CODESYS、会有什么不同吗？

CODESYS 是一种黑盒二进制文件、据我所知、它们不允许客户访问源代码。

从几个屏幕截图中、我看到两者看起来都符合1000us 的周期时间？如果没有 USB 转换器、与1429相比、跑步看起来很短、只有370秒、但无论如何、这两种模式都符合1000us 的要求。据我所知(他们当然应该咨询销售 CODESYS 的供应商)、"最长周期时间"是最坏的情况、当它低于所需的周期时间时、即满足计划。

Pekka

0 admin 5 个月前

TI__Guru**** 2378650 points

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

基于 DMIPS、使用 AM6442的设计已经完成、与之前使用的 Zynq 解决方案相比、性能预计会更好(内核时钟更低)。

问题是环路中只有一个器件才能达到1ms 周期时间。
使用8个器件时、性能降至~3ms：

轴数	PRG/LINE	最小周期时间	平均周期时间	最大周期时间	优势	建议最大值	目标周期时间
8.	空闲	1348	1423	1710.	287.	3200	8000
8.	凸轮	1499	1565	1879	314	3200	8000
8.	60000	2699	2765	2948	183.	3200	8000
8.	120000	4021	4089	4303.	214	3200	8000
8.	240000	6661.	6722	6949.	227	3200	8000

这是他们的完整任务优先级列表：

R5F 和 A53之间没有运行的 IPC。

root@plcnext：~# uname -A
Linux plcnext 6.1.83-rt28-ti-RT-g96b0ebd82722 #1 SMP_RT Preempt_RT、5月13日、星期一、23：06：24 UTC、2024 AArch64 GNU/Linux

在与 Thomas Schneider 的讨论中、他提到我们在连接了3个驱动器的 AM6442上看到了~300us。

CODESYS 的整体配置似乎有问题？

此致
Manuel

0 admin 5 个月前

TI__Guru**** 2378650 points

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

好的、所以似乎距离目标还有很长的路要走。对于基准器件、您是否有更具体的细节、什么是 Zynq 器件？比如带有 Cortex-A9的 Zynq-7000或带有 A53的 UltraScale+？这些步骤和内核配置用于实现所需性能、是否遵循了所有相同的步骤和内核配置？

它应该归结为"正常"RT 调优和延迟优化。这是像 Linutronix 和 BayLibre 这样的公司很好的地方。或其他高端 Linux 承包商。并提供了几个起始步骤。

1.确保中断处理不是问题。 PREEMPT_RT 使用 ksoftirq 来处理中断(https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf )。他们的优先事项是什么？类型：

ps aux | grep ksoftirq

查看两个 ksofirqs (每个内核一个)的 PID。在我们的 SDK 中、它们默认不是 RT 或 FIFO 调度。更改为高优先级、如 FIFO 为10。使用如下命令(假设 PID 为13和27)：

chrt -f -p 10 13 
chrt -f -p 10 27

2.在完整的任务优先级列表中,我看到 PRI+RT 列中 RT 优先级(负数)处有大量空。我想90%以上的绿色材料不应该处于高优先级。只有与 CODESYS 使用的以太网接口相关的内容才应是 RT、其他所有内容都不应是 RT。 RT 是一个零和游戏,优先级来自尽可能少的高优先级,蹲下其他人,所以救护车可以通过。高优先级越高、优先级越低。在 Zynq 上获取相同的打印输出并进行比较。

3、使系统精益化。根据经验、Linux 内核越小、RT 性能越好。删除您不需要的所有服务和内核模块。

4. https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux 开始走下坡路。

Pekka

0 admin 5 个月前

TI__Guru**** 2378650 points

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

您好、感谢您加入我们的论坛、感谢您的支持！

更改 Ksoft 中断的优先级不会提高性能。

user4068379 说：
OK、所以似乎距离目标还有很长的路要走。对于基准器件、您是否有更具体的细节、什么是 Zynq 器件？比如带有 Cortex-A9的 Zynq-7000或带有 A53的 UltraScale+？这些步骤和内核配置用于实现所需的性能、是否遵循了所有相同的步骤和内核配置？

对于我们的旧系统、我们使用基于 Cortex-A9的 Zynq 7020。

"第二个问题为什么是 AM64x？这是 TI 产品系列中功能更强大的器件的原因。在所有 TI AM6x 产品系列中、AM64x A53 Linux 性能是最差的。"

这句话对我来说很有趣。原因是什么？如果我们在所有4个 R5内核和 ARM64内核之间使用 rpmsg、性能会更差吗？

0 admin 5 个月前

TI__Guru**** 2378650 points

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

为什么所有中断都是实时的、优先级为-51？您应该只具有 CODESYS 任务 ksoftirq、可能还有几项其他实时任务。其他一切都应具有较低的优先级。实时是一个零和游戏,你真的只能有一件事优先,每个人都应该被推倒和受苦。您能否打印出旧系统和新评估系统中的任务和优先事项？类似的情况

uname -A
获取内核版本

PS -ALO PSR、策略、优先级、pid、tid、cputime、通信
获取正在运行的内容和实时内容

Unknown 说：
根据 DMIPS 标准、性能预计会比 Zynq 解决方案更好

DMIPS 测量热 L1高速缓存的平均性能。它与实时性能无关、而且与复杂的 Linux 应用程序性能几乎不存在相关性。

[引述 userid="644124" url="~/support/processors-group/processors/f/processors-forum/1487627/am6442-codesys-performance-problems/5781821 #5781821"]

"第二个问题为什么是 AM64x？这是 TI 产品系列中功能更强大的器件的原因。在所有 TI AM6x 产品系列中、AM64x A53 Linux 性能是最差的。"

这句话对我来说很有趣。原因是什么？如果我们在所有4个 R5内核和 ARM64内核之间使用 rpmsg、性能会更差吗？

[/报价]

"你是什么人? CODESYS 不使用 R5。对于 CODESYS Linux 性能、您只需要 A 内核、最大时钟速度和高速缓存以及 DDR 性能。一般来说、并行运行的设备越多、Linux 的实时性能就越差。

Unknown 说：

这是通过 USB 许可：

这不包括：

[/报价]
这些屏幕截图中的结果看起来能满足1ms 的周期时间要求、比以下选项好5倍：
[引述 userid="486414" url="~/support/processors-group/processors/f/processors-forum/1487627/am6442-codesys-performance-problems/5770167 #5770167"]

轴数

PRG/LINE

最小周期时间

平均周期时间

最大周期时间

优势

建议最大值

目标周期时间

8.

空闲

1348

1423

1710.

287.

3200

8000

8.

凸轮

1499

1565

1879

314

3200

8000

8.

60000

2699

2765

2948

183.

3200

8000

8.

120000

4021

4089

4303.

214

3200

8000

8.

240000

6661.

6722

6949.

227

3200

8000
[/报价]
您能详细说明一下有哪些不同之处吗？

Pekka

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] AM6442：CODESYS 性能问题