Linking 2 MCUs: I2C, SPI, or a Home Grown Interface?

Max could use an existing protocol like I2C to communicate between two devices, so why would he want to create his own?

Once again, I've been contemplating, cogitating, and ruminating on my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display. In my previous blog on this topic, I focused on the physical implementation of the presentation cabinet and its display and control panels. Today's musings are on the electronics side of things.

Have you ever noticed how each design decision has a ripple-on-effect that influences other decisions downstream? For example, my decision to use Adafruit's NeoPixel Strips -- the type with 30 NeoPixels per meter -- means I have to use my Arduino Mega microcontroller development board to drive the display. This is because I'm also using Adafruit's NeoPixel libraries, which only run on Arduino Unos and Megas.

Of course, I know that there are other possibilities. For example, I could use an FPGA to perform the DSP spectrum analysis and drive the display. However, this would actually end up slowing me down. Why? Well, I'm currently thinking of this project as having the following major elements:

Build the display itself

Start playing with the display and experimenting with different effects

Decide how to implement the spectrum analysis functionality (and then actually implement it)

Use the spectrum data to feed the display

I'm currently working on building the display itself. As soon as that's done, I want to start playing with it. If I were to use an FPGA to drive the display, I'd have to spend some time and effort getting everything up and running. By comparison, using the Arduino Mega means I can dive right in with gusto and abandon -- I can be literally flashing my LEDs in a couple of seconds.

This also explains why I'm not looking at using one of Cypress Semiconductor's PSoC 5LP (Programmable SoC) devices. I know these little rascals contain a 32-bit ARM Cortex-M3 microcontroller along with programmable analog and programmable digital fabric. Also, I recently learned that there is a library available that can be used to manage the same controllers that are used in Adafruit's NeoPixels. Sad to relate, however, I've never actually played with a PSoC, so once again I would have to spend time learning "stuff" -- and this is "quality time" I could be using to play with my LEDs.

The bottom line is that, initially, all I will have will be my Arduino Mega driving the LEDs on my BADASS display as illustrated below. In reality, I could use a single digital output to control all 256 LEDs, but the Arduino Mega has 54 digital input/output pins to play with, so I think it will be easier to use a separate pin to drive each column in my display.

In the fullness of time, I hope to end up with a lot of cunning display routines that I can use to present my spectrum data, but therein lies the rub...

I want my Arduino Mega to focus all its attention on driving the display and providing me with cool effects like peak-hold and fading pixels and falling pixels and suchlike. This means that I will eventually be looking at using another device to read the analog audio data stream and extract the spectral components using appropriate DSP algorithms (the nitty-gritty details of which will form a discussion for another day).

This other device could be an FPGA or it could be another microcontroller development platform. In the case of the latter, one platform I'm definitely considering is the chipKIT Max32, which boasts a 32-bit PIC32 microcontroller from Microchip. In addition to having exactly the same physical footprint and connector map as the Arduino Mega (making it easy for me to wrap my brain around), this little beauty runs at 80 MHz and has 512 KB of flash program memory and 128 KB of SRAM data memory.

Now, you might be wondering about the Arduino Due, which is also a 32 bit machine. At 84 MHz, the Due runs a tad faster than the Max32; the Due has 512 MB of Flash just like the Max32; and it has 96 KB of SRAM, which is 32 KB (25%) less than the Max32. If I've learned anything in this life, it's that more SRAM is generally a good thing (LOL).

Another point against the Arduino Due is that it runs at 3.3 V, as compared to the Arduino Mega, which runs at 5 V. This could be problematical when it comes to connecting the two together, because the Arduino website warns that providing higher voltages like 5 V to an I/O pin on the Arduino Due could damage the board. The chipKIT Max32 also runs at 3.3 V, but the folks at Microchip assure me that its digital I/O pins will tolerate 5 V signal levels.

But we digress... Whatever device I choose to implement the DSP algorithms to perform the spectral analysis, I'm going to need some way to connect it to my Arduino Mega as illustrated in the following diagram:

Two potential interface schemes that immediately spring to mind are SPI (Serial Peripheral Protocol) and I2C (Inter-Integrated Circuit). But should I use one of these, or should I develop my own?

The obvious first question is "what's your data rate?" I2C is pretty slow: it was originally designed for passing control information between digital components in early TVs with digital chips. OTOH, I2C is very forgiving electrically: I2C components include input filtering so it doesn't matter if your SDA and SCL are ringing. This is nice if you're going between boards.

SPI can run much faster, but you have to ensure good signal integrity on your clock.

If you're running very slow, you might consider UART. Then you can debug each board separately using a terminal emulator on a PC. You need to get a USB to UART dongle with the correct voltage for UART signals for your board. Here's one from Adafruit http://www.adafruit.com/products/954.

You can also get dongles that talk I2C or SPI and talk to your boards individually from a PC, or monitor what's happening on the line. However, then you have to write I2C/SPI code on your PC which could be a steeper learning curve than using your embedded boards. Still, here are some cables from FTDI: http://www.ftdichip.com/Products/Cables/USBMPSSE.htm.

As an aside, while I was writing this column, my inventer friend Brian LaGrave dropped by my office with his two sons (Sam and Daniel) bearing gifts -- two large plastic coffee containers -- one loaded with cow manure and the other loaded with horse manure.