Part of the incentive here is to have a fast digital to analog converter. It seems inappropriate to talk about a microcontroller containing a DSP engine without using the DSP. Yes, we could do DSP calculations and display the results on an LCD or transmit them to the PC, but really, you would like to take audio from the radio, process it, and send it out to a speaker or amplifier.
Both of the dsPICs under consideration have A/D converters that are plenty fast for our purposes, but microcontrollers tend to be light on D/A capabilities. In most cases, however, there is a pulse width modulation output of sufficiently high frequency that it can easily be filtered to provide an analog voltage. This is fine if you want a DC voltage, but after filtering you are left with quite a low frequency AC. Probably not fast enough for our purposes.
Some years back I had done some unsuccessful experimentation with I2C, but this was done with 8 bit parts which are much harder to use. So it was time to do some more I2C experimentation to see if we could get an A/D that we could use for audio output.
|I2C Test Board|
I built up a board with a dsPIC30F4013 and the three devices for testing. If the I2C communications works out to be straightforward enough, I could put it on the "dsPIC-EL" and the loss of debugging capability for just I2C experiments might not be too high a price. (see the November 8 post, http://elmer166.blogspot.com/2012/11/decisions-decisions.html)
|DAC on adapter board|
After some initial struggles, I got the 23008 working and was able to use the same basic routines for the DAC with no drama. The DAC was kind of interesting in that is is the simplest of the devices, but had the fattest datasheet.
The FRAM caused me some consternation. The I/O expander can be tested merely by putting some LEDs on its outputs, and the DAC with a voltmeter. But the only way to see that the FRAM was doing it's thing was with the debugger and initially, it wasn't. Eventually I discovered that I had a cold solder joint on the FRAM, and once that was corrected, it behaved as expected.
I put all the tests in a git repository (https://gitorious.org/elmer166/ztest-4013-i2c-tests) with a branch for each test. After moving the I2C routines into a library, I made separate folders for libraries and include files. I need to come up with some sort of convention for "local" libraries and includes; putting them into the xc folders risks loosing them on upgrades, but most other possibilities seem to have rather ugly paths.
So, on to more considerations. After all this, it appears that the I2C DACs aren't going to be fast enough, either. The MCP4726 can take I2C at up to 3.4 MHz, but it requires extra bits to go beyond 400 kHz, further slowing the device.
I've avoided SPI because of the extra pins, but it does look like an SPI DAC is going to be the answer. Microchip's SPI DACs are cheap, and have a very compact protocol, and can take data at up to 20 MHz. Whether we can actually pass 20 MHz data on an ugly, hand wired board is another question. On the other hand, SD cards also take SPI, so that might lead to another interesting set of experiments.
So it looks as if the next move is to order some SPI DACs, probably MPC2822s or something similar.