I2C Tinkering

A couple of posts ago I mentioned I2C.  I2C is a scheme for communicating with smart integrated circuits.  It is a bus arrangement where multiple devices are attached to a two wire bus, each device having a unique address.  This is very appealing in that it allows a lot of devices to be connected while using few pins.

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 acquired three I2C devices; an MCP23008 I/O expander, an MCP4726 12 bit DAC, and a MB85RC16V FRAM.  The DAC is obviously what we are interested in, but the I/O expander provides a very simple, easily visible, way to see that I2C is working, and the FRAM, while not especially useful for the 30F series of micros, could be quite handy with the 33F, 33E and PIC24 families.  In addition, the FRAM provided a third device to test I2C and more significantly, from another manufacturer (Fujitsu makes the FRAM, Microchip the other two devices).

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

The DAC was in an SOT-23 package, a mere 1.5 by 3 millimeters, which made soldering it to a FAR Circuits adapter board a bit of a challenge.  Worse, the adapter I had was for an SSOIC which has slightly wider pin spacing than an SOT-23, but close enough that it could be fudged.

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.