ipc_ex2_msgqueue_c28x1例程在等待CM4内核回复消息时用了阻塞的方式：
我觉得这样可能效率低些，所以仿照CM4内核接收C28数据的方式，改成了以C28以中断方式接收CM4内核，测试接收时没问题，代码如下
请问这样做可行吗？合理吗？
如果可行，IPC的中断和ePIE中断之间是什么关系，哪个优先级高呢？
ipc_ex2_msgqueue_c28x1例程在等待CM4内核回复消息时用了阻塞的方式：
我觉得这样可能效率低些，所以仿照CM4内核接收C28数据的方式，改成了以C28以中断方式接收CM4内核，测试接收时没问题，代码如下
请问这样做可行吗？合理吗？
如果可行，IPC的中断和ePIE中断之间是什么关系，哪个优先级高呢？
您好 在C28和CM4进程间通讯调试过程中遇到一个现象，相关的问题我还是写在这个帖子里吧
TMS320F28388D: C28XCPU1与CM4 IPC通讯不能进入中断 - C2000
︎ 微控制器论坛 - C2000 微控制器 - E2E 设计支持 (ti.com)
上面这个链接，也就是这个帖子里您贴出的那个帖子的链接，我又复制了一下
这个帖子中，C28与CM4双方都是利用中断方式收发消息
C28发送数据 ----> CM收到数据后进入中断读取数据，随后在中断中向C28发送回复消息 ----> C28收到回复消息后进入中断读取回复数据，随后发送回复消息给CM
上述过程循环往复，C28与CM之间不断进行消息交互。
在这个例子中，应该不存在A发送数据，在B没有读取数据的时候A再次发送数据的情况。
问题1. 如果A发送数据，在B没有及时读取数据的情况下，A再次向B发送数据会出现什么情况。
我在调试中遇到了这样的现象：
在C28中设定了固定周期的Timer中断，在timer中断中定时向CM内核发送消息；
在CM内核接收中断中设置断点，发现第一次是可以进到中断中的，但是只能进一次，在全速运行CM的代码，就进不到中断了；但是如果C28和CM都是以全速方式运行，在两方的变量观测窗口、内存观测窗口看，数据交互似乎是正常的。
我想这是不是由于设置断点，导致CM内核程序执行中断，但是此时C28内核还在不停的向CM内核发送数据，从而导致以消息队列机制进行交互出现异常
问题2. 如果需要多个消息通道的数据收发交互，我可以这样定义和使用消息队列吗？
case1：
IPC_MessageQueue_t messageQueue1;
IPC_Message_t TxMsg1, RxMsg1;
IPC_MessageQueue_t messageQueue2;
IPC_Message_t TxMsg2, RxMsg2;
IPC_initMessageQueue(IPC_CPU1_L_CM_R, &messageQueue, IPC_INT1, IPC_INT1);
IPC_initMessageQueue(IPC_CPU1_L_CM_R, &messageQueue, IPC_INT2, IPC_INT2);
case2：
IPC_MessageQueue_t messageQueue;
IPC_Message_t TxMsg1, RxMsg1;
IPC_Message_t TxMsg2, RxMsg2;
IPC_initMessageQueue(IPC_CPU1_L_CM_R, &messageQueue, IPC_INT1, IPC_INT1);
