Simple DSP Platform

[Gurner]

I'm fancying dipping my toe in the DSP water - any idea how much current these things draw (I realise that gonna depend on the task expected of it) - more of a ballpark figure for say a simple delay. I'd hope to be able to use some form of lithium batter based supply...but obviously if the draw is too chunky, I'd have to rethink!

[markseel]

These two DSP boards (10 pin SIP and 20 pin DIP) draw about 50 mA.

Keep in mind that this DSP has 1024 words of sample memory (good for 22 to 32 milliseconds of delay depending on sampling rate).
If your effect is primarily delay then you should examine the SpinSemi FV-1 as an alternative (32K of sample memory for almost 1 second delay at a lower sampling rate).

If you're voltage supply is well above the required minimum voltage of the DSP module (around 3.5V) then you can use a switched capacitor voltage divider (consists of one IC and two caps) to reduce current draw from the battery.

For example; The DSP board needs 3.5V.  A 9V batter with a switched cap voltage divider operating at 90% efficiency would result in about a 28 mA load on the 9V battery.  The batteries minimum voltage (as it wears out) would then be around 7.2 volts.  That's maybe 10 to 20 hours of run-time for an 9V alkaline.

50 mA (just the board with a battery) isn't too bad but the voltage divider (extra work) is an option.  I'll be using these for my pedals.

The switched cap voltage converter I'll be using is the ICL7660 - one chip and two caps - easy!

[ExpAnonColin]

Hey - sorry to jump in late, interesting work.  A couple of questions/comments -
1) Does the DSP do all the listed instructions in one cycle, and all in floating point?  If not, can you point to a resource for approx number of cycles for each instruction?
2) To expand I/O, could you use the 3 serial outputs (or 2 of them, or whatever) as binary outputs for an analog multiplexor?  I have difficulty playing with systems with a fixed amount of I/O, and allowing it to multiplex would make it more powerful IMO.
3) The python assembler is interesting, but are there any dialects of C that compile down to this assembly?  It would be really slick to implement a system where you had a separate control loop and DSP loop - the control loop for reading in pots, inputs, etc, and the DSP loop for the actual DSP code (potentially in assembly).  It seems like your system is kind of like that, but it's not clear!
4) Can you post any basic code using the ADC (non-codec) inputs?  If you already have, apologies, I didn't see it!
5) I'm curious as to what SNR you're getting with the system.  With the 24-bit ADC/DAC I'm sure there's no problem there but there must be noise creeping in from the circuitry to some extent, right?
6) An 8-channel version would be cool, especially for synth systems! Stereo is sufficient 99% of the time though, I'm sure!

Anyways, very cool stuff, would be happy to beta test.  Honestly I have been a bit torn lately as to whether it is smarter to make dev boards for DSP like this on actual dedicated DSPs or with just a powerful MCU like an ARM Cortex m3.

-Colin

[markseel]

Great questions!

1) All DSP instructions are single cycle.  In general the math operations use a fixed point format for fractional math.  I believe the accumulator is 28 bits (one sign bit, 3 integer, 20 fractional).  There are some integer operations that seem to be included for the purpose of table look-ups.

2) The 20-pin board has the 3 remaining DSP outputs routed to board pins.  I was going to use them to drive led's but your idea sounds cool - you could use these 3 pins, under DSP program control, to route other analog signals into the ADC using an analog multiplexer.

3) I don't know of any language compiler for this chip.  If there were something like that available it would have to be reduced to conform to the programming model of the DSP-1K in that there's one big sequence of math operations, I/O operations and forward-only jumps executed each sample period.  No other forms of branching beyond forward jumps is supported.  None-the-less it would be nice to program this device using math expressions and variable allocation/assigments like in higher level languages.  Maybe I'll write one (or someone else can!) someday if the device/board becomes more popular.

4) I think you're referring to the three unused inputs of the DSP chip, right?  The Wavefront Semiconductor web site has some application notes on using these inputs as low speed delta-sigma ADCs.  The AL3102 has 4 inputs and 4 outputs.  The codec on the board using 1 input and 1 output for analog stereo in and stereo out.  The remaining 3 outputs are exposed for the user and can be used with more DAC's or as general purpose digital outputs.  The remaining 3 inputs are NOT exposed but if they were they could be used with more ADC's or as general purpose digital inputs.  If there's interest I can change the board layout to expose these inputs.

