[参考译文] AM3356：PRU-ICSS

Nick、

感谢您的回复。

我刚才意识到、PRU 是一款小型 CPU 、仅有8KB 的指令和 数据 RAM。 我的理解是、最多可以将8KB 的代码加载到 PRU 中、这意味着我应该仔细考虑这8KB 的指令代码中可以填充的内容。  

我们考虑3种替代方案：

1.将 PRU 用作专用 CPU、定期从共享存储器发送/接收以太网数据包。 在此设计中、ARM 主内核将为数据读取/写入共享存储器。

2.主 ARM 内核通过 PRU 以太网端口定期发送/接收以太网数据包  

3.主 ARM 内核通过 CPSW 以太网端口定期发送/接收以太网数据包

问题： 选项1优于选项2和3 (在 ARM 内核的 CPU 负载时间内)是否有任何优势？  方案2在 ARM 内核负载中是否比方案1更重？ 方案3 在 ARM 内核负载中是否比方案2或1重？  

选项1在从 PRU 中的共享存储器发送/接收数据(以太网数据包)方面看起来更具确定性、但 对于主 ARM 内核、它也取决于共享存储器的读取/更新速率。  

选项3看起来更好、因为我们不必对软件和硬件进行任何更改。

请提供您的意见。

尊敬的 Martin：

选项1：这不是 TI 支持的用例。 PRU 内核负责处理进出芯片的信号、然后由不同内核处理网络堆栈。 在 AM335x 上、ARM 内核是不同的内核、而在 AM64x 等更高版本的器件上、网络堆栈可由 Linux A53内核或 RTOS R5F 内核处理。

对于通用以太网用例、我不知道使用 PRU 以太网而不是 CPSW 以太网有什么具体好处。 如果您的用例需要3-4个以太网端口而不是1-2个以太网端口、则主要优势将是。

如果您未使用 PRU-ICSS、则可以考虑使用不同的 AM335x 器件型号、例如 AM3354、其 Linux 内核的运行速度最高可达1000MHz。 从而使 ARM 内核的性能略为提高。

另一方面、如果 Linux 内核花费大量周期来执行 非网络任务、例如监控外部电压值、这种任务可以转移到 PRU 子系统中。 如果您有关于 PRU 的其他问题、请告诉我。

此致、

尼克

我与支持 CPSW 以太网的工程师进行了双重核实、他证实、与 PRU 以太网相比、CPSW 以太网具有相同或更少的执行以太网所需的 ARM 处理能力。 再加上所有 AM335x Linux SDK 版本均支持 CPSW 以太网、我建议将 CPSW 以太网用于您的用例。

此致、

尼克

您好、Nick、

再次感谢 您的回答。

我不熟悉 PRU 中以太网子系统的代码和架构、以及它如何与 AM335x 主内核互连。

我假设 AM3356内核上的以太网驱动程序以某种方式向 PRU 传输/从 PRU 接收以太网数据包。 我假设 PRU 实现了 MAC 层并控制连接到 PHY 的 MII 线路。 我是对吗？

我的团队成员坚持要澄清以下选项：

将 多个传入以太网或 UDP 数据包聚合到一个数据包中、并将单个聚合数据包转发到 AM335x ARM 内核、更改 PRU 中的以太网驱动程序是否可行(可能)。 其理念是缩短向一个传入数据包提供多个数据包的时间。 我不确定能否在 PRU 内控制通过 PRU 到 AM335x 主内核以太网驱动程序的以太网数据流量。  

请就此问题提供建议。

实际上、我将暂停线程一会儿。

请在开始时查看  
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_01_00_001/exports/docs/linux/Foundational_Components Network/CPSW.html Kernel_Drivers Network/CPSW.html

部分" 中断起搏 "

此致、

尼克

没问题 Martin！

关于中断节奏的另外一点注意事项-我希望它能够帮助处理 RX 以太网数据包(但我不确定它能改善多少数据、因为我还没有进行自我测试)。 但是、这不会降低 ARM 内核生成的 TX 以太网数据包的处理器负载。

此致、

尼克