[参考译文] AM4378：在 AM4378处理器中加载 PRU-ICSS 固件时出现问题

感谢您的答复。
此问题已解决、但我无法使用驱动程序、因为我没有任何开发标准固件的资源手册。  
示例包含环回测试、但我不知道固件的标准结构以及应该在其中开发哪些函数。

你好、MOH、

请详细说明您在系统中尝试执行的操作。

例如、是否只需要 Linux 的一个额外 UART 端口、以及是否希望 Linux 能够在 PRU 子系统中使用硬件 UART？ 在这种情况下、您实际上不需要对 PRU 内核进行编程。 您可以只对 Linux 进行编程。 您将看到适用于 AM335x 的 Linux 驱动程序、并且您可以修改驱动程序和器件树文件以在 Foundational_Components Linux_Drivers 中添加对相同软件的支持：https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_03_05_02/exports/docs/linux/AM437x/PRU-ICSS/Linux/ pruss-uart.html

如果您要执行其他操作、请解释用例。

此致、

Nick

我需要 Linux 的额外 UART 端口、该端口由 PRU 内核而不是主内核控制。 我之前 使用8250_pruss.c 驱动程序在 PRU 子系统中启动硬件 UART、但由于硬件限制、这个额外 UART 的性能对于我的应用来说并不足够。 我想增加一个在实时响应方面与主要 UART 端口或更好的端口相同的 UART 端口。

你好、MOH、

如果我有任何误解、请纠正我：

1)你想要的东西能够听到 UART 端口上的输入,然后快速响应(即,有一个很好的"实时响应")

2)当 Linux 控制 UART 端口时,即使在运行 RT Linux 时, Linux 也没有足够快的响应

后续问题：

1)您需要的"周期时间"是多少? (UART 信号到达处理器与需要执行操作之间相隔多长时间？)

2)在 UART 输入后需要执行什么操作？

3)是否需要在 Linux 和 PRU 内核之间进行处理器间通信(IPC)？ 如果是、此 IPC 是否需要在周期时间内进行？

此致、

Nick

主 UART 可以正常工作、但由主处理器控制的额外 PRU UART 在总线负载较高时无法正确响应。 出现这种问题的原因是、与主 UART 的64字节 FIFO 大小相比、其 FIFO 大小仅为16个字节、并且主处理器无法有效处理中断。 我怀疑如果额外的 PRU UART 由 PRU 内核控制、则问题可能会得到解决。

在我的测试期间、接收到的数据包的频率为200Hz。 除了计算接收到的大约120字节数据包的 CRC 校验之外、在该周期内未执行任何重要的处理。 不过、由于一些字节丢失、大约1%的数据包未能正确接收。

 我的项目中没有任何处理器间通信。