Interfacing using Serial Protocols

Using SPI and I2C

By Paul Myers
pmyers@emrt.com
Senior Consultant
EMRT Consultants
www.emrt.com

Introduction
Communication between Integrated Circuits, cards and devices is a problem as old as the
IC. The application of parallel buses to all interfaces however, is not always a good
tradeoff between cost, convenience and required performance. The tried and true serial
bus is often a better solution when data transfer, is required between ICs on a board, in a
chassis or mezzanine or between IC subsystems connected by cables. When ICs require
interconnecting designers often first select components supporting I2C or SPI. Many
times both are used in the same design when component selection outweighs a clean
design utilizing a single standard interface.
This document discusses I2C and SPI, their history, summarizes their features, and
highlights reasons to use them and their limitations.

I2C
Overview
The I2C stands for Inter-IC and was originally intended to connect integrated circuits on
circuit boards or in circuit board based systems. Philips Semiconductor originally
designed the I2C bus in the 1980s. Philips originally intended the I2C Bus to be used
with devices within TV sets and video components. Today most major semiconductor
manufacturers offer ICs supporting I2C. Most device types support I2C such as
Processors, EEPROMs, Temperature sensors, A2D, D2A, Video components, Real Time
Clocks, Displays and even programmable devices like FPGAs can utilize I2C IP cores.

Technical Details
The I2C bus is a simple Master-Slave serial bus architecture. The bus utilizes only a 2wire connection. A serial data line, SDA, is used to transmit data to and from slaves. A
single serial clock, SCL, generated by the master and is used to clock data in or out of
slave devices.
The I2C bus glossary is short and simple. An I2C Transmitter is a device that sends
data on to the bus. This transmitter can be the entity that controls the bus, or in response
to a request from another device. The I2C Receiver is the device that receives data on
the bus from the Transmitter.

1 of 9

The I2C bus Master is the component that initializes a transfer, generates the SCL
clock, and ends the transfer sequence. The Master can be the Transmitter or Receiver
depending on whether it is writing to or reading from a device. The I2C bus Slave is
the device addressed by the Master and can be a Transmitter or Receive depending on
whether the Master is writing or reading.
I2C can be either a Single-Master or Multi-Master bus. A Single-Master as the name
implies has only one Master component and 1-N slaves. A Multi-Master I2C bus has 2-N
Master components and 0-M slave devices. Note Masters could access each other as
well.
Each device has a unique 7-bit or 10-bit address. A bit is used in the address to indicate
read or write operations. The data bus is 8-bit wide. The address is sometimes modifiable
by allowing the user to select alternate addresses by controlling some bits via external
pins, a software accessible register or other means to select other addresses as the default
to avoid conflicts. Masters transmit the address to communicate with a particular slave
on the bus.
A Multi-Master bus must have the ability for more than one master to share the bus
without losing data and to resolve collisions. Multi-Master I2C buses use Arbitration
which is a prearranged process, which allows only one Master to control the bus. In
effect if two masters are driving the bus, and one detects the data line is not at the value it
is supposed to be a collision is detected and that master relinquishes control to the other.
Masters can operate a Master-Receivers or Master-Transmitters depending upon whether
they wish to read or write. Also, I2C functions as a true multi-master bus by providing
collision detection allowing masters to detect when more than one master is driving the
bus and allowing for the winner to continue holding the bus and the losing master to
quietly give up to detect such collisions, perform arbitration for bus control and prevent
data corruption resulting in loss.
Since all Masters generate their own clock, clock Synchronization is performed by wire
ANDing the SCL clock lines of all devices. The SCL Clock low to high transitions
required to clock the SDA data line can only operate as fast as the slowest devices clock
period.
The I2C hardware interface implementation is kept simple as well. The electrical
interface is bi-directional and able to read and write on to the SCL and SDA pins. The
SCL and SDA pins are typically open collector or open drain. Pull-up resistors are
required on SDA and SCL of 2-10Kohms. The only limiting factor for the number of
devices on the I2C bus besides address conflicts is the bus capacitance, which must be
less than 400pF.
The Master drives the SCL clock line high to clock data into or out of a slave. All data is
transferred on the rising edge of a clock signal and the data line may not change while the

