Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAPL138
Hi,
I am currently working with the OMAPL138 platform. I am running SYS/BIOS on the DSP & Linux on the ARM. I would like to communicate between the cores with IPC over RPmsg.
In this regard, I have tried out the "ex02_messageq" & "ex11_ping" examples and the outputs looks fine.
MessageQ flow question:
I am currently writing my own application, which is applying IPC & MessaageQ, but I am struggeling a bit with understanding the MessageQ flow between the ARM & the DSP.
Considering the steps mentioned below, is the MessageQ flow correctly understood?
DSP opens queue created by ARM, OR ARM opens queue created by DSP
- [DSP] creates local MessageQ with MessageQ_create().
- [DSP] waits for a handshake message from the ARM with MessageQ_get().
- [ARM] creates local MessaageQ with MessageQ_create().
- [ARM] opens DSP local messageQ to obtain queue id for DSP local queue.
- [ARM] initializes MessageQ header in message with MessageQ_setReplyQueue().
- [ARM] sends message with MessageQ_put().
- [DSP] receives the message from the ARM and is able to obtain a queue id with MessageQ_getReplyQueue() from the ARM message.
MessaageQ_open not working on DSP:
I have also experienced that any calls to MessageQ_open() on the DSP always returns "MessageQ_E_NOTFOUND" If I try to open a local MessageQ created by the ARM.
However, the ARM is perfectly able to open any local MessageQ created by the DSP with MessageQ_open(). Is this due to the ARM being able to obtain the queue id's using
the LAD daemon & the DSP is unable to use the LAD daemon since it is running in Linux?
Thanks & Regards,
Kim
