Keith's Electronics Blog

Cort and I are good friends and both interested in electronics, but have had surprisingly little opportunity to work on electronics together. He’s an amateur radio operator and very much into RF design, and I’m more interested in physical computing.

So when he started describing his receiver voter project and suggesting that I might be able to help out on some of the digital interfacing, I jumped at the opportunity. A radio repeater receives transmissions at one frequency and rebroadcasts them at a nearby frequency, effectively boosting the signal (by repeating it) without increasing transmission power over the legal limit.

The voter picks the best signal from several different receivers (possibly several miles apart, linked back to the repeater base) and routes it to the repeater. And Cort’s voter will have lots of pushbuttons, LEDs, and digital controls — more than he could wire directly to the Arduino he’s planning to use to control it.

That’s where I come in. Cort is very interested in learning the Arduino, but he hasn’t done much with microcontrollers lately and is to some extent playing catch-up with a decade’s worth of advances in technology. So I’ll pitch in and give him some ideas and programming assistance on the digital I/O.

I²C I/O Expansion

I started by looking for digital I/O expansion chips, and I did not start by looking for I²C. I’ve never worked with I²C before and I thought I’d find something with SPI, but oh no, that was not to be the case. Nearly everything I could find — and everything I could find that was readily available and affordable — used I²C. This is actually a good thing — I²C uses only two interface pins to talk to up to 127 devices, and SPI needs two pins for the bus plus a separate chip select line for each device — but it wasn’t what I was hoping for when I started looking.

So I ordered some samples, warmed up by trying to interface to an I²C EEPROM I had lying around (with no luck whatsoever, although I now know several things I did wrong and will go back to it soon), built some breakout boards, and got I²C communications up and running on the Arduino this weekend.

And the number of mistakes I made along the way was staggering. Not just little misunderstandings, but mind-numbing stupid mistake after stupid mistake, things I’ve know better since I was six. With a weekend like this, it’s a wonder I haven’t run over myself with my own car somehow.

So do what I say, not what I did.

Arduino I²C

First off, I had to get the Arduino talking to I²C. There’s not much online about doing I²C on the Arduino, and the most useful for me was Julian Bleecker’s blog post prosaically entitled Arduino and the Two-Wire Interface (TWI/I2C) Including A Short Didactic Parenthetical On Making TWI Work On An Arduino Mini.

It turns out there’s a Wiring library called Wire (why not, oh, say, I2C???) that operates the ATmega’s hardware I²C port and which has been incorporated into the Arduino software since version 6, so everything I needed was right there; I just had to figure out how to hook it together.

Between the Wire documentation being sketchy and not explaining how each function corresponds to an I²C function, its code examples being outdated and occasionally incorrect, my lack of familiarity with I²C in general, my not yet having a working I²C circuit to reference, and of course my many, many mistakes, this made for a bit of a vexing experience.

Let’s do it.

Give up analog pins 4 and 5

Analog pin 4 doubles as the I²C SDA (serial data) pin, and analog 5 doubles as SCL (serial clock), so you don’t get to use them any more. I like to put a comment at the top of my code to remind myself which pins I’m using and what they should be wired to, so:

/******************************************************************************
 *  i2c_gpio
 *  Keith Neufeld
 *  May 26, 2008
 *
 *  Prototype I2C interface to TI 9535 and 9555 GPIO expanders.
 *
 *  Arduino analog input 5 - I2C SCL
 *  Arduino analog input 4 - I2C SDA
 *
 ******************************************************************************/

Pull the Wire library into your project

#include <Wire.h>

This gets you declarations for the functions you’re going to be using, and magically tells the linker to look in the Wire library for functions you’ve referenced.

Set your I²C device address(es)

I’m an old C programmer, so I like to #define constants at the top of my program rather than hard-code them where they’re used. And the parens around each definition protect it from order-of-operation errors, since #defines are substituted lexicographically by the preprocessor, with no intelligence whatsoever about your intentions. (If this doesn’t make sense, don’t worry about it and just remember to put parentheses around numerical and variable #define substitutions.)

