• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 383 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.

Requirement for data buffer transfer from ARM to DSP (OMAP3530) using Message Q

renu
Intellectual 300 points
Other Parts Discussed in Thread: OMAP3530

I am using "ex02_messageq" taken from "ti\syslink_2_10_08_35\examples\archive\ti_platforms_evm3530_linux " for transferring my data buffer from
ARM to DSP for OMAP3530.

My question is
1) when we create heap in "App_Start()" function

" heapParams.blockSize = 64; heapParams.numBlocks = 10;"

what is unit of this blockSize 64? what does "MAUs" mean?
2)In "AppCommon.h"

typedef struct {
MessageQ_MsgHeader reserved;
UInt32 cmd;
SharedRegion_SRPtr buf;
} App_Msg;

Can we transfer "buf" of our own Choice in terms of size? Do we have to make changes in shared region size or memmap.txt specification will serve my purpose?
3)what all changes I have to do in "ex02_messageq" in ARM Side as well as DSP side Code to transfer a buffer(say 1K size data) from ARM to DSP ?
4) Is there any documentation availabe for this MessageQ Example?

  • 0
    TI__Expert 6860 points

    renu said:
    1) when we create heap in "App_Start()" function

    " heapParams.blockSize = 64; heapParams.numBlocks = 10;"

    what is unit of this blockSize 64? what does "MAUs" mean?

    Since the IPC code supports various devices, we need to use a term that would be applicable to all architectures supported. MAU = Minimal Addressable Units.  For the OMAP3530, I believe that's 16-bit words.

    renu said:

    2)In "AppCommon.h"

    typedef struct {
    MessageQ_MsgHeader reserved;
    UInt32 cmd;
    SharedRegion_SRPtr buf;
    } App_Msg;

    Can we transfer "buf" of our own Choice in terms of size? Do we have to make changes in shared region size or memmap.txt specification will serve my purpose?


    In this example the buffer (buf) in the App_Msg struct isn't being used for anything other than a place holder.  The MessageQ msg must be allocated from a heap but the buffer (buf) within the message can be allocated from any location.  You can simply pass the pointer to the buffer in the App_Msg itself. The buffer must be accessible from both cores.  Though making it a SharedRegion_SRPtr type ensure both side can access it.

    renu said:
    3)what all changes I have to do in "ex02_messageq" in ARM Side as well as DSP side Code to transfer a buffer(say 1K size data) from ARM to DSP ?

    No need to make any changes, you can allocate a HeapBufMP (or any other way) and pass it to the message as a pointer so long as its accessible to the DSP-side.  Newer version of SysLink have more examples to illustrate the use of HeapBufMP and SharedRegion.  Follow the download link from:

    http://processors.wiki.ti.com/index.php/Category:SysLink

    renu said:
    4) Is there any documentation availabe for this MessageQ Example?

    All the examples are documented in the the code itself.  You can also find lots of information relate to SysLink at the link above.

    Below is a previous SysLink question related to buffer allocation and usage that you may find useful.

    http://e2e.ti.com/support/embedded/tirtos/f/355/p/324635/1130829.aspx