How to Create Codec on DM6446 run on DSP

Hi Bob,

I recommend you a post in this community about Algorithm in DSP, Juan helps me a lot on how to create a codec. I hope it will help to you.

https://community.ti.com/forums/t/330.aspx

thanks.

Bob,

The post Lorry pointed you to has some good information on developing DSP algorithms.  In my humble opinion, the best way to get started is to look at the sample source code under codec_engine_X_XX_XX_XX directory which is part of the DVSDK software installation.  You will be able to find very simple examples which show you how to take advantage of the various software components included with the DVSDK.  There is also some documentation is this directory that should help, but I think the source code is the best resource.

thanks for your help. I have solved the problem now

Hi , I got a new problem

I want to create a new codec that process two two arrays of diffent types to codec but the program failed to run,though it was compiled successfullly.

I just past the two arrays of diffent types  as paramters  to the codec.

one array is int (int a[]), the other is a struct array(Pixel b[])

How to create a codec that process two two arrays of diffent types passed from paramters 

Thanks in advance!!!

I think your codec is not XDM compatible. Could you paste the error messages?

Please note that when you pass pointers from ARM to DSP, you must allocate that memory from CMEM (contigous memory allocator shared between ARM and DSP). In C, when you pass arrays, you are essentially passing a pointer.

Hi Juan,

          That is to say, the array pointer should point to the beginning of the contigous memory just allocated in ARM application. Is that right?

          In encodedecode demo, I find that the code just uses the contigous memory to pass the video data between capture stream and display stream in "video.c". If the demo is not running in "passthrough" mode, the contigous memory will be passed as parameters to encode and decode functions.  So, I wonder the function "Memory_contigAlloc" sounds like "calloc" besides the former can allocate contigous memory address. Is that right?

Thanks.

When ARM passes memory pointer to DSP, two conditions must be met

1) memory pointed to must be contigous

2) memory pointed to must reside in CMEM space (shared by ARM and DSP)

This is met by using Memory_contigAlloc API.  If "calloc" were used by ARM side application instead, it would allocate memory from the space defined for Linux (defined in bootargs).  It is not safe that DSP access Linux memory space, hence the reason CMEM was defined to share memory buffers between ARM and DSP. 

Let me know if this helps clear things up.

Hi , Lorry

the error message is "segmentation fault"

Hi,Juan

About (1) contigous memory,I did use the contigous memory,

but about(2),I'm not quite clear about CMEM space ,I'm checking it out

For 2):

1. Why it is safe for ARM application accessing Linux memory.

2. From control capabiliy, I think DSP can not compare with ARM. Is that the reason why it is not safe for DSP accessing Linux memory?

Lorry,

To answer your questions

1) ARM runs Linux OS and u-boot booatargs defines how much memory is available for ARM/Linux; therefore, when using standard C functions to allocate memory, ARM MMU will only access the mempry space defined by u-boot.  If you want to allocate from shared CMEM space, you must use the non-standard CMEM function calls.  Why is it safe for ARM to access Linux memory?  Because ARM is running Linux and therefore any standard C function calls will play in this space.

2) Because ARM has MMU to manage memory, it may have some data in cache (as opposed to DDR2); DSP can not assume ARM MMU has copied data back to DDR2 as ARM has no idea that DSP is trying to access a particular memory.  Additionally, there is the contention issue, because ARM and DSP work independently of each other, DSP can be reading data while ARM is writting data (user does not know when memory gets written, this is controlled by ARM MMU).  In short, ARM MMU causes many headaches and CMEM APIs play in a memory space outside of Linux and therefore can ensure MMU does not get in the way.

Bob,

The following wiki articles  may help you understand CMEM better

http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map

http://wiki.davincidsp.com/index.php?title=CMEM_Overview

Thanks Juan, I understand. I'll read documents you recommend to Bob to think about it deeply.

me too ,thank you

I still have another question about function "Memory_contigAlloc".

If I call "Memory_contigAlloc" then the result is "Fail", one of the reasons is that I do not have enough memory space to be allocated, is that right?

Are there any functions to set how large "Memory_contigAlloc" can allocate ?

Thanks.

Lorry

Lorry,

If I am not mistaken Memory_contigAlloc allocates memory from CMEM; if it fails it is because CMEM is out of memory pools, or the memory pools CMEM has (see loadmodules.sh) are too small.  The esiest way to increase CMEM space without having to recompile all DSP software is to give Linux OS less memory (via bootargs) and give CMEM this additional memory (via loadmodules.sh, changing the starting address for CMEM)

Yep, Memory_contigAlloc() - on Linux - uses CMEM.  There are some details and debugging techniques relevant to CMEM here:

http://wiki.davincidsp.com/index.php?title=CMEM_Overview

Chris

notice the loadmodules.sh，that file indicate how much memory you give to cmem.if your Memory_contigAlloc function wants to allocate a buffer larger than the cmem size  indicated in the loadmodules.sh,It will fail

Thank you for your replies.

After reading SPRAAQ6 and CMEM overview ,I still have a question.

Just as in SPRAAQ6 mentioned, "insmod cmemk.ko phys_start=0x88000000 phys_end=0x88200000 pools=2x831488,4x4096" shows that there are two pools here, one is  2 buffers of 812KB and the other with 4 buffers of 4KB.

How does codec know which pool it should use?

[edit] I know poolid is an identification of a memory pool, but I think it does not help to verify which memory pool the codec should use at runtime.

Thanks.

Lorry.

Lorry,

The memory pool definitions are just for CMEM to know which pools it has to work with; when other software components request these pools from CMEM, CMEM looks at its list of 'available' memory pools and if it has one at least as large as the one that is being requested, it assigns that pool to the requestor; if no pool that is at least as large as the size being requested, it fails the request.  With regards to who gets what pool, CMEM manages that underneath and it depends on which software component requests it first.  Think of CMEM as a small memory manager with pre-defined set of memory pools  it can work with.

The job f the system designer is to figure out how many pools and how large it would need for ARM to DSP communication (CMEM was intended for this, but does not have to be used for this); this is primary a function of audio and video algorithms running on DSP side (again does not have to be).