TI中文支持网Part Number:AM623
您好，我在测试m4f与a53-linux之间的ipc通讯，我git-clone了ti-rpmsg-char代码(链接https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/)
在ti-rpmsg-char代码中稍微修改，重新编译通过。
我将ti-rpmsg-char代码修改成了可以发出任意长度的数据，如下图所示，data_len是一个ssh命令行中获取的发送数据长度，而原代码只能发出"hello there %d"
通过这个程序与m4f进行通讯，m4f端的功能是收到什么内容返回什么内容(有一点我已经明白，发送用户数据不能超过496字节)，
如下图所示，当我发送内容小于等于256字节时候，linux可以完整收到m4f端的回复，发送的内容以‘s’开始，以‘e’结束
如下图所示，当我发送内容大于256字节时，linux端就只能收到256字节的数据，发496字节也是返回256字节，发300字节，也是返回256字节，
我通过m4f的串口DebugP_log函数打出了信息，看到m4f是确实收到了所有数据的，且发送的时候也是按收到的长度去传入到RPMessage_send函数进行发送的，
但是就是发不出来，超过256字节就截断。
下图是m4f端vring的配置，vringbuf数量是256个，每个vringbuf长度是512字节(此处已经是512字节，为何出现前文所述的256字节截断问题？)
下面是m4f端的接收发送处部分代码
#define IPC_RPMESSAGE_MAX_MSG_SIZE(512u)
char recvMsg[IPC_RPMESSAGE_MAX_MSG_SIZE+1]; /* +1 for NULL char in worst case *//* wait for messages forever in a loop */while(1) {/* set 'recvMsgSize' to size of recv buffer,* after return `recvMsgSize` contains actual size of valid data in recv buffer*///DebugP_log("runing task_id=%d localEndPoint=%d rec_cnt=%d\r\n", inputArgs->task_id, localEndPoint, rec_cnt);recvMsgSize = IPC_RPMESSAGE_MAX_MSG_SIZE;status = RPMessage_recv(pRpmsgObj,recvMsg, &recvMsgSize,&remoteCoreId, &remoteCoreEndPt,0);if(status==SystemP_SUCCESS){/* echo the same message string as reply */#if 1 /* not logging this so that this does not add to the latency of message exchange */recvMsg[recvMsgSize] = 0; /* add a NULL char at the end of message *///DebugP_log("recvMsg:%s\r\n", recvMsg);#endif/* send ack to sender CPU at the sender end point */status = RPMessage_send(recvMsg, recvMsgSize,remoteCoreId, remoteCoreEndPt,RPMessage_getLocalEndPt(pRpmsgObj),5);//DebugP_log("Rec Size=%d Cnt=%d ",recvMsgSize, rec_cnt);rec_cnt ++;if(status==SystemP_SUCCESS){//DebugP_log("send ok %d\r\n", send_cnt);send_cnt++;}else{DebugP_log("send error = %02X\r\n", status);}//DebugP_assert(status==SystemP_SUCCESS);}else{vTaskDelay(1);}}
问题1：上述的问题出在哪里，如何解决
问题2：下图对应的IPC_RPMESSAGE_NUM_VRING_BUF和IPC_RPMESSAGE_MAX_VRING_BUF_SIZE，这两个参数如何理解？
是不是在ipc通讯中，有NUM_VRING个缓存区，每个缓存区的大小是VRING_BUF_SIZE，如果是这样的话，是不是linux连续发送NUM_VRING个消息，m4f一直不读取，一旦启动读取就可以读取出NUM_VRING个消息？
/* Number of a buffers in a VRING, i.e depth of VRING queue */
#define IPC_RPMESSAGE_NUM_VRING_BUF (256U)
/* Max size of a buffer in a VRING */
#define IPC_RPMESSAGE_MAX_VRING_BUF_SIZE (512U)
Shine：
已升级到e2e英文论坛，请关注下面帖子的回复。https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1311691/am623-m4f-side-packets-can-t-exceed-256-bytes
,
Shine：
请看下面e2e工程师的回复。
请问MCU+ SDK，Linux SDK用的是哪个版本？在SDK 9.0版本里IPC_RPMESSAGE_MAX_MSG_SIZE 最大是496bytes.
Which versions of the MCU+ SDK and the Linux SDK are the customer using?
We accidentally placed a limitation on the size of the RPMsg message that the M4F would receive in earlier MCU+ SDK examples for Linux RPMsg. So the M4F code is the first place I would look.
e.g., if I check MCU+ SDK 8.3, file examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c
I see/* maximum size that message can have in this example */#define IPC_RPMESSAGE_MAX_MSG_SIZE (96u)while if we check MCU+ SDK 9.0, file examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.cI see/* Maximum size that message can have in this example * RPMsg maximum size is 512 bytes in linux including the header of 16 bytes. * Message payload size without the header is 512 – 16 = 496 */#define IPC_RPMESSAGE_MAX_MSG_SIZE (496u)
As far as IPC_RPESSAGE_NUM_VRING_BUF and IPC_RPESSAGE_MAX_VRING_BUF_SIZE:
IPC_RPESSAGE_NUM_VRING_BUF – this is the number of RPMsg messages that can be queued up in each direction (i.e., 256 from Linux to M4F, and 256 from M4F to Linux, for a total of 512 VRING buffers total)
IPC_RPESSAGE_MAX_VRING_BUF_SIZE – this should stay at 512 bytes total per VRING buffer.
,
BobLu：
TI还有一个zerocopy的demo，你可以看一下，适用于传输大量的数据
git.ti.com/…/