//  I2C device address is 0 1 0 0   A2 A1 A0
#define DIP_ADDRESS (0x4 << 3 | 0x0)
#define LED_ADDRESS (0x4 << 3 | 0x7)

---

[Update 03-Jun: The WordPress HTML monster ate my operators! Corrected DIP_ADDRESS and LED_ADDRESS to both be << 3 . Thanks, Kenneth!]

---

An I²C device address is seven bits. The I²C section of your datasheet will talk about the eight-bit address byte including the data direction bit (R/W), but this is a trick. ("Get an axe.") The Wire library will take care of the data direction bit for you automatically on each operation you perform, so you need to give it only a seven-bit address.

In my prototype, I'm using two different chips with the first four device address bits "burned in" at 0100 and the last three bits controlled by address pins on the chip, so you can use eight of these on one bus. I have one with all the address pins tied to ground (000) and another with all the address pins tied high (111), and I'm "OR"ing together the burned-in fixed bits and the values that I have the variable bits set to.

First mistake: Make sure you know how to convert from binary to hex (or decimal). It turns out that binary 0100 isn't hex 0x8, and it also turns out that the chips don't respond to an address that isn't their own. Seventeenth mistake: Make sure you remember how many hardware address lines you have. It turns out that binary 111 isn't hex 0x3, and it also turns out that chips don't respond to an address that isn't their own.

Sigh.

Initialize the Wire library

void setup() {
  // ...
  Wire.begin();
  // ...
}

Wire.begin() initializes the Wire library as an I²C master and reconfigures analog pins 4 and 5 as I²C pins. Wire.begin(address) (not used here) initializes the Wire library with the Arduino functioning as a slave at address address, useful if you want to use the Arduino as an I/O expander for another Arduino, build a BlinkM, or something like that.

Do some I²C output

From here on out, everything is specific to the device you're trying to control. Since I went 'round and 'round (what comes around goes around, I'll tell you why) on this before I got it working, and you probably won't be using exactly the same chips I am, I want to go through the datasheet and talk about how to translate the timing diagrams (correctly) into Wire code. And I'm going to cover writing to the device first, because curiously that's easier than reading.

One thing that's important to keep in mind throughout is which level we're discussing at any given time. Transmitting on the I²C bus is not the same as writing to a bus device's registers, which is not the same as causing a device to output on a pin. Unfortunately, all of these are called "write" by different documents in different contexts.

My samples that arrived first are Texas Instruments PCA9535 and PCA9555 16-bit I/O port expanders, so that's what I'm using. These chips give you sixteen additional digital I/O lines; you just supply power, three configurable address lines, and I²C. The chips are identical except that the 9555 has internal pull-up resistors, so I'm using the 9555 for inputs and the 9535 for outputs (where the pull-up is unnecessary and would add to the power draw when outputs are low).

The chips have eight one-byte registers, divided into four pairs for the sixteen bits' worth of input, output, polarity inversion, and data direction. To output data on the chip's pins, configure the pins as outputs by writing 0s into the data direction registers (they default to inputs), then write data to the output registers. To write to a register, send the chip the register address followed by the desired data. A write to one byte of a two-byte register pair toggles the register address to the other byte of the pair, so we can write both registers of a pair consecutively (in either order) without retransmitting the register address in between.

Working through the timing diagram one section at a time (open in another window if you want a bigger version to follow along), the slave address including the R/W bit is sent automatically by the Wire library when you call Wire.beginTransmission(address) . "Acknowledge from Slave" happens under the covers. The command byte is the address of the desired register, in this case 6 for the data direction register, which is transmitted by calling Wire.send(data) ; and again, the acknowledge happens automatically. Data to ports 0 and 1 is transmitted by calling Wire.send(data) for each byte desired. Finally, the transmission is terminated by calling Wired.endTransmission() .

Here's how it looks all put together in my code:

#define REGISTER_CONFIG (6)

void gpio_dir(int address, int dir) {
  //  Send config register address
  Wire.beginTransmission(address);
  Wire.send(REGISTER_CONFIG);

  //  Connect to device and send two bytes
  Wire.send(0xff & dir);  //  low byte
  Wire.send(dir >> 8);    //  high byte

  Wire.endTransmission();
}