5) I haven't measured SNR yet.  When I hook up the system it seems a bit noisy but then the input is my guitar plugged into an exposed jack that's wired to a breadboard with no shielding.  The boards really small - not sure if that's good or bad for noise.  I kept the analog supply separate from the digital supplies (separate linear v-regs) and the analog and digital ground traces connect at one point -the ground pin on the board.  The mid-supply voltage reference for the CODEC's internal analog has 0.1uf and 10uF caps to ground.  The board is too small for a ground plane unless I change from 2 layers to 4 layers.  It's possible there's digital and RF noise finding it's way into the analog (well, there is of course but the question is how much) but I'm not sure how many of those 24 bits will be flipping around due to noise yet.  I'd love feedback/measurements from others though!  I will do my own when I get the time.

6) Right on, eight channels would be pretty cool.  I guess that would be a different board though with a different CODEC or ADC's/DAC's.  Since that might be a different application space then the requirements I had for this board (small, stereo, low power) might not be as important.  Suggestions are always welcome.

You'd beta test?  I'll send you a board!  Can you email me (mark.seel@gmail.com)?

I've thought about using other embedded u-controllers, CPUs or DSP's.  The small u-controllers have small word sizes, are slow when implementing fixed point fractional arithmetic and don't have I2S interfaces (you have to use SPI/I2C or parallel interfaces for ADC's/DSP's).  I've seen projects for delay/echo using these but for non-linear wave shaping they're a no go.  The more complicated embedded CPU's (ARM immediately comes to mind) seem fast enough.  But they require more firmware work since they use more conventional (and therefore more flexible) programming models.  'C' compilers exist for them.  Don't seem to interface to DACs/ADCs/CODECs very easily.  Some have pipelines and instruction cache.  Low latency real time audio work needs appropriate interrupt driven firmware - too much work for me!  The general purpose DSP's are pretty much the same except that they interface to the analog sections easily.  They still need more firmware work than I'm willing to do (that's what I do for a career - wireless communications for power and memory constrained hearing aids - don't want to do it for a hobby!).  The only firmware I've had to write is for the Atmel that allows DSP programs to be downloaded to flash, the DSP loaded and CODEC initialized on power-up, and the pot values updated to the DSP memory during run-time.

Sorry for the long post!

[ExpAnonColin]

Hi Mark, great info, thanks!  What I meant about the unused, non-codec inputs are the ones you're using for pot inputs - do you have any code examples for that?  Anything simple.  I am just having trouble visualizing how the AVR writes those values so that the DSP can use them. u If it's in a code example posted and I missed it, let me know!  Re: Noise, I will attempt to check this out on the beta board .  I would say it is worth the extra couple of bucks for the end-user for 4 layer in order to squeeze the maximal precision out of 24-bit.  One thing worth mentioning about the ARMs is that they actually do interface with codecs rather well as many have I2S built in!  Other than that, I do agree that they don't necessarily conform as well to interrupt-driven firmware, but I do think they could be smart for a lot of audio apps.  Anyways, I will shoot you an email!  Thanks again for the info,

-Colin

[markseel]

The non-audio analog inputs are connected to the low speed ADC inputs on the AtTiny84 u-controller.  They're intended to be used for pots but they could be used for other stuff of course.  The firmware in the u-controller writes to DSP memory over a two-wire serial interface with these low-speed ADC's values.  The DSP memory that is written to is at address 0x40A through 0x40F - 5 registers of the DSP-1K's 16 register area.  The DSP-1K refers to these 16 bytes as registers in order to differentiate them from the 1024 words of sample memory.  The u-controller firmware will write ADC values when an ADC value changes.  Hysteresis is used to prevent constant writes to the DSP since constant writing to the DSP over the serial bus consumes power and may cause subtle audio artifacts - hope not - testing needed.  Does this help?

[ExpAnonColin]

The non-audio analog inputs are connected to the low speed ADC inputs on the AtTiny84 u-controller.  They're intended to be used for pots but they could be used for other stuff of course.  The firmware in the u-controller writes to DSP memory over a two-wire serial interface with these low-speed ADC's values.  The DSP memory that is written to is at address 0x40A through 0x40F - 5 registers of the DSP-1K's 16 register area.  The DSP-1K refers to these 16 bytes as registers in order to differentiate them from the 1024 words of sample memory.  The u-controller firmware will write ADC values when an ADC value changes.  Hysteresis is used to prevent constant writes to the DSP since constant writing to the DSP over the serial bus consumes power and may cause subtle audio artifacts - hope not - testing needed.  Does this help?

Yes, absolutely!  That makes sense.

-Colin

[markseel]

I have Python files (beta) for developing/downloading/simulating DSP programs ready.
If anyone wants to see how the Python-based development works you can get the files at:
http://sites.google.com/site/nextaudiodsp/