Nuts and Volts - May 2014

I've been a fan of I2C since my days with the BASIC Stamp (the BS2p family introduced I2C instructions to PBASIC). The I2C protocol is such an integral part of the Propeller I kind of assumed everybody understands and is as comfortable with it as I am. Then, an odd thing happened. I got a ton of private messages through the Parallax forums by other enthusiasts that were struggling with I2C.

Let's see if we can do something about that, shall we?

Propeller Boot-Up Sequence

We're going to start with the boot-up sequence because an I2C EEPROM (24LC256 or larger) is connected to the Propeller to store the program and non-volatile data. Pins 28 and 29 are used for the I2C buss that connects to the EEPROM. Pin 28 is SCL (clock);

pin 29 is SDA (data). Once you're comfortable with I2C, you can connect other devices to these pins.

When the Propeller comes out of a reset, it checks to see if that reset was caused by an IDE (Integrated Development Environment) wanting to download new code. This is a serial transaction on pins 30 (TX) and 31 (RX). If no IDE is detected, the Propeller will copy 32K of data from the EEPROM into the hub RAM. The boot loader copies a Spin interpreter into cog 0, and the program takes off from there.

This sequence after reset is the only time that the Propeller demands control of pins 28/29 (I2C) and 30/31 (serial). That said, I don't think it's a good idea to assign these pins to activities other than what they do in the boot sequence. That is to say that I always use pins 28/29 for I2C if I need it, and pins 30/31 for serial (usually debugging) if I need it.

The serial pins are a point-to-point connection, but I2C is a multi-drop buss. We can take full advantage of this.

I2C Basics

First things first (and another blindingly obvious statement considering the previous section). I2C is a two-wire synchronous communications protocol. What this means is that the SCL line controls the movement of data on the buss; speed of the transaction is determined by the bit rate of the SCL line. You'll typically see parts specified at 100 kHz or 400 kHz — some even higher.

To keep things easy we're going to write an I2C driver in Spin, so it will be slower. That's okay; the synchronous nature of the buss allows for this.

The I2C protocol does support "multi-master" systems, but we're not going to get into that. In our code, the Propeller is the master; the EEPROM and anything else we hang on the buss are considered slaves. The master initiates and controls the transactions on the buss. Slaves are identified by a device type and (usually) a three-bit address. The combination of device type and address is called the control byte or slave ID.

For example, the EEPROM used for holding the program is at address %000. If we wanted additional storage space, we could hang another EEPROM on the buss and set its address to %001.

Oh, Say, Can You I2C?

At the risk of stating the blindingly obvious, we human beings are an interesting lot. Our ability to live in denial and make silly assumptions is remarkable. My acting teacher — the late Cliff Osmond — used to point out that we all know we're going to die, yet we live our lives as though that day will never come. As electronics and programming enthusiasts, we often assume that if something is really simple to us, then, of course, everybody else knows and understands it too. Yet, this is not always the case. In fact, it's frequently not the case at all. If I'm honest, I'm a little guilty in my Propeller forums posts of treating some topics as if everyone knows and understands them. I2C has been one of those topics.