• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 899 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138 - DSPLINK - MSGQ

David Marty
Intellectual 645 points
Other Parts Discussed in Thread: OMAP-L138

I'll try to understand the MSGQ operation in DSPLINK.

With this name "MSGQ" (message queue), I expected a real queue of messages. The sender can send multiple messages before the receiver reads messages one by one.

 

Is this definition correct ?

A real queue operation is possible ? How ?

Is there an example that show this ?

 

Thanks for your answers

  • 0
    TI__Expert 6860 points

    David Marty said:

    With this name "MSGQ" (message queue), I expected a real queue of messages. The sender can send multiple messages before the receiver reads messages one by one.

    Is this definition correct ?

    In short Yes.  You may want to take a look at the DSP/BIOS API Reference Guide for a more detailed description of the MSGQ modules.

    MSGQ  can be used for both intra-processor communication (process to process) and inter-processor communication (ARM + DSP) as is the case when using DSPLink.

    You may also find some useful info here:

    http://processors.wiki.ti.com/index.php/DSPLink_FAQs#What_is_the_difference_between_DSPLink_MSGQ_and_DSP.2FBIOS_MSGQ.3F

    There are also various examples in both the DSPLink product and the DSP/BIOS examples that should should help you get started.

    If you are using the OMAP-L138 DVSDK kit there is an audio example (audio SOC) that uses MSGQ to pass data between processors using DSPLink.  You can find more detailed info on that application:

    http://processors.wiki.ti.com/index.php/Audio_Soc_example

  • 0 in reply to Arnie Reynoso
    Intellectual 645 points

    Hi Arnie.

    Thank you for your answer.

    I'll be much concrete :

    In my application from scratch or from the "message" example in "dsplink_linux_1_65_00_02", I'm not able to see MSGQ to work fine. If the writer sends only one message, the reader is able to read and use this message but if the writer sends multiple messages rapidly, the reader only see only some messages but not all.

    Why ? Effectively, this is not the functionnality described in SPRU403R.

    Is a configuration parameter of DSPLINK or MSGQ can explain that ?

  • 0 in reply to David Marty
    TI__Expert 6860 points

    You should be able to send multiple messages into the MSGQ queue and read them at you convenience.

    The typical data flow model for MSGQ is:

    write: MSGQ_locate -> MSGQ_alloc -> MSGQ_put -> MSGQ_release

    reader: MSGQ_open -> MSGQ_get -> MSGQ_free -> MSGQ_close

    In the DSPLink message sample application, the same message buffer is re-used on both cores thus only one allocation is performed.  Are you allocating multiple MSGQ buffers to put onto the queue or are you re-using the same buffer.  If your reader isn't keeping up, you could be simply over-writing the data.

  • 0 in reply to Arnie Reynoso
    Intellectual 645 points

    Hi Arnie !

     

    This is a little bit better.

    The problem was about the use of MSGQ_free, I'm not sure when I have to use this function : please, give me more information about that.

    If I don't use MSGQ_free, the reader receives the good number of message but the msg_id is corrupted by the most recent msg_id.

     

    See in the attached file the main files of my project.

  • 0 in reply to Arnie Reynoso
    TI__Expert 6860 points

    I see two potential issue here.

    On the GPP -side, I see that you only allocate (MSGQ_alloc) one buffer and issue multiple puts (MSGQ_put) into the queue.  If you want to send multiple buffers without waiting to get one back from the DSP (to re-use), you must allocate the same amount of buffers you put into the queue.  Similar thinking applies to the DSP-side, if you are acquiring a message (MSGQ_get) and not sending (MSGQ_put) the buffer back to the GPP then the DSP-side must free the buffer.

    Genreal rule on thumb:

    Writer:   alloc -> put -> alloc -> put, ... etc

    Reader: get -> free -> get -> free, ..., etc.

  • 0 in reply to Arnie Reynoso
    Intellectual 645 points

    Thank you very much for your help !!