Start with ARM+DSP

Hi Ben,

What are you running in the DSP side? Are you going to use the DSP just for algorithms? Or you are going to use the drivers in the DSP as well?

Please see:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/48908/174018.aspx#174018

Thanks for your answer. 

Actually, I am going to use the DSP side for audio purpose.

I'm confused about all the libraries, API and other interfaces (Codec engine, framework component, DSPLib ... ), which one should I use?

Do I really need a JTAG Emulator in order to develop with CCS?

The "helloDSP" is designed for the L137, is this going to work with the L138?

Last question, about the "Reference Frameworks", do I need to implement the RF1, RF3 et RF5 before go through the RF6?

Regards,

Ben

Hi ben,

I understood that you are going to use the DSP side for audio. Does that mean that you are going to use the DSP drivers (use the DSP to talk to the audio port and codec), or that you are going to use the ARM drivers  (use the ARM to talk to the audio port and codec), and just run audio filters/algorithms in the DSP side?

I think I will use the DSP drivers, just because the example applications I saw use it (Audio Soc, helloDSP). But I don't really know what difference does this make...

The critical part to run in the DSP are the DSP algorithms, as obviously the DSP performance is much better than the ARM for that.

The decision to use the drivers in the DSP side or on the ARM side would depend if your ARM side is overloaded. If what you are running in the ARM is does not require much of the CPU, you can have the Audio drivers in the ARM without a problem. There is an example that uses the ALSA + iUniversal driver for L137 (might need some adaptation for L138):

http://processors.wiki.ti.com/index.php/OMAP-L137_iUniversal_%2B_ALSA_driver

this was made with the test bench code (comes with the SDK) + the IUniversal code: http://processors.wiki.ti.com/index.php/Getting_started_with_IUNIVERSAL

If what you are running in the ARM is "heavy" and you want to have some of the load distributed to the DSP, than you should look at the Audio Soc example that you mentioned:

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

A similar example for OMAP-L137 can be found at: http://processors.wiki.ti.com/index.php/OMAP-L137_Audio_Drivers_in_the_DSP_%2B_Linux

Some DSP developers prefer to use the drivers in the DSP because they are used to it, and prefer the DSP/BIOS OS (runs in the DSP) because it is a real-time OS. 

Thank you for your answer, it helped me figure it out what I need to do.

Actually, I want to do quite the same application than the Audio Soc, but the opposite...

Instead of ouput the signal with the DSP, I want to acquire it with the DSP, make some treatments and give the result to the ARM.

Do you know an example of this kind? Especially for the DSP-side input audio driver.

Regards,

Ben

Hi Ben,

We do not have exactly what you need, you would need to adapt the Audio Soc example.