2 of 9

SCL clock line is high except in 2 cases. The protocol indicates the Start of a transfer
to a device by driving the SDA line low when the SCL data line is high. The Master
driving the SDA line high, when the SCL is high indicates an end of transfer to a device
or a Stop.
Between the Start and Stop bits the actual transfer between the Master and Slave device
occurs. The Master sends the Address 7 or 10 bits long terminated with a bit indicating
Read or Write. If the Slave device recognizes its address it acknowledges the transfer by
holding the data line low when the SCL is taken high by the master. If the SDA line is
high a Negative Acknowledgement or NACK is received. If a write is being performed
by a Master-Transmitter, subsequent data bytes are written to the slave and
acknowledged by the slave. If a Master-Receiver performs a read; then the Master
attempts to clock in data from the slave and acknowledges each byte read. A NACK is
issued by the Master to stop once the desired quantity of data bytes are read. Note that no
other master can take control of the bus until a Stop is sent to place it in the Idle state
again.

Protocol Description
The I2C bus uses a simple protocol. The Master transmits the Slave Address and a Read
or Write bit to indicate the direction of transfer.
A more complex protocol is typically built on top of this to read and write data locations
in slave device memory or register space.
A device write is performed by writing the Slave address, writing the address of the
memory location or register and then subsequent writes are used to these locations.
Oftentimes the device auto-increments its internal pointer.
A device read is performed by performing a device write writing the Slave followed by
the address of the memory location of register. A device read is then performed and the
device remembers the internal offset previously set and the read returns the byte
requested either a register or memory location. If an ACK is sent rather than an NACK
the slave device can then auto increment the pointer and read the next location until the
master sends a NACK.
More complex protocols can be created upon the simple read and write operations
supported by the I2C specifications.

Performance
The I2C bus specification supports three basic modes of operation providing different
levels of performance and device address spaces. The default mode is Standard speed
which ranges from 0 up to 100 Kbits/sec limited by the speed of the slave device. The
Standard mode has been around since the 1980s and provides 7-bit addressing.
The Fast Mode support up to 400 Kbits/sec and is again limited by the speed of the slave
devices. This mode supports new devices with 7-bit or 10-bit addresses. Fast mode is

3 of 9

backward compatible with Standard mode, however Standard mode devices are not
compatible with faster modes. Fast mode devices can prolong the SCL clock to slow
down the transfer cycle. The protocol format, electrical specifications, timing and use of
the SDA and SCL signals are the same as Standard mode.
High Speed Mode (HS) is the latest innovation that provides up to 3.4Mbits/sec data
transfer speeds. Hs mode maintains backward compatibility with Standard and Fast
modes allowing devices to be included. The electrical and timing specifications are
enhanced to allow High Speed operation.

Software Device Driver Requirement

