Seeking big picture: Linux, Codec Engine, XDAIS Framework Components

Hi Helmut,

If all you want to do is work on the DSP, Codec Engine and XDAIS supports DSP/BIOS as a target OS. XDAIS is OS agnostic and Codec Engine has an OS abstraction layer which supports Linux, WinCE and DSP/BIOS (and possibly others).

Using Codec Engine makes sense if your algorithm adheres to XDAIS. If you have your own algorithm which is NOT XDAIS compliant, it may be simpler to call the codec directly from DSP/BIOS. You can then use DSPLink to communicate from the ARM to the DSP before invoking your algorithm if you need to.

Regards, Niclas

Niclas,

Thanks very much for the concise yet deep explanation.

Is the source code to Codec Engine itself available somewhere?  I need to make trivial modifications to it, such as reading a switch to alter my codec behavior (and probably informing the codec of this through a non-XDAIS back door).

Note I have a slightly older post asking similar questions about XDAIS Framework Components and Dev Kit (http://e2e.ti.com/support/embedded/f/356/p/66632/242076.aspx#242076)

QUESTION ONE: It sounds like I could use either Codec Engine or XDAIS Framework for my purpose.  Any reason to use one over the other?

QUESTION TWO: Now I add a wrinkle.  In the future I'd like the options of (A) write snapshot to SD card, (B) watch IP video, (C) use SD for something as host or client, (D) control outboard camera and monitor over RS-232. Should I still go with one of the two above, or am I now really needing an OS?  I figure I'm OK on (D) RS-232, but (A,B,C) would be much easier with availability of device drivers under OS.

QUESTION THREE: Boss has me on a very short time frame (weeks).  Might getting prototype running without OS be calendar fast enough that, later when doing it all over again with Linux OS, the initial overhead without OS is inconsequential?  Remember, I have 30yrs hardware/software experience but ZERO DaVinci experience.

Thanks very much,

-Helmut

Hi Helmut,

1) Codec Engine is essentially a codec focused Remote Procedure Call (RPC) framework for calling XDAIS algorithms across processors, but it can work in "local mode" as well. XDAIS is an algorithm standard which helps algorithm developers write portable algorithms (the standard doesn't allow for direct allocation of resources including memory). The Framework Components you refer to gives resources to XDAIS algorithms upon request, such as H/W accelerators and memory allocations.

If you went no-OS you would have to implement your own functions for at least memory allocation and plug these in to Framework Components, the requirements depend on what your algorithm uses. I wouldn't use Codec Engine in this scenario as it has more dependencies on the operating system.

I would encourage you to use DSP/BIOS on the DSP as Framework Components is already implemented on this operating system. It's a low level RTOS, not as complicated as Linux.

2) It sounds like you would benefit from a higher level OS such as Linux for these use cases. That would be a lot of drivers to write.

3) On an SoC the biggest overhead vs. just using the DSP is cache maintenance of video buffers when they pass between the cores. An operating system like Linux has some overhead in userspace -> kernel space transitions, but it's much smaller. This article has more information: http://processors.wiki.ti.com/index.php/Codec_Engine_Overhead.

Regards, Niclas

Niclas,

Your information and advice is amazingly useful.  Thank you very much.  To follow up...

1) When you encourage me to use DSP/BIOS, you also imply using XDAIS Framework Components (FC) on top of that bios.  Understood.  Would this be to the exclusion of Codec Engine (CE), or do FC and CE go together somehow?  

2) Understood.  If I do run Linux, then what do I run on top of that?  FC?  CE? Both?

3) When I used the word "overhead" originally, I was not talking about processor time.  I was talking about my own human effort.  To rephrase my original #3 question, updated by your answer to #1 above:  Imagine I try to save development time by using FC on DSP/BIOS.  In doing so, I temporarily set aside all USB or SD Card or Internet capability.  Then, later, I need to integrate those things in.  This means all of a sudden I should probably jump to Linux.  I'll have to duplicate some of my effort.  I'm concerned about how much effort I'm duplicating.  If it's relatively small, then it's worth it.  If it's relatively large, then it's not worth it.  (Note that this may also depend largely on the answer to #2 above.  If my choice of what to run on top of Linux is substantially the same as on top of DSP/BIOS, that being FC, then it could be the case that the OS setup/installation/configuration and the FC setup/installation/configuration/APPLICATION-HOOKUP are largely independent.  As a result, swapping OS underneath FC might have little impact on FC, leaving only the OS work to consider.  Thus, the answer to this follow up question #3 might relate simply to the difference in work to setup DSP/BIOS vs Linux.)  So, what's the info and your recommendation here?  

PLEASE NOTE ALSO that I'm going to be disk-less, booting from NAND I believe.  

Thanks again,

Helmut

Niclas,

Beautiful answer.  It's so nice to find someone who both understands the question and can explain the answer. 

-Helmut

Niclas et al.:

I'm getting nervous about making sure my custom hardware is going to have what it takes to implement what has been discussed in this thread.  

Can you please look at my new question posted at http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/73101/265573.aspx#265573 ?

Thanks very much.

-Helmut