The Following 6 Users Say Thank You to lardman For This Useful Post: | ||
|
2010-09-17
, 00:29
|
Posts: 124 |
Thanked: 52 times |
Joined on May 2010
@ Sweden
|
#12
|
The Following User Says Thank You to S0urcerr0r For This Useful Post: | ||
|
2010-09-17
, 21:55
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#13
|
The Following User Says Thank You to lardman For This Useful Post: | ||
|
2010-09-17
, 22:02
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#14
|
[lardman:]
when i reach a certain level, i will start out DSP asm by making some simple calculation apps for it - almost like a "hello world" app (without display capabilities). they should be small enough to fit in the DSP's cache (if the DSP have cache) so i hope i wont need to use shared memory during the execution of the app, until output is needed from the DSP.
The Following User Says Thank You to lardman For This Useful Post: | ||
|
2010-09-18
, 05:24
|
Posts: 124 |
Thanked: 52 times |
Joined on May 2010
@ Sweden
|
#15
|
The Following 2 Users Say Thank You to S0urcerr0r For This Useful Post: | ||
The DSP is a separate chip, with its own compiler and assembly language and indeed its own kernel (that runs on the DSP and performs IO access, multi-tasking of DSP threads, etc.)
So, there is an obvious advantage that the DSP can run in parallel with the CPU. That's the first thing.
The second, and the reason you have a DSP rather than another CPU is that the DSP is optimised for arithmetic operations in various ways. It can perform SIMD, efficient MAC (both in terms of time and power), the instructions generally inform you if they have had problems (e.g. overflow, underflow) so that explicit checks do not need to be coded in-line.
Another advantage of the DSP is the speed of the memory that it can access and the number of cycles required to access said memory.
I should say that I've not done any DSP programming for the C6x which we have in the N900/beagleboard, as I've been too busy, but I can comment on the disadvantages of the C55 which we had in the N8x0 and say how things have improved with the C6x which we have in the N900.
With the C55 there was no 8bit type (i.e. a char was 16bits wide) which made porting code a real pita. Thankfully the C6x does have an 8bit type which should make things much easier.
My understanding is that the DSP bridge (which is a Linux kernel side link to the DSP's own kernel, and allows data and object code to be passed back and forward) is also nicer to use now than the DSPgateway we used to use on the N8x0.
The DSP runs a multitasking kernel (which is separate to the Linux kernel) and includes an MMU. Data transfer is carried out by mapping shared memory on both the DSP and CPU sides (this was done by the DSP gateway kernel-side code.)
On the 770 the DSP was used to decode video and on the N8x0 it was used only for audio decoding. With the N900 we're back to using the DSP for video.
I ported the SBC codec to the C55 DSP on the N8x0 in the hope that it would offload some CPU load and allow better quality movies to be played in mplayer while using A2DP headphones (the next step being to implement an mp3->PCM decoder that could keep the PCM data on the DSP rather than passing it back to the CPU via the shared memory buffer), but this was not to be.
While the Nokia supplied DSP kernel included an audio hw codec driver, no api docs were available so we would have had to have rewritten the audio hw codec driver and replace the kernel in order to directly output audio from the DSP (not the end of the world, but it would stop the existing mp3, aac decoders, etc., from working). Therefore I used the shared memory buffer to both pass PCM data to the DSP and retrieve it from the DSP. It worked, but some sort of memory contention issue stopped it from being used with mplayer playing video files at the same time.
So yes, you may have troubles. I'm afraid that I don't know how the N900's DSP outputs video data, whether it's passed back to a shared framebuffer or output directly.
There's a wiki page called "DSP Programming" on wiki.maemo.org with links for the N8x0 tools.
HTH