I2C devices require somewhat more complicated device drivers than SPI, but there are
typically only a few issues to deal with such as avoiding reentrancy issues, real time
performance for devices and clock stretching for slow devices. Implementations of such
device drivers can be truly polled, or can utilize an interrupt.
I2C implementations are of two varieties. Those that use I2C-IP such as a processor or
PIC which has dedicated IP logic or a complete firmware bit banging solution.
The hardware solution typically consists of a microprocessor with a few dedicated
registers and an interrupt indicating completion of transfer or error. Data is loaded or
read from a data register, a control register is used for setting up transfers and a status
register is used for determining I2C bus status. At least one I2C Bus Controller, a kind of
UART, for I2C exists from Philips called the PCF-8584. This chip like the I2C capable
microprocessor uses a firmware driver to implement Master only, Multi-Master, or slave
implementations. Philips even provides a sample device driver for Master use.
The full bit banging firmware implementations of I2C require several levels of support:
Single Master, Multi-Master or Slave. Single master solutions are the simplest and
require only the means to send start and stop bits, send address, send data, receive data,
receive acknowledgments and reset the I2C bus. Such implementations use bi-direction
GPIO lines for SCL serial clock and SDA serial data lines.
Multi-Master implementations must additionally be able to detect that another master has
been detected and taken control of the bus. This is achieved by detecting that a data bit
driven by a master is not in the desired state. This indicates another master is driving the
bus and is in control. The first master which loses a contest for driving the value of a bit
on the data line SDA relinquishes control of the bus allowing the other master to
complete its transfer.
Slave devices are only required to detect their address, acknowledge address selection,
acknowledge data transfer, perform data transfers, and perform resets. I2C slave devices
can also support multiple read/write accesses as well to improve performance by
incrementing the current address location by 1 byte after each successful read or write.

4 of 9

It has been found that the polled versions of the I2C device drivers whether full bit
banging implementations or one using dedicated I2C-IP often are fine for most
applications. I2C device drivers utilizing interrupts and even a semaphore/thread
architecture result in faster performance and avoidance of task blocking and priority
issues in multi-threaded systems. But these complicated implementations of I2C device
drivers are infrequently used and are not often necessary.

Patent Issues
Philips still maintains control of the I2C specification and I2C Device address space
through licensing of the I2C patents and by assigning each I2C Device an address to
licensed device manufacturers.
Conventional wisdom has long been that manufacturers of systems utilizing I2C, which
create devices talking on I2C buses are covered by the I2C patent if one of the device
pairs, either master or slave is a licensed I2C device. This argument is suspect however,
except possibly with devices created to run on the Access.Bus specification.
Creators of PICs devices or processors using bit-banging GPIO and makers of FPGAs
using IP Cores which interface to I2C and advertise their products as utilizing this
technology or those creating ICs or subsystems for sale that interface to I2C may be in
violation of Philips patents. Philips position is that I2C devices are covered by patents
and only licensed IC manufacturers that sell devices or boards incorporating the
technology. A licensed manufacturer has already secured the rights to use I2C, relieving
the burden from the purchaser.
Philips maintains a license is required for implementing an I2C interface on a chip (IC,
ASIC, FPGA, etc). And it is Philips's position that all chips that can talk to the I2C bus
must be licensed. It doesnt matter how this interface is implemented. The licensed
manufacturer may use firmware bit banging, in-house IP, or purchased IP cores.
Philips handles FPGAs and ASICs using IP cores a little differently. Since the FPGAs are
programmed and ASIC are created using in-house and purchased IP Cores by the user,
the user is considered a company that builds an I2C-IC and would need to obtain the
license from Philips.
The original I2C patents filed in the 1980s for the Standard and Fast modes are to expire
in a few years. The High Speed patents filed later will still be in effect, but Philips will
need to modify its strategy for managing I2C address space and the specification when
the original patents expire.

Summary
I2C is a very useful IC interface when accessing device registers, memory and
peripherals are important. High-speed connections, which require data streaming, are not
well supported. Also, the Slave address protocol tends to direct device developers to a
Device Address/Location on device address type implementations. The biggest
advantages of I2C are it is widely supported, well known, supports a Plug-n-Play model
5 of 9

is not confined to single boards, scales well, can be used as a cable connection over
longer distances, and with the patents expiring sure to become ever more widely used.

SPI
Overview
Motorola originally designed Serial Peripheral Interface (SPI) for the MC68HCxx
processors to communicate with peripheral devices. The SPI implementation is very
simple, it is in effect a shift register used to shift data out and in. There is no real
established specification other than Motorola processors, which use it and application
notes, which gives adopters great flexibility but little guidance. The use of SPI is
widespread and is used by many IC manufacturers, ASIC and FPGA implementers and
peripheral devices. SPI can also be used for accessing EEPROM, Flash, A2D, D2A, Real
Time Clocks, sensors and other devices.