Note that I'm sending the low byte first, then the high byte. I could just as well select the high byte of the configuration register (address 7) and transmit the high byte first, then the low byte, since the register address always toggles to the other byte of the current register. (It doesn't advance to the next register address as it does in some other types of chips.)

Having set the pins as outputs by calling gpio_dir(address, 0x0000), I can then output data on the pins with a gpio_write() function:

#define REGISTER_OUTPUT (2)

void gpio_write(int address, int data) {
  //  Send output register address
  Wire.beginTransmission(address);
  Wire.send(REGISTER_OUTPUT);

  //  Connect to device and send two bytes
  Wire.send(0xff & data);  //  low byte
  Wire.send(data >> 8);    //  high byte

  Wire.endTransmission();
}

Note that as these two functions are identical except for the target register address, they should really be abstracted into a gpio_register_write() function and two calls to the new function. For today, I just wanted to get a prototype up and running; for later, I'll build this into a proper object-oriented library that lets you create GPIO objects and call pinMode(), digitalRead(), and digitalWrite() on them like on the Arduino's native I/O pins (as well as still reading/writing them in bulk like I've done so far).

Do some I²C input

Assembly is the reverse of disassembly, right? Well, no. In order to read an input, you have to select the input register; and you select the input register by transmitting its register address.

So here's where I made mistakes five through sixteen; masked, of course, by the fact that I was transmitting to the wrong device address most of the time.

The first part is the same: send a device address by doing Wire.beginTransmission(address), and a register address (command byte) by doing Wire.send(data) . Then notice the "S" in there? That's another I²C start, i.e. Wire.beginTransmission(address) , and you have to do a Wire.endTransmission() first. (I tested lots of combinations before getting this right . . . and ultimately what I think I remember as my first hunch was correct, had I only been using the right device address at the time.)

Now send the device address again with another Wire.beginTransmission(address) , after which everything else is new. Instead of writing, we need to read; and the way to do that is Wire.requestFrom(address, numbytes) . (For the curious, as I understand it, the I²C master keeps clocking even during a read and the slave only manipulates the SDA line; so the master controls the number of bytes in the transfer and does need to know how many bytes are expected.)

Wire.receive() delivers the byte read from the wire, but the Wire library and the example code all show using if (Wire.available()) to check whether a byte was actually delivered before reading it. From my experimentation, I don't think this is actually implemented (or implemented correctly), and it's not like I can throw an exception if there's nothing there to read, but I'll go ahead and use it. (Laddie good boy!)

And here's mistake number somethin'-or-other (and the most embarassing one): Make sure that you actually return that value as the result of your function. If you just fall off the end of the function, you always get 0 back. Arrrrrgh.

All together now:

#define REGISTER_INPUT (0)

int gpio_read(int address) {
  int data = 0;

  //  Send input register address
  Wire.beginTransmission(address);
  Wire.send(REGISTER_INPUT);
  Wire.endTransmission();

  //  Connect to device and request two bytes
  Wire.beginTransmission(address);
  Wire.requestFrom(address, 2);

  if (Wire.available()) {
    data = Wire.receive();
  }
  if (Wire.available()) {
    data |= Wire.receive() << 8;
  }

  Wire.endTransmission();

  return data;
}

I/O Expansion in Action

And thar she be. I'm reading a PCA9555 (has internal pull-ups) on the left with a DIP switch on port 0 pins 0-3 (left to right) and writing a PCA9535 (no pull-ups) on the right with LEDs on port 1 pins 4-7 (right to left). I deliberately put the LEDs on different pins of a different port in a different order to make sure I was successfully exercising every portion of the device. Flip the switches and turn the LEDs on and off, woo hoo, we're havin' some fun now!

All the Code

Here's the whole program: i2c_gpio.pde

I'll post a better version when I get it converted to a proper library.

This entry was posted on Monday, May 26th, 2008 at 03:47 pm by Keith Neufeld and is filed under Arduino. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.