Influential Blog

This post is about how to set up a Gumstix Overo as an I2C bus master, with one or more Arduino devices as slaves. Here’s a picture of the basic set up:

Why? Gumstix and Arduino are two very different, but very awesome, open-source hardware projects. The 2” Gumstix board runs a complete Linux distribution on a 600 MHz ARM processor. Unlike a microcontroller, it’s not a very good fit for reading simple sensor data or doing stuff at precisely timed intervals. It’s also not for the kernel-mode faint of heart: to get things like external interrupts working you’ll have to roll your own drivers. However, with 256 MB of DRAM and up 8 GB of Compact Flash, you can do complex embedded processing tasks from the relative comfort of a Python script.

Arduino on the other hand is a simple AVR microcontroller board – a modern day Basic Stamp – with a huge user community that includes artists and designers as well as engineers. (User-written tutorials range from how to flash an LED to advanced high-speed photography of exploding Peeps Easter candies). While Arduino is pretty much the coolest thing to happen to microcontrollers since internal pullups, it’s fundamentally still an 8-bit micro that’s limited to simple tasks like reading sensors and turning servo motors.

I2C (Inter-Integrated Circuit) is a serial bus protocol that also goes by TWI, SMBus and “Wire” (in Arduinospeak). Although you should connect the Gumstix and Arduino through USB if you can (it’s less work), using up the Gumstix’s lone USB OTG port like this may not be acceptable in all cases and also runs up against a well-documented Arduino feature/bug by which the Arduino will reset every time you try to re-open a serial connection to it. If the Arduino is buffering sensor data to transmit to the more-sophisticated-but-less-I/O-oriented Gumstix, you obviously can’t have it do hard resets all the time. There are other solutions to this problem, but connecting the two through I2C is the one I’ll describe here.

Hardware I’m using this hardware:

1. Gumstix Overo Earth module + Summit expansion board - The Gumstix is our bus master. I2C port #3 on its OMAP processor is brought out on the Summit board’s 40-pin header as holes 23 (SCL) and 24 (SDA). The Linux i2c driver will expose this as /dev/i2c-3 as we’ll see in a moment.
2. Arduino Duemilanove - The AVR’s I2C port is brought out on Arduino’s analog pins 4 (SDA) and 5 (SCL). The Arduino will be the one and only slave device on our bus.
3. Logic-level Converter - Since the Gumstix uses 1.8V logic versus 5V logic on the Arduino, some logic level conversion is needed in between. The red SPE board takes care of this. Its inputs are confusingly labeled, though. Just use the two “TX” lines (which are bidirectional) and don’t try to understand why the terms “transmit” and “receive” were used on the board instead of “bi” and “uni”.

At the beginning of this post there was a picture of the complete setup. Here are close ups on each part of that picture (note that Gumstix is rotated 90 degrees CW to correspond w/ pinout):

Erratum #1: wire colors are supposed to be consistent as you go from left to right across the three pictures, but I screwed up the bottom one, which should have been yellow on both sides.

Erratum #2: short red wire jumping over level converter in the middle picture is not necessary. The two grounds are already joined by a trace on the SPE board.

Software For the software, the Arduino Wire library includes examples called “slave_sender” and “slave_receiver” that set up the Arduino as an I2C slave. In either case, we assign the Arduino an address and then it listens for that address to be asserted on the bus. Then, in the first example, it responds by sending back data. Here’s the code:

#include <Wire.h>
void setup()
{
  Wire.begin(0x11);                // join i2c bus with address #17 (0x11)
  Wire.onRequest(requestEvent); // register event
}
void loop()
{
  delay(100);
}
void requestEvent()
{
  Wire.send("hello ");
}

Now, on the Gumstix, we can use the command line tool i2cdetect to check whether anyone else is on i2c bus #3:

root@overo:~# i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- 11 -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

One device at address 0×11 (17 decimal). So let’s put a request on i2c bus #3 for that device and dump the response:

root@overo:~# i2cdump -y 3 17 i
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
20: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
60: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 68 65 6c 6c 6f 20 ff ff ff ff ff ff ff ff ff ff    hello ..........
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................