Technical Details
The SPI bus is referred to as a 4-wire full-duplex interface synchronous serial data link in
literature. This is mostly true. It is really a 3+N wire interface where N is the number of
devices connected to a single master on the bus. Only 1 master can be active on the bus.
Unlike I2C, SPI supports both 8 and 16 bit transfers. I2C is limited to 8 bit transfers.
Technically the SPI bus shift register length limits the size of the transfers. The transfer
size could be integer multiples of 8 bits.
The SPI is a single master bus with one master controlling N slaves. The SPI bus
supports Full Duplex capability between a Master and Slave device. The SPI interface
provides a synchronous serial data link. SPI has a simple hardware implementation. The
SPI uses shift registers to clock data in and out. Control and Status registers and
oftentimes an interrupt to indicate data ready or data transferred are provided.
SPI uses two data signals. The MOSI, Master Data Output, is the slave data output line.
This data line transmits output data from a slave into the master. Only one slave at a time
may transmit data. The MISO, Master Data Input, is the slave data input line. This data
line transmits data from the masters output to the slaves input.
There are two control signals. SCLK is the master clock, which clocks data to or from
the slave. The /SS signal is the Slave Select used to select each slave for control by the
master. SPI is better suited for data streams than I2C due to this slave select feature.
SPI has one hardware complication. There are two parameters associated with each
Master and Device relating to Clock Polarity CPOL and Clock Phase CPHA. These two
parameters decide where the active clock edge occurs. These parameters must match for
successful Master/Slave communications. At first this seems an inconvenience, but
actually results in greater compatibility with a variety of devices, which can be added to
the SPI bus.

6 of 9

Protocol Description
There is no SPI protocol per se. No slave addresses are required. Only a hardware select
line is used to select devices for access. Each device on an SPI bus may have its own
software protocol controlling access and control. Each master and slave must agree on
parameter value pairs or meaning of the data transferred. One important consideration to
note about the SPI bus is that no acknowledgement or flow control mechanisms are
provided. If these features are required SPI may not be the correct choice or these
features must be added on top of the SPI bus.

Performance
The SPI interface is generally higher performance than I2C. The SPI bus can support a
variety of transfer speeds but is limited by the system clock. The SPI interface is
generally capable of several mbits/sec data rates. The SPI interface is also more efficient
because it does not use addressing but rather uses a slave select line to enable a device for
access.

Software Device Driver Requirement

The SPI interface does not have a predefined protocol. SPI device drivers consist of
simply the firmware needed to load data to and from the shift registers, possibly an
interrupt handler and a set of access functions or a veneer to interpret the Control and
Status registers for the interface.
Like I2C protocols can be built on top of the SPI interface, however, these protocols
might differ from peripheral device to device. In effect the software architecture would
be a low level SPI interface layer and data transport moving bytes to and from the shift
registers with different high-level protocol stack drivers on top of the SPI transport to
handle different device behaviors.

Patent Issues
The SPI bus is broadly accepted because it has little or no patent issues. This is partly
because Motorola, its creator, provides no specification or central support. Those
applying SPI can create hardware and software solutions without patent issues, but also
without support or definition of supporting protocols.

Summary
The SPI bus is definitely the more versatile than the I2C. For point-to-point interfaces,
SPI is more efficient than I2C since it lacks addressing, is full duplex and supports
streaming. Embedded Systems creators can use it without patent issues. It is low cost,
high performance, protocol free, and requires simple firmware. The downside is that it
does not scale as well as I2C with multiple devices. Each device requires a slave select
resulting in greater hardware complexity. It quickly consumes more traces than I2C
does. And if the devices are very different in behavior each requires a different firmware
device driver to ride on top of the common SPI transport driver.

7 of 9

