[参考译文] AM623：ECAP 用户空间应用代码

您好、Li：

我知道您的上一个主题中包含测试代码和文档：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1242640/am625-ecap/4766153#4766153 

1) 1)"不准确"是什么意思？

您是说 ECAP 时间戳本身不准确吗？ 或者您是说、当 ECAP 非常快地捕获时间戳时、Linux 无法足够快地响应、以便在时间戳被新数据覆盖之前读取它们、正如您之前线程末尾所讨论的那样？  https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1242640/am625-ecap/4800670#4800670 

ECAP 硬件对输入信号的时序存在限制、AM62x 数据表中对此进行了定义。 但在本例中、我认为 Linux 调度程序在时间戳被覆盖之前读取时间戳的能力是限制因素。

请提供有关您用例的其他信息

您正在测量什么？

您将捕获的最坏情况(即、最快)脉冲是什么？

AM62x 如何处理这些信息？

此致、

Nick

您好、Li：

好的。 如何调节电机控制？

您可以从每个操作系统中获得什么？

ECAP 驱动程序不存在问题、这只是 Linux 作为操作系统的行为方式。 Linux 不是实时的(即、您不能保证 Linux 在固定延迟内响应外部刺激)- Linux 调度程序不能保证执行几项任务的特定性能指标、而是旨在为所有任务提供最高的整体性能。

RT Linux 允许您确定某些软件任务的优先级、以便它们几乎每次都能满足延迟要求(请记住、 RT Linux 不是硬性实时系统。 如果您的系统将会发生故障、或者如果在0.001%的时间内未满足计时要求、则您确实需要考虑真正的 RTOS 或纯硬件实现、无需软件)。 缺点是、由于某些任务优先于其他任务、因此在 A53内核上运行的所有其他代码的性能将低于在常规 Linux 上观察到的性能。

RT Linux 将能够比常规 Linux 更快地定期响应、但它无法处理1MHz 信号。 该信号的周期仅为1us。

更多有关确保在设定周期时间内进行计算的信息、请参阅
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1085663/faq-sitara-multicore-system-design-how-to-ensure-computations-occur-within-a-set-cycle-time 

在继续阅读之前、请阅读上面链接的常见问题解答。 阅读完该常见问题解答后、接下来的这些句子将更加有意义。

您可能无法使 RT Linux 始终比大约100usec 更快地响应。

您可以在此处看到我们在 RT Linux SDK 10.1上测量的中断响应时间： https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/devices/AM62X/linux/RT_Linux_Performance_Guide .html 

您也可以在此处找到有关测试定制设计的中断响应时间的更多信息：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1183526/faq-linux-how-do-i-test-the-real-time-performance-of-an-am3x-am4x-am6x-soc 

可以替代 PRU 内核来提供您要寻找的功能

如果您未将 PRU 内核用于您设计中的任何其他任务、您可以对 PRU 内核进行编程、以 检测传入信号、并根据需要采取措施。 将 PWM 信号直接发送到 PRU GPI 输入后、您可以看到最快的性能。

有关 PRU 内核和 PRU GPI/PRU GPO 信号的更多信息、请参阅  
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269989/faq-what-is-a-pru-core-why-are-pru-gpio-signals-different-from-regular-gpios

此致、

Nick