Anybody Planning To Use The Dsp?


Curlyjs

Still Fresh
Joined
Aug 31, 2008
Messages
14
Hi All,

I was wondering if anybody is planning to use the DSP for their application... I'm a HW guy so unfortunately I won't be of any help in that matter. But could the DSP be used to accelerate certain emulators, resizing video, audio effects?

What do you think? Anybody has experience with DSPs?

Curlyjs
 
http://www.dsp-c.org

might be helpful. Their overview pretty much sums things up, in terms of language support, and the things you can do with DSP's. And it would probably take a lot of effort and a in-depth knowledge of DSP's to do anything useful, which would mean that the program wouldn't port very well at all. It's a lot of work, not unlike just programming in assembler.

There might be one or two "cool tricks" that can be done with the various chips but you're looking at the sort of things that were made for the GP2X's 940 - niche programs and demos until someone can come up with a general purpose library several years down the line that would probably be quite limited in scope. And to be honest, the 940 was much closer to a "real" processor than a DSP would ever be. It was just the same as the "main CPU" 920 but without such easy access to the memory. A DSP is a different ballgame altogether.
 
I'm planning on using the DSP for filters and effects for music software specifically being written for the Beagleboard/Pandora .. so for sure I'm interested in knowing anyone else who's gonna do the same. DSP assembly doesn't bother me - the idea would be to put only a few functions on the DSP (filter, effects) and use the main processor to do a majority of the synthesis work ..
 
ledow said:
There might be one or two "cool tricks" that can be done with the various chips but you're looking at the sort of things that were made for the GP2X's 940 - niche programs and demos until someone can come up with a general purpose library several years down the line that would probably be quite limited in scope. And to be honest, the 940 was much closer to a "real" processor than a DSP would ever be. It was just the same as the "main CPU" 920 but without such easy access to the memory. A DSP is a different ballgame altogether.

We will get some standard way of communicating between C-A8 and the C64x+ (DSPbridge or whatever it's called). That library is made of modules that take care of communication at low level, a "firmware" for the C64x+, a way to launch programs, API to exchange data and synchronize, etc. I may have details wrong, but you get the idea. Anyway it won't be the mess 940 is (no pun intended, some people did great things with it) so it should be easier for most programmers :)
 
Last edited by a moderator:
I want to use DSP for procedural texture creation lib. Data flow in those seems to be a good fit for either DSP or NEON. I might end up using both. :rolleyes:
 
I hope someone will port liboil to the dsp (from the scroedinger codec for dirac).

I also hope someone will add NEON and DSP support to corepy.org
 
Can anyone estimate how likely is it we can get a resource in using the C64x+ DSP in our development?

I too am interested in doing some signal generation and manipulation for audio synthesis with the help of the DSP.
 
mrpham said:
Can anyone estimate how likely is it we can get a resource in using the C64x+ DSP in our development?

I am not sure I understand your question. It will only be a matter of compiling your application for the DSP (using TI compiler free for non-commercial use) and use the API to launch and establish communication between your DSP app and your program running on the ARM core.
 
Last edited by a moderator:
Yeah, I'll get SBC working first (already working on the C55 on the Nokia tablets), then I trust Tremor and mad will be easier than for the C55 (both of which I've yet to finish) mainly because of the nice 8bit byte :)

For Tremor the issue atm is a lack of memory, we'll have to see what the debugging tools are like on the C64 (or actually it might even have enough DSP-local memory to support the codec without resorting to slab allocators in shared SDRAM, we live in hope).
 
I think the DSP would be ideal for sound processing, it could lift the burden of mixing and maybe de-compression and distance attenuation from the ARM.
Someone could do a port of OpenAL that utilises it, wouldn't that be smashing!
 
I was thinking of porting OpenAL for it, I've been a bit stuck dev-ing as my linux disk got messed up a while ago, but I'm finally getting my beagleboard dev environment set up right now...
 
I am of the opinion every chip has to be used to the max to unload the ARM to be the general application processor.
I am in favor of developing a sound card driver with dsp mixer.
This would be the thing to do.
 
Back
Top