Conclusions
Both I2C and SPI can be used for initializing, configuring, and accessing IC components
and subsystems. I2C and SPI are both well suited for low bandwidth systems. SPI
appears to be better suited for streaming data and creating protocols, especially
considering the patent issues surrounding Philips High Speed version. The fact that the
original I2C patents are expiring may spur further growth, but Philips will need to change
how the I2C address and device maker licensing process works to accommodate this to
grow I2C adoption. Possibly an I2C manufacturers association needs to be created.
I have used I2C in embedded systems. I have even worked on mixed systems using both.
I have found both to work equally well for similar purposes. I have used the Philips PCF8584 I2C Bus Controller, I2C bit banging TI DSPs and FPGAs with I2C and SPI cores.
The complexity of the firmware for I2C and associated protocols can be a little greater
than SPI. However, SPI sometimes can result in more uncertainty since FPGA designs
and firmware protocols are often created just for this project. Bugs can be difficult to
track down in these cases, and oftentimes are not even the SPI interface but in third party
SPI components or simply initialization issues. (Though, I have found bugs in third party
I2C components, which consumed development time as well.) However, once created
and debugged the SPI firmware and FPGA core designs can be reused without any I2C
patent issues.
I can comfortably recommend both to embedded systems developers. I believe the key
tradeoffs will be what ICs you intend to interface, what their needs are and whether
streaming data must be moved will make your decision on whether to use I2C or SPI.
Now that I2C patents are expiring both SPI and I2C look increasingly equivalent.

References
Articles, Books and Papers
Application Note: Using the Serial Peripheral Interface to Communicate between
multiple microcomputers, Motorola, ANN91/D Rev. 1, 01/2001.
DesignCon 2003 TecForum I2C Bus Overview January 2003, Philips Semiconductors,
Jean Marc Irazabal and Steve Blozis.
Introduction to Serial Peripheral Interface, by David Kalinsky and Roee Kalinsky,
Embedded Systems Programming, 02/01/2002.
Introduction to I2C, by David Kalinsky and Roee Kalinsky, Embedded Systems
Programming, 07/31/2001.
Phillips Serial Bus Overview: UART, CAN, USB, 1394, SPI, and I2C/SMBus, 2003
PCF8584 I2C Bus Controller, Philips Semiconductor, Oct 21, 1997.
The I2C Bus Specification, Version 2.1, Jan 2000, Philips Semiconductor.

8 of 9

Serial Communications Using PIC Micro-Controllers, Square 1, Stevens, Roger,

1999, www.sq-1.com

Assorted Web links

www.chipcenter.com/circuitcellar/askus/apr00/Q3_00_72.htm
www.dbserv.maxim-ic.com/appnotes.cfm?appnote_number=356
www.epanorama.net/links/serialbus.htm
www.esacademy.com/myacademy
www.motorola.com/brdata/PDFDB/docs/M68HC11RM.pdf
www.motorola.com/brdata/PDFDB/docs/M68HC05AG.pdf
www.dmoz.org/Computers/Hardware/buses/I2C
www.pcwebopedia.com/hardware/buses
www.pcwebopedia.com/terms/i/i2c.htm
www.pcwebopedia.com/terms/s/spi.htm
www.ping.be/~ping0751/i2cfaq/i2cindex.htm
www.semiconductors.phillips.com/buses/I2C
www.semiconductors.philips.com/buses/i2c/licensing/index.html
www.semiconductors.philips.com/buses/i2c/faq/
www.semiconductors.philips.com/buses/i2c/index.html
www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFICATION_3.pdf
www.stanford.edu/class/ee281/presentations/aut2002/eugeneho-serialcomm.ppt

Comments
1. Contact Phillips for licensing information, documents or listed presentations.
2. Motorola provides little documentation or support other than above links and
application note.
3. There are a lot of very good presentations and resources available online
regarding SPI and I2C. Please consult some of the above.

9 of 9