[参考译文] AM263P4-Q1：RPMessage_send () 返回 SystemP_TIMEOUT 的原因

您好、请在此处找到有关我认为其根本原因的简短摘要：

RPMessage 协议使用两层体系结构：

1.数据层（VRING 缓冲区）:存储实际的消息有效负载

• 配置的容量：16 个缓冲器（每个 SysConfig）
• 所有 16 条消息均已成功写入测试中的 VRING

2.通知层 (IPC Notify SW FIFO):向远程内核发出信号以检查消息

• 固定容量：3 条消息（由 PARAMBOL_MAX_msgs_in_SW_FIFO=4 定义，采用循环缓冲区实现）
• 3 个通知后满

执行序列（Core0 暂停）：

呼叫 1-3：写入 VRING[0-2]的数据、在 SW FIFO[0-2]中排队的通知→成功
调用 4：写入 VRING[3]、SW FIFO 已满、IpcNotify_sendMsg () 失败→超时
调用 5-16：写入 VRING[4-15]的数据、SW FIFO 仍满→超时

为什么会收到所有 16 条消息？ 通知用作“门铃“触发器、而不是报文计数器。 执行 Core0 ISR 时、RPMessage_notifyCallback() 处理所有可用消息：

while (RPMessage_vringIsFullRxBuf (remoteCoreId))
｛
   rpmessage_recvHandler (remoteCoreId)；//进程消息
}

接收器会比较 VRING 索引 (lastUsedIdx 与 Used->idx) 以确定消息计数、而不受通知计数的影响。 此通知合并是有意设计的。

RPMessage_send() 返回的 SystemP_timeout 表示通知传递失败、而不是数据传输失败。 消息数据在尝试通知 (ipc_rpmsg.c:280) 之前提交到 VRING、从而确保只要远程内核最终处理消息、就能实现无损传输。

可以采取哪些措施来解决此问题？

1.使用像 SDK 示例一样的非零超时值。

2.批处理邮件以减少发送的邮件数量,将多个小邮件合并成更少的大邮件可以减少接收器上的开销。

3.在几个快速发送之间添加小延迟,例如,每 3 个发送后增加 1ms 的延迟,超时为 0ms。

4.添加重试逻辑以等待您达到超时条件,让软件耗尽 FIFO 并发送通知,即使数据传输已经发生。

根据您的应用设计、您可以选择合适的应用。

此致、
Shaunak