Affordable Freescale DSP Board

I thought this might be interresting to my fellow DSP enthousiasts;

Symphony™ SoundBite - Affordable Audio DSP Development Kit Product Summary Page

Comes with free dev tools!
Debugging through JTAG via USB.

Very affordable. I bought a couple early this year.
The board is based on a member of the well known 56k DSP chip family
and is equipped with decent AK codecs.

While those who have worked with mot56k before can jump right in,
there might be quite a learning curve for others.
Compared to emu10kx the DSP56371's instruction set can be quite intimidating
as is it's initialization and features.

This thing is very fast.
@48kHz I was able to squeeze several cascaded effect algoritmes like
guitar amp moddeller + Cab.moddeller + Chorus + tremelo + delay + Reverb
etc. into it without any dropouts.
The onboard RAM however is quickly used up by the delay lines.

Although you can program the DSP in C (comes with C compiler),
assembler is still the way to go.

/Lex.

 

Btw. there's one more interesting product coming (same Freescale DSP but with additional bite - well, check it out): Line 6 - ToneCore DSP Developer Kit

 

Yes, I've seen that one but it wasn't available (still isn't??)
Besides, I wanted an expandable board (host + LCD, knobs etc.)

Btw; I'm still looking for a suitable (affordable) host processor board.
Any suggestions?

 

Cool stuff
Thanks for the info.

 

For the features/affordability ratio i believe this Freescale's goody is just unbitable by now.
(it's interesting how agressively they decided to get these old good Motorola 563 series back to the market - very good)
I'd really wish i had this one a few years ago.

 

I wunder if these devices use a host cpu for reading out those pots/controls and parameter calculation.
I doubt it's all done in the dsp.
Did you find any specs/technical info?

 

I do not think so, that would seem to defeat the purpose of making it stomp box. From the info on that page, it sounds like it only needs to be connected to the PC for programming.

 

From what i've heard/read it has "some" MCU to handle this - but nothing in detail
(just some "on-board Freescale microcontroller")

 

The following document has a little more info:
http://www.freescale.com/files/ftf_...NewToneCoreDevelopersKitfromLine6.pdf?fsrch=1

 

Sorry, you misunderstood; most if not all such digital audio devices use a seperate build-in host cpu to support the DSP. (not a PC)
Non audio tasks like MIDI interface, control readout and parameter calculation etc. are handled by that host cpu.

PS:
Yes, MCU actually since it has all the periphial components and RAM/ROM integrated.

 

Yeah, sorry, I misunderstood the term host.
In any case, the above document shows the MCU info (Flexis MC9S08JM).

 

Ah yes see on page 6.
That MC9S08JM MCU reads out those controls and more.
Thanks for the doc.
Now let's see if there's some affordable dev board for the MC9S08JM.

 

Lol, turns out to be an 8-bit proc.
Anyway, board. $99
DEMOJM Product Summary Page
Supports the 32-bit mcu as well.

 

btw., Lex - just in case, what a specific purpose you need a MCU board for?
(Actually, i've misread your question about "affordable host processor board" above - reading it as "DSP board" for some reason)

Either way (if you're not limited to any specific arch. or manufacturer) - of course i'd recommend something ARM based. There're very inexpensive ARM chips/boards.
For example, last year i used LPC2148 PROTOTYPE DEVELOPMENT BOARD (it's a clone of more expensive IAR Kit) - here in Moscow i got it just for $30. So far so good - it did its task (though i can't say the USB part of this particular Phillips 2148 chip is not weird ).
Although - before going with ARM you will need to dig into compiler compatibility/availability stuff (as not every ARM chip/board is programmable with GCC and commercial ARM compilers are very expensive).

 

Well, the Soundbite is great but does not have a host MCU.
(currently I use a laptop as host for the soundbite)
To make a complete standalone device I need a host MCU that does;
- parameter calculations (filter coeffs & stuff)
- control readout (pots, switches and dial encoders)
- MIDI I/O
etc. and it must come with C compiler.
(i'm not going to do filter coeff math in assembler lol)

Hey Max that ARM board looks perfect at firts glance!
Is there a (free) compatible C compiler available?

 

Is there a (free) compatible C compiler available?

As far as i can tell - yes. (search for something like "LPC2000+gcc" or so).
Unfortunately - i can't say in detail (as i used a commercial compiler).

Anyway - i mentioned this particular board just as an example (if you dislike this one for some reason). But speaking of microcontrollers (and especially of 32-bit ones) - it's no even doubt to go with ARM
(There's quite wide choice of ARM chips/boards - so i'm sure sooner or later you'll find something that fits near perfectly)

i'm not going to do filter coeff math in assembler lol)

I assume that you're ready for no floating-point in MCUs
(though actually with many compilers you'll be able to have some fp-emulation - it's still pain in the ass)

 

Now that's the kinda info I like!
No need to look further, ARM it is.
Thanks.

 

Why are those fpu emulations PITA? Incompleet, not accurate?
I mean OK they are slower since they run in software, but sin(x) is still the same sin(x) from a programmers point of view right?

 

Welll, nothing serious - but, it's additional Flash/RAM overhead (may or may not be critical depending on their amount you have) and they're not just "slower" but "slooooow" :drool: (again may be just fine on >50MHz MCU - but still need extra care when being put into time-critical chains (turning knobs like a mad or controlling via MIDI or something might be considered as time-critical at certain point).

but sin(x) is still the same sin(x) from a programmers point of view right?

Not just "sin(x)" but "C conforming sin(x)" (e.g. supporting all those #infs, #nans etc., e.g. with extra overhead, though typically many fpe libraries allow a sort of fine-tuning of such stuff)

Well, i think you won't have any problems with that
(Finally, if at some point one finds certain fpe function hindering he's not going to be frighted by finding/writing suitable approximation (not necessary less presice) right in fixed-point domain)

 

Hmmm,. I see. In that case, performance and RAM usage could indeed be a real 'show stopper' here.
I must say I was a little worried about that.

Not afraid of doing so, but I was kinda hoping to avoid these kind of exercises.