工具与软件：
从以下 URL 下载了 TI 的 Linux 内核、并使用 Linux 内核的 RT (实时)版本切换到了 ti-rt-linux6.6.6.y-cicd 版本。
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/
使用 rpmsg_char_simple.c 中的以下示例代码
e2e.ti.com/.../4276.rpmsg_5F00_char_5F00_simple.c
测试了超过100,000次、并使用命令./rpmsg_char_simple -r 2 -n 100000和 chrt -f -p 10 $！设置优先级。 测试结果如下图所示：
从图中可以看出、最大延迟为1177us、这个值太高了、不符合我们的电流要求。 是否有优化的空间？
您好、Nick J ü、
目前、CPU 以1GHz 的频率运行。 我正在使用以下 文件系统。
默认情况下、文件系统放置在 SD 卡上以进行操作。 只有系统的默认任务、没有其他任务。 系统启动后、我运行以下任务：
/rpmsg_char_simple -r 2 -n 100000 & chrt -f -p 10 $！
我不确定我的工作环境是否与您的？相同
此致、
Mack
另外、我们正在使用的 SDK 版本为10.00.07.04.as (如下所示)：
您好、Nick
延迟要求
如果最大延迟偶尔超过100us、则整个器件将失去精度。 因此、我们不能允许这种情况发生。
最坏情况延迟
该最大延迟是往返延迟。 A53和 R5F 之间的通信时间、R5F 和 A53之间的通信时间是指硬件通信时间、而不是应用发送和接收数据所需的时间。 以前、我们使用 EtherCAT 总线测量从发送数据到接收数据的时间、该时间在20-30微秒之间。 此测量还指网卡发送和接收数据之间的间隔、而不是应用层的间隔。
这里、我有一个问题：为了实现下图所示的性能、我需要采取哪些步骤？
此致
Mack
您好、Nick
我rpmsg_char_zerocopy使用命令(./rpmsg_char_zerocopy -r 2 -n 100、)测试了示例、但出现了以下问题。
使用命令时(./rpmsg_char_zerocopy -r 2 -p 14 -n 100）、出现以下错误。 您能否建议如何正确设置remote_endpt参数并解释为什么屏幕截图中出现错误消息？
此致、
Mack
您好、Nick J ü：
1、我修改了如下所示的器件树。
apps-shared-memory {
compatible = "dma-heap-carveout";
reg = <0x00 0xa6000000 0x00 0x2000000>;
no-map;
};
设备节点 cerveout_apps-shared-memory 出现在/dev/dma_heap 目录下。 使用以下命令./rpmsg_char_zerocopy -r 2 -n 100 -e /dev/dma_heap/carveout_apps-shared-memory 仍然会导致以下错误。
2、我按照以下步骤将您的零复制代码加载到 R5F 内核中、而不是 RPMsg 回声代码：
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AdAyuKWUWVV5j4wBc7C6XA__AM64-ACADEMY__WI1KRXP__LATEST
发生以下错误、我使用的是 RT 版本的 SDK 10.00.07。
您使用的 SDK 版本是否与我的版本相同？
我是否需要刷写 R5F 内核上的任何固件？
此致、
Mack
Mack、您好！
我想向您提供部分最新信息。
TI-rpmsg-char 示例已更新、可用于测试
我已经更新了您之前找到的 ti-rpmsg-char 示例代码、现在该代码应该能够计算数十亿次测试运行的平均延迟。 这与您在一周左右发现的测试代码不同、在测试代码中的平均延迟计算会因大量测试运行而中断。 提醒一下、对于上一个线程中的10亿次测试运行、我必须通过将直方图数据导入到 Excel 中并在 Excel 中计算平均值： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1388960/sk-am64b-rpmsg-between-a53-and-r5-performance-update/5328241#5328241来计算平均延迟
更新后的代码如下所示：
我还不会将其推送到公共存储库、因为我可能想要进行其他更改、以便将延迟基准测试集成到未来的 Linux_Performance_Guide 文档中：https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/10_00_07_04/exports/docs/devices/AM64X/linux/RT_SDK.html
e2e.ti.com/.../0001_2D00_Update_2D00_max_2D00_message_2D00_size_2D00_to_2D00_496.patch
e2e.ti.com/.../0002_2D00_Replace_2D00_fixed_2D00_number_2D00_of_2D00_read_2D00_bytes.patch
初始测试结果
在了解到我尚未优化文件系统和 Linux 内核的情况下、这与使用开箱即用的默认文件系统获得的 RPMsg 性能一样好。 添加共享存储器读取和写入将增加更多延迟。 如果这些数字不足以满足您的用例需求、则需要评估 Linux 和 R5F 之间的其他信令方法。
通过 RPMsg 发送1个字节的延迟远短于通过 RPMsg 发送496个字节的延迟。 这个发送496字节10亿次迭代的测试仍然在运行、但我会在测试完成后立即添加结果。
测试方法
软件
RT Linux 文件系统：
来自 https://www.ti.com/tool/download/SDK-AM64X 的 tisdk-default-image-am64xx-evm.rootfs.wic.xz、PROCESSOR-SDK-LINUX 10.00.07.04
R5F 代码：
使用在文件系统映像上预构建的 ipc_rpmsg_echo_linux 固件
Linux 用户空间代码：
将上述补丁应用于 https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/
修改 Linux 用户空间代码中的这些行、并重新编译应用程序、以便在发送1个字节、496个字节或其他内容之间进行选择：
/* select how many bytes to send per message */
/* send 1 byte */
sprintf(packet_buf, "0");
/* send 4 bytes */
//sprintf(packet_buf, "0123");
/* send 32 bytes */
//sprintf(packet_buf, "01234567890123456789012345678901");
/* "normal" test: do the hello message */
//sprintf(packet_buf, "hello there %d!", i);
/* maximum test: send 496 bytes (i.e., 495 bytes plus null termination) */
//sprintf(packet_buf, "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234");
我重命名了输出文件、以便跟踪哪个二进制发送了多少字节。
最后、我禁用了 R5F 子系统的 core1、并使用 core0运行测试(目的是确保另一个内核上运行的代码不会影响延迟)。
运行的测试如下所示：
与 R5F0_0交谈。 运行1字节测试10亿次、并将优先级提高到50以上和99以下
./rpmsg_char_simple_1byte -r 2 -n 1000000000 & chrt -f -p 80 $！
另一个可能的测试是在 Linux 上添加后台负载。 在这种情况下、命令将如所示
Stress-ng --cpu-method=all -c 4 & ./rpmsg_char_simple_1byte -r 2 -n 1000000000 & chrt -f -p 80 $！
肠道检查：测试10,000次迭代
| 功能 | 平均延迟 | 最坏延迟 |
| ./rpmsg_char_simple_1byte -r 2 -n 10000 & chrt -f -p 80 $！ | 28us | 205us |
| ./rpmsg_char_simple_496 byte -r 2 -n 10000 & chrt -f -p 80 $！ | 147 μ s | 257us |
未绘制这些测试的直方图
测试、迭代次数为10亿次
| 功能 | 平均延迟 | 最坏延迟 |
| ./rpmsg_char_simple_1byte -r 2 -n 1000000000 & chrt -f -p 80 $！ | 28us | 203usec |
| ./rpmsg_char_simple_496 byte -r 2 -n 1000000000 & chrt -f -p 80 $！ | 147 μ s | 334 μ s |
| 功能 | 直方图 |
| ./rpmsg_char_simple_1byte -r 2 -n 1000000000 & chrt -f -p 80 $！ |  |
| ./rpmsg_char_simple_496 byte -r 2 -n 1000000000 & chrt -f -p 80 $！ |  |
此致、
Nick