Linux + OS-less DSP on OMAP-L137

mtmike said:

What's the easiest way to start a C program on the DSP after it gets the ARM running?

The easiest way would probably be to use DSP/BIOS, since that allows you to leverage the rest of the software such as Codec Engine that allows the loading and execution of DSP code from the ARM. Without using BIOS you would have to write your own custom DSP loader for the ARM and implement your own communication mechanism, as well as having more work to do on the DSP side configuring things like interrupts and the memory map that would normally be handled by BIOS. Essentially the software collateral for the TI ARM+DSP parts is dependent on the DSP running DSP/BIOS, anything else would require significant modifications and/or new software to be written, this is not to say it is impossible, just not something the collateral provides for.

I have been finding the opposite problem,  Running C code is easy and trying to get the framework working much harder.  Then again this is my second day with the card.  

Try looking here

C:\CCStudio_v3.3\boards\evmomapl137_v1\dsp\tests.

seems to be very bare bones test that have little additional code running. 

~JM

JM,

When running a CCS project, the GEL file does much of the required hardware initialization and CCS/JTAG make loading DSP image onto DSP seem trivial.  However, when you take away CCS and JTAG as is normally the case in a finished program, you will need software to initialize the hardware and load the image onto DSP (what Benie suggested by 'loader' program). 

You are probrably thinking that this stills sounds simpler than using the framework and you would be right; the framework does much more then taking DSP out of reset and loading image; it also provides a communication channel between ARM and DSP as well as an environment where DSP algorithms develop by different vendors can co-exists and play well together (framework manages resources).  This is something many customers could use and providing the framework saves them much time.

Thank you for your feedback.

For my project, the DSP/BIOS makes sense in the long-term.  It's well supported and provides a lot of functionality that would be difficult to build from scratch.  The only problem is that it has a non-trivial learning curve, and it would take some time to get up to speed on developing and debugging DSP/BIOS apps.

In the short-term, though, I already have code that does basic interrupts, memory management, ARM-DSP communication, etc.  I need to do some simple performance tests, and the code is mostly there - I just need to figure out a way to run it.  It appears that the DSP-Link application for Linux can load and execute any C program on the DSP, not just DSP/BIOS apps.

Another option appears to be the AISgen program that comes with the Linux BSP.  It looks like it's possible to specify a C program that will run on the DSP after it initializes the ARM.  This solution is not as attractive, though, since the entire system would have to be rebooted every time the DSP code is changed.

Anyhow, I plan on taking a closer look at the DSP-Link application for now and eventually learning DSP/BIOS when I get a chance.