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.
60 May 2014
; BY JON MCPHALEN THE SPIN ZONE
Post comments on this article and find any associated
files and/or downloads at www.nutsvolts.com/index.php?/
magazine/article/may2014_SpinZone.