CMEM and DSP/BIOS

CMEM supports WinCE. For information on how to set up CMEM for WinCE, refer to http://processors.wiki.ti.com/index.php/CMEM_Overview#WinCE_Configuration

---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
---------------------------------------------------------------------------------------------------------

pablo colodron said:

Do I need to have a Linux kernel running on my ARM in order to use CMEM functions?

CMEM supports Linux and WinCE.  Since you mention a CCS project I get the feeling that you're trying to build code intended to run on Linux (most likely, not many use WinCE).  CMEM_getPhys() and CMEM_init() (the 2 CMEM functions mentioned in the build error) run on Linux and don't exist for DSP/BIOS, and generally CCS is not  used to build Linux code.

pablo colodron said:

Is this the only way of sharing memory between the DSP-ARM and co-processors?

CMEM is for dynamic allocation of contiguous memory.  While it's true that you need contiguous memory for a shared memory communication area between processors, you don't necessarily need to dynamically allocate it - you could simply statically allocate it from a memory area *not* under Linux control and share that static address between the two sides (i.e., code on two different processors, usually a DSP<->ARM connection) of the application.

pablo colodron said:

Do I need DVSDK for using CMEM functionalities?

No, CMEM is contained in a stand-alone package named Linux Utils.  CMEM is needed for using Codec Engine.

Regards,

- Rob

Thank you Rob for your comments. You're right, I am trying to build a code intended to run in Linux. However, I am most interested now in how to create xDAIS modules that could work properly and, after, that, create an application in Linux for my DaVinci that is able to call this xDAIS module functionalities.

Given that I am using 'vicp2codec1' as a basis example, I was confused by the fact that the function 'VICP2CODEC1_TI_useVICP' used CMEM functions. If I am not wrong, as 'VICP2CODEC1_TI_useVICP' is part of vicp2codec1_ti.c (part of the xDAIS module) it will be executed in the DSP so no CMEM functions could be used in this case.

Could you confirm this? Thanks again Rob.

Regards,

Pablo

Don't find this example within my EZSDK 5.01.01.80 from here, but anyway: are you sure speaking exclusively about the XDAIS module or might that be that you mix it with the ARM part of the codec?

The CodecEngine driven codecs have their base functionality implemented within an XDAIS module, but by use of CodecEngine they provide an interface to the ARM side as well, and I would assume, that in your case the image capturing or reading from disk or network or whatever is managed on ARM side, and to provide this data to the actual codec on DSP side, you need contigous memory provided by cmemk.ko. Might that clarify what you are wondering about?

Regards,
Joern.

Hi Rob,

I will post in  Multimedia Software Codecs forum refering to this thread in order to ask for help.

Thanks again Rob,

Best Regards,

Pablo

Hi Pablo,

don't want to annoy you, but are you actually sure to speak about the codec implementation (and not speaking about cmem access from within the concerning demo application on ARM side)?

Regards,
Joern.

Hi Joern

The codec example that I am trying to use a base for my xDAIS module is in 'Texas Instruments\codec_engine_2_26_02_11\examples\ti\sdo\fc\ires\examples\codecs\vicp2codec1'.

I don't know if you would have time to have a look at it but, essentialy, it creates an xDAIS module with the typical v-table for the IALG interface:

#define IALGFXNS  \
    &VICP2CODEC1_TI_IALG,       /* module ID */                         \
    NULL,                       /* activate */                          \
    VICP2CODEC1_TI_alloc,       /* alloc */                             \
    NULL,                       /* control (NULL => no control ops) */  \
    NULL,                       /* deactivate */                        \
    VICP2CODEC1_TI_free,        /* free */                              \
    VICP2CODEC1_TI_initObj,     /* init */                              \
    NULL,                       /* moved */                             \
    NULL                        /* numAlloc (NULL => IALG_MAXMEMRECS) */

After this, a function is added to the interface of the xDAIS module:

IVICP2CODEC1_Fxns VICP2CODEC1_TI_CODECIRES = {    /* module_vendor_interface */
    {IALGFXNS},
    VICP2CODEC1_TI_useVICP
};

This function VICP2CODEC1_TI_useVICP is the one that calls CMEM functions. As far as I know, VICP2CODEC1 is a codec intended to run in the DSP. You would have a Codec Engine Server in the DSP with this codec included in the server and the ARM application has a Codec Engine Client that would call Codec Engine Server. If I am not wrong, once the ARM application calls the Coded Engine Server, the desired codec would be executed only in the DSP.

I am sorry but given my lack of experience maybe I am saying a set of wrong concepts...

Thank you very much for your help

Regards,

Pablo

Hi Gunjan,

Thanks for the help.

I will get rid of CMEM calls. I was not actually using them but I didn't understand why those calls were there, given that they are supposed to be used in the GPP side. I thought that I had misunderstood something and that some functions in the codec were executed in the GPP, now I see this is not true.

Kind regards and thanks again,

Pablo.