Raspberry Pi digital control

Recently I’ve been wondering how hard it would be to drive a Shruthi filter board from a raspberry pi.

The Pi has 8 GPIO pins and a SPI interface. One of the GPIO pins is PWM enabled. From what I understand the PWM pin can be configured to output (~11-bit) audio from the kernel ALSA driver already. Real-time kernel patches are available to improve time-critical performance - not as good as a dedicated micro but probably usable. Theoretically it seems like a nice project.

Thoughts anyone? I’m especially interested in any potential showstoppers.

BCM2835 Datasheet:
http://www.element14.com/community/docs/DOC-43016/l/broadcom-datasheet-for-bcm2835-soc-used-in-raspberry-pi

There are no less than one bajillion expansion boards planned for the pi. I’m with you though that it would be coolest to do it without one.

There’s is the aout_lc which uses lots of resistors. The aout_ng costs a bit due to the number of channels and if you go to the trouble of doing a CV board you may as well have one with lots of channels.

Have a look at the CV out boards on MIDIBox?
e.g.
http://www.midibox.org/dokuwiki/aout_ng

I’d prefer to avoid adding another microcontroller, to keep things simple. It’s tempting though, I have a whole tube of Propeller chips that excel at spinning multiple PWM signals.

Thanks for the DAC suggestion and MIDIBox link, looks like a good place to start. It uses a pretty expensive DAC chip, at least from my local Farnell site ($37!). Might start looking for something cheaper…

@fcd: yes thats true. not sure how many IOs safetydank will need. several PWM for the filterboard, but probably also analog ins for pots etc.
i think using arduino might be the easiest way to get many outs and ins for the π. this will only be worth the trouble if you really need the processing power of the π and need to have it connected to the filterboard directly.

@olivier: i have not thought about this.

555 timers to the rescue!

Why PWM anyway? Given how fast this thing is, it wouldn’t be a big deal to bit-bang to a bunch of SPI DACs. Especially since this would be for the CV controls only - the audio itself could go through the pi onboard audio interface.

for what i understand there will be good support for hocking a arduino to the raspberry pi. maybe this will be a good way to get more PWM outputs to make the CVs for the filterboard.

maybe you can generate some PWM signal on the other GPIO Pins? Even a PicAxe can do 4 PWM Outs :wink:

@loderbast
if you hook an arduino to the π, why not use the arduino as standalone… wait… isn’t this any different from a Shruthi?

@6581punk Both! Using the control board <=> filter pins.

@fcd72 Yeah, one PWM won’t be enough for the control voltages…looks like it’ll need some outboard circuitry to do this.

Do you mean control the filter board or do you mean use the Pi board to generate audio which is then filtered by the filter board?

You will need at least 3 more 0…5V CVs for VCA, and the Filters F and Q…

Well time does go quickly when you have a rugrat to entertain…I finally got around to testing the Raspberry Pi GPIO outputs. To recap, the goal here is to drive a Shruthi filter board from the Pi. Here’s what I’ve found so far

The Pi has no onboard ADC. There are a few designs out there now, I have ordered a board with 8 channel ADC over I2C for testing.

Audio is produced on the Pi by an ALSA driver that uses PWM (1-bit PWM at 100mhz) to produce a signal on pins connected to the headphone jack. Effective audio resolution is 11-bits - or you can hook up an external card for full res audio. The ALSA driver interacts with firmware that runs on the GPU and this source is closed so there’s no way to see what’s happening inside it.

The control voltages seem like the trickiest part. I’ve run some bitbanging tests using the sample userspace GPIO C code and measured timings with a scope. Simply flicking a pin on/off runs at a variable rate, up to 5 mhz, with the CPU pegged at ~82%. As soon as you put a sleep inside the loop to control timing the rate drops drastically, to about 6.5khz, CPU usage about 30%. This looks like the lower limit for my kernel’s sleep calls, might be able to lower it by modifying kernel jiffies but at the expense of more CPU. It looks like bitbanging from userspace wouldn’t be able to handle 4 channels of DAC at close to audio rate.

An alternative is to use the kernel SPI interface to drive the DACs. I have a couple of MCP4922 boards and was able to write to them using the SPI kernel module. Chip select is handled by the kernel driver (maximum 2 devices supported), and I don’t see a way to utilize the LDAC pin (latch sync data of 2 DAC channels) through this interface. I haven’t tested writing a signal with a fixed frequency, and suspect that timing is going to be an issue. The SPI interface writes an array of words at a specified maximum frequency, but the timing isn’t guaranteed. I need to test this more to see if a signal can be generated with a reliable steady clock but the docs suggest it won’t work well.

Even if it is possible, I’m not sure how the control voltages can be synchronized with the audio signal. Assuming the audio data and control voltages are written at the same each device the ALSA driver and SPI drivers will exhibit different latencies, there’s no clear way to keep them in sync. I guess this is a similar problem to synchronizing multiple soundcards for output, something that’s never really worked on the PC.

There are still avenues to explore - bitbanging from kernel-space, perhaps using interrupts. Or a custom ALSA driver combining audio and CV outputs…if only the audio driver source was open. But it’s not looking great at this point. Any ideas welcome!

From my cynical and maybe naive perspective the ideal combo would be a Pi for numbercrunching and an Arduino for I/O handling-it’s interesting that Farnell’s planned I/O expansion board uses an ATMega and costs significantly more than an Arduino, bit like the Arduino ethernet shield costing more than a Pi…

Watch out also that I read you can’t use the 5v pin in the gpio header or you will blow your pie.

@gwaidan Yep, that’s what I’d like too. I haven’t found a way to get the audio-rate signals out of the Pi reliably from Linux. The more I research this the more unlikely it looks. You could make a killer sequencer though…

@Mdashdotdashn The GPIO pins use the 3.3V logic level, so mixing them with 5V signals from an Arduino could damage the Pi. You can safely convert between the levels using logic converters, basically simple FET circuits.

You should be able to set the Arduino to 3.3V levels however.

@safetydank What is that 8 channel DAC you selected ? What resolution does it provide ? I’d be interested to know for possible projects on the arduino :slight_smile:

Also I have no idea what at whet resolution the shruti internal manage to drive filter/cutoff/cv and the likes.

@Mdashdotdashn I’m not using an 8-channel DAC, just testing with 2 channels DACs at the moment (MCP4922). The aout_ng project uses the TLV5630IDW. There’s a lot of chips out there that could work though, some 8-channel DACs I’m looking at include the LTC1660, AD5318, AD5328 and AD5628.

I’m reconsidering my approach to this. Going to try using an offboard microcontroller to generate the control voltages in response to SPI messages from the Pi and see if syncing will be a problem.

Shruthi uses the AVR’s PWM for it’s control voltages, I believe it has 8-bit resolution.