Download I2C Background

I2C Background
Contents http://www.totalphase.com/docs/articles/article01/
History
When connecting multiple devices to a microcontroller, the address and data lines of each
devices were conventionally connected individually. This would take up precious pins on the
microcontroller, result in a lot of traces on the PCB, and require more components to connect
everything together. This made these systems expensive to produce and susceptible to interference
and noise.
To solve this problem, Philips developed Inter-IC bus, or I2C, in the 1980s. I2C is a
low-bandwidth, short distance protocol for on board communications. All devices are connected
through two wires: serial data (SDA) and serial clock (SCL).
Figure 1: Sample I2C Implementation.
Regardless of how many slave units are attached to the I2C bus, there are only two signals
connected to all of them. Consequently, there is additional overhead because an addressing
mechanism is required for the master device to communicate with a specific slave device.
Because all communication takes place on only two wires, all devices must have a unique
address to identify it on the bus. Slave devices have a predefinied address, but the lower bits of the
address can be assigned to allow for multiples of the same devices on the bus.
Theory of Operation
I2C has a master/slave protocol. The master initiates the communication. The sequence of
events are:
1. The Master device issues a start condition. This condition informs all the slave devices to listen
on the serial data line for instructions.
2. The Master device sends the address of the target slave device and a read/write flag.
3.
4.
5.
The Slave device with the matching address responds with an acknowledgement signal.
Communcation proceeds between the Master and the Slave on the data bus. Both the master
and slave can receive or transmit data depending on whether the communcation is a read or
write. The transmitter sends 8-bits of data to the receiver which replies with a 1-bit
acknowledgement.
When the communication is complete, the master issues a stop condition indicating that
everything is done.
Figure 2: I2CCommunication Protocol
Since there are only two wires, this protocol includes the extra overhead of an addressing
mechanism and an acknowledgement mechanism
Features
I2C has many features other important features worth mentioning. It supports multiple data
speeds: standard (100 kbps), fast (400 kbps) and high speed (3.4 Mbps) communications.
Other features include:




Built in collision detection,
10-bit Addressing,
Mutli-master support,
Data broadcast (general call).
For more information about other features, take a look at the references at the end of this article.
Benefits and Drawbacks
Since only two wires are required, is well suited for boards with many devices connected on
the bus. This helps reduce the cost and complexity of the circuit as additional devices are added to
the system.
Due to the presence of only two wires, there is additional complexity in handling the overhead
of addressing and acknowledgments. This can be inefficient in simple configurations and a
direct-link interface such as SPI might be preferred.
References
 I2C-bus - Philips Semiconductors Official I2C website
http://www.semiconductors.philips.com/markets/mms/protocols/i2c/

I2C (Inter-Integrated Circuit) Bus Technical Overview and Frequently Asked Questions Embedded Systems Academy by Axel Wolf, ESAcademy based on the I2C FAQ by Vince
Himpe http://www.esacademy.com/faq/i2c/
In the early 1980's, Philips Semiconductors developed a simple bi-directional 2-wire bus for
efficient inter-IC control. This bus is called the Inter-IC or I2C-bus. At present, Philips?IC range
includes more than 150 CMOS and bipolar I2C-bus compatible types for performing
communication functions between intelligent control devices (e.g. microcontrollers),
general-purpose circuits (e.g. LCD drivers, remote I/O ports, memories) and application-oriented
circuits (e.g. digital tuning and signal processing circuits for radio and video systems).
All I2C-bus compatible devices incorporate an on-chip interface which allows them to
communicate directly with each other via the I2C-bus. This design concept solves the many
interfacing problems encountered when designing digital control circuits. I2C has become a de facto
world standard that is now implemented in over 1000 different ICs and is licensed to more than 50
companies.
Contents
General Introduction
Historical Background
The I2C bus was developed in the early 1980's by Philips Semiconductors. Its original purpose
was to provide an easy way to connect a CPU to peripheral chips in a TV-set.
Peripheral devices in embedded systems are often connected to the MCU as memory-mapped
I/O devices, using the microcontroller's parallel address and data bus. This results in lots of wiring
on the PCB's to route the address and data lines, not to mention a number of address decoders and
glue logic to connect everything. In mass production items such as TV-sets, VCR's and audio
equipment, this is not acceptable. In these appliances, every component that can be saved means
increased profitability for the manufacturer and more affordable products for the end customer.
Furthermore, lots of control lines implies that the systems is more susceptible to disturbances by
Electromagnetic Interference (EMI) and Electrostatic Discharge (ESD).
The research done by Philips Labs in Eindhoven (The Netherlands) to overcome these
problems resulted in a 2-wire communication bus called the I2C bus. I2C is an acronym for Inter-IC
bus. Its name literally explains its purpose: to provide a communication link between Integrated
Circuits.
Today, the I2C bus is used in many other application fields than just audio and video
equipment. The bus is generally accepted in the industry as a de-facto standard. The I2C bus has
been adopted by several leading chip manufacturers like Xicor, ST Microelectronics, Infineon
Technologies, Intel, Texas Instruments, Maxim, Atmel, Analog Devices and others.
I2C Bus Protocol
The I2C bus physically consists of 2 active wires and a ground connection. The active wires,
called SDA and SCL, are both bi-directional. SDA is the Serial DAta line, and SCL is the Serial
CLock line.
Every device hooked up to the bus has its own unique address, no matter whether it is an MCU,
LCD driver, memory, or ASIC. Each of these chips can act as a receiver and/or transmitter,
depending on the functionality. Obviously, an LCD driver is only a receiver, while a memory or I/O
chip can be both transmitter and receiver.
The I2C bus is a multi-master bus. This means that more than one IC capable of initiating a
data transfer can be connected to it. The I2C protocol specification states that the IC that initiates a
data transfer on the bus is considered the Bus Master. Consequently, at that time, all the other ICs
are regarded to be Bus Slaves.
As bus masters are generally microcontrollers, let's take a look at a general 'inter-IC chat' on
the bus. Lets consider the following setup and assume the MCU wants to send data to one of its
slaves (also see here for more information; click here for information on how to receive data from a
slave).
First, the MCU will issue a START condition. This acts as an 'Attention' signal to all of the
connected devices. All ICs on the bus will listen to the bus for incoming data.
Then the MCU sends the ADDRESS of the device it wants to access, along with an indication
whether the access is a Read or Write operation (Write in our example). Having received the
address, all IC's will compare it with their own address. If it doesn't match, they simply wait until
the bus is released by the stop condition (see below). If the address matches, however, the chip will
produce a response called the ACKNOWLEDGE signal.
Once the MCU receives the acknowledge, it can start transmitting or receiving DATA. In our
case, the MCU will transmit data. When all is done, the MCU will issue the STOP condition. This is
a signal that the bus has been released and that the connected ICs may expect another transmission
to start any moment.
We have had several states on the bus in our example: START, ADDRESS, ACKNOWLEDGE,
DATA , STOP. These are all unique conditions on the bus. Before we take a closer look at these bus
conditions we need to understand a bit about the physical structure and hardware of the bus.
I2C Bus Events: Transmitting a byte to a slave
Once the start condition has been sent, a byte can be transmitted by the MASTER to the SLAVE.
This first byte after a start condition will identify the slave on the bus (address) and will select
the mode of operation. The meaning of all following bytes depends on the slave.
A number of addresses have been reserved for special purposes. One of these addresses is
reserved for the "Extended Addressing Mode". As the I2C bus gained popularity, it was soon
discovered that the number of available addresses was too small. Therefore, one of the reserved
addresses has been allocated to a new task to switch to 10-bit addressing mode. If a standard slave
(not able to resolve extended addressing) receives this address, it won't do anything (since it's not its
address).
If there are slaves on the bus that can operate in the extended 10-bit addressing mode, they will
ALL respond to the ACK cycle issued by the master. The second byte that gets transmitted by the
master will then be taken in and evaluated against their address.
Note: Even in 10-bit extended addressing mode, Bit 0 of the first byte after the Start condition
determines the slave access mode ('1' = read / '0' = write).
I2C Bus Events: Receiving a byte from a slave
Once the slave has been addressed and the slave has acknowledged this, a byte can be received
from the slave if the R/W bit in the address was set to READ (set to '1').
The protocol syntax is the same as in transmitting a byte to a slave, except that now the master
is not allowed to touch the SDA line. Prior to sending the 8 clock pulses needed to clock in a byte
on the SCL line, the master releases the SDA line. The slave will now take control of this line. The
line will then go high if it wants to transmit a '1' or, if the slave wants to send a '0', remain low.
All the master has to do is generate a rising edge on the SCL line (2), read the level on SDA (3)
and generate a falling edge on the SCL line (4). The slave will not change the data during the time
that SCL is high. (Otherwise a Start or Stop condition might inadvertently be generated.)
During (1) and (5), the slave may change the state of the SDA line.
In total, this sequence has to be performed 8 times to complete the data byte. Bytes are always
transmitted MSB first.
The meaning of all bytes being read depends on the slave. There is no such thing as a
"universal status register". You need to consult the data sheet of the slave being addressed to know
the meaning of each bit in any byte transmitted.
I2C Bus Events: The START and STOP conditions
Prior to any transaction on the bus, a START condition needs to be issued on the bus. The start
condition acts as a signal to all connected IC's that something is about to be transmitted on the bus.
As a result, all connected chips will listen to the bus.
After a message has been completed, a STOP condition is sent. This is the signal for all
devices on the bus that the bus is available again (idle). If a chip was accessed and has received data
during the last transaction, it will now process this information (if not already processed during the
reception of the message).
Start
The chip issuing the Start condition first pulls the SDA (data) line low,
and next pulls the SCL (clock) line low.
Stop
The Bus Master first releases the SCL and then the SDA line.
A few notes about start and stop conditions:
 A single message can contain multiple Start conditions. The use of this so-called "repeated
start" is common in I2C.
 A Stop condition ALWAYS denotes the END of a transmission. Even if it is issued in the
middle of a transaction or in the middle of a byte. It is "good behavior" for a chip that, in this
case, it disregards the information sent and resumes the "listening state", waiting for a new
start condition.
I2C Bus Events: Getting Acknowledge from a slave
When an address or data byte has been transmitted onto the bus then this must be
ACKNOWLEDGED by the slave(s). In case of an address: If the address matches its own then that
slave and only that slave will respond to the address with an ACK. In case of a byte transmitted to
an already addressed slave then that slave will respond with an ACK as well.
The slave that is going to give an ACK pulls the SDA line low immediately after reception of
the 8th bit transmitted, or, in case of an address byte, immediately after evaluation of its address. In
practical applications this will not be noticeable.
This means that as soon as the master pulls SCL low to complete the transmission of the bit (1),
SDA will be pulled low by the slave (2).
The master now issues a clock pulse on the SCL line (3). the slave will release the SDA line upon
completion of this clock pulse (4).
The bus is now available again for the master to continue sending data or to generate a stop
condition.
In case of data being written to a slave, this cycle must be completed before a stop condition
can be generated. The slave will be blocking the bus (SDA kept low by slave) until the master has
generated a clock pulse on the SCL line.
I2C Bus Hardware
As explained earlier, the bus physically consists of 2 active wires called SDA (data) and SCL
(clock), and a ground connection.
Both SDA and SCL are initially bi-directional. This means that in a particular device, these
lines can be driven by the IC itself or from an external device. In order to achieve this functionality,
these signals use open collector or open drain outputs (depending on the technology).
The bus interface is built around an input buffer and an open drain or open collector transistor.
When the bus is IDLE, the bus lines are in the logic HIGH state (note that external pull-up resistors
are necessary for this which is easily forgotten). To put a signal on the bus, the chip drives its output
transistor, thus pulling the bus to a LOW level. The "pull-up resistor" in the devices as seen in the
figure is actually a small current source or even non-existent.
The nice thing about this concept is that it has a "built-in" bus mastering technique. If the bus
is "occupied" by a chip that is sending a 0, then all other chips lose their right to access the bus.
More will be explained about this in the section about bus arbitration.
However, the open-collector technique has a drawback, too. If you have a long bus, this will
have a serious effect on the speed you can obtain. Long lines present a capacitive load for the output
drivers. Since the pull-up is passive, you are facing an RC constant which will reflect on the shapes
of the signals. The higher this RC constant, the slower you can go. This is due to the effect that it
influences the slew rate of the edges on the I2C bus. At a certain point, the ICs will not be able to
distinguish clearly between a logic 1 and 0.
What's more is that you can get reflections at high speed. This can be so bad that "ghost
signals" disturb your transmission and corrupt the data you transmit. Not even Schmitt triggers at
the IC's inputs will be able to eliminate this effect.
Therefore some strict electrical specifications have been put together.
To overcome this problem, Philips has developed an active I2C terminator. This device
consists of a twin charge pump and you can look at it as a dynamic resistor. The moment the state
changes, it provides a large current (low dynamic resistance) to the bus. In doing so it can charge
the parasitic capacitor very quickly. Once the voltage has risen above a certain level, the high
current mode cuts out and the output current drops sharply.
Take a look at the following figure. As long as the bus is kept low (transistor C is on), the
charge pump is disabled because the gate of transistor B is kept low by transistor A.
As soon as the chip releases the bus (A and C turn off), the capacitor will start charging,
drawing current trough all four of the resistors (1 - 4). The voltage drop over resistor 2 will cause
the transistor B to turn on, shorting out resistor 3. Since resistor 3 is a relatively low value, the
current will rise. At a certain point in time, the drop between transistor B's gate and source will not
be big enough to keep it switched on. It will then switch off and the charge injection will stop. At
that time, only the external pull-up resistor remains to overcome the charge leakage on the bus.
Please note that this is a simple explanation. The actual device implements more circuitry, e.g.
to prevent "overcharging" if another chip is still pulling the bus low.
This device can come in handy if you need to overcome several meters of I2C bus length.
Overview about the different versions of the I2C bus specification
The very first specification dates back to the year 1982. It only covered Standard mode (up to
100 kbit/s) and 7-bit addressing. Extensions like Fast Mode, Hs-Mode or 10-bit addressing were
added in later versions.
Version 1.0 - 1992
This version of the 1992 I2C-bus specification included the following modifications:

Programming of a slave address by software has been omitted. The realization of this feature
was rather complicated and had not been used.

The "low-speed mode" has been omitted. This mode was, in fact, a subset of the total I2C-bus
specification and did not need to be specified explicitly.
The Fast-mode was added. This allows a fourfold increase of the bit rate up to 400 kbit/s.
Fast-mode devices are downwards compatible i.e. they can be used in a 0 to 100 kbit/s I2C-bus
system.
10-bit addressing was added. This allows 1024 additional slave addresses.
Slope control and input filtering FOR FAST-MODE DEVICES was specified to improve the
EMC behavior. NOTE: Neither the 100 kbit/s I2C-bus system nor the 100 kbit/s devices have
been changed.



Version 2.0 - 1998
As the I2C-bus became a de facto world standard implemented in over 1000 different ICs and
licensed to more than 50 companies, an update of the specification became necessary as many of
the newer applications required higher bus speeds and lower supply voltages. This version 2.0 of
the I2C-bus specification met those requirements and included the following modifications:
 The High-speed mode (Hs-mode) was added. This allows an increase in the bit rate up to 3.4
Mbit/s. Hs-mode devices can be mixed with Fast- and Standard-mode devices on the one
I2C-bus system with bit rates from 0 to 3.4 Mbit/s.
 The low output level and hysteresis of devices with a supply voltage of 2 V and below has
been adapted to meet the required noise margins and to remain compatible with higher supply
voltage devices.
 The 0.6 V at 6 mA requirement for the output stages of Fast-mode devices has been omitted.
 The fixed input levels for new devices were replaced by bus voltage-related levels.
 Application information for bi-directional level shifter was added.
Version 2.1 – 2000 http://www.esacademy.com/faq/i2c/I2C_Bus_specification.pdf
Version 2.1 of the I2C-bus specification is the most current version. It includes the following
minor modifications:
 After a repeated START condition in Hs-mode, it is possible to stretch the clock signal SCLH.
 Some timing parameters in Hs-mode have been relaxed.
I2C Bus Arbitration
So far we have seen the operation of the bus from the master's point of view and using only
one master on the bus.
The I2C bus was originally developed as a multi-master bus. This means that more than one device
initiating transfers can be active in the system.
When using only one master on the bus there is no real risk of corrupted data, except if a slave
device is malfunctioning or if there is a fault condition involving the SDA / SCL bus lines.
This situation changes with 2 MCU's:
When MCU 1 issues a start condition and sends an address, all slaves will listen (including
MCU 2 which at that time is considered a slave as well). If the address does not match the address
of CPU 2, this device has to hold back any activity until the bus becomes idle again after a stop
condition.
As long as the two MCU's monitor what is going on on the bus (start and stop) and as long as
they are aware that a transaction is going on because the last issued command was not a STOP,
there is no problem.
Let's assume one of the MCU's missed the START condition and still thinks the bus is idle, or
it just came out of reset and wants to start talking on the bus which could very well happen in a
real-life scenario. This could lead to problems.
How can you know if some other device is transmitting on the bus ?
Fortunately, the physical bus setup helps us out. Since the bus structure is a wired AND (if one
device pulls a line low it stays low), you can test if the bus is idle or occupied.
When a master changes the state of a line to HIGH, it MUST always check that the line really
has gone to HIGH. If it stays low then this is an indication that the bus is occupied and some other
device is pulling the line low.
Therefore the general rule of thumb is: If a master can't get a certain line to go high, it lost
arbitration and needs to back off and wait until a stop condition is seen before making another
attempt to start transmitting.
What about the risk of data corruption ?
Since the previous rule says that a master loses arbitration when it cannot get either SCL or
SDA to go high when needed, this problem does not exist. It is the device that is sending the '0' that
rules the bus. One master cannot disturb the other master's transmission because if it can't detect one
of the lines to go high, it backs off, and if it is the other master that can't do so, it will behave the
same.
This kind of back-off condition will only occur if the two levels transmitted by the two masters
are not the same. Therefore, let's have a look at the following figure, where two MCUs start
transmitting at the same time:
The two MCU's are accessing a slave in write mode at address 1111001. The slave
acknowledges this. So far, both masters are under the impression that they "own" the bus.
Now MCU1 wants to transmit 01010101 to the slave, while MCU 2 wants to transmit
01100110 to the slave. The moment the data bits do not match anymore (because what the MCU
sends is different than what is present on the bus) one of them loses arbitration and backs off.
Obviously, this is the MCU which did not get its data on the bus. For as long as there has been no
STOP present on the bus, it won't touch the bus and leave the SDA and SCL lines alone (yellow
zone).
The moment a STOP was detected, MCU2 can attempt to transmit again.
From the example above we can conclude that is the master that is pulling the line LOW in an
arbitration situation that always wins the arbitration. The master which wanted the line to be HIGH
when it is being pulled low by the other master loses the bus. We call this a loss of arbitration or a
back-off condition.
When a MCU loses arbitration, it has to wait for a STOP condition to appear on the bus. Then
it knows that the previous transmission has been completed.
Clock Synchronization
All masters generate their own clock on the SCL line to transfer messages on the I2C-bus. Data
is only valid during the HIGH period of the clock. A defined clock is therefore needed for the
bit-by-bit arbitration procedure to take place.
Clock synchronization is performed using the wired-AND connection of I2C interfaces to the
SCL line. This means that a HIGH to LOW transition on the SCL line will cause the devices
concerned to start counting off their LOW period and, once a device clock has gone LOW, it will
hold the SCL line in that state until the clock HIGH state is reached. However, the LOW to HIGH
transition of this clock may not change the state of the SCL line if another clock is still within its
LOW period. The SCL line will therefore be held LOW by the device with the longest LOW period.
Devices with shorter LOW periods enter a HIGH wait-state during this time.
When all devices concerned have counted off their LOW period, the clock line will be released
and go HIGH. There will then be no difference between the device clocks and the state of the SCL
line, and all the devices will start counting their HIGH periods. The first device to complete its
HIGH period will again pull the SCL line LOW. In this way, a synchronized SCL clock is generated
with its LOW period determined by the device with the longest clock LOW period, and its HIGH
period determined by the one with the shortest clock HIGH period.
Using the clock synchronizing mechanism as a handshake
The I2C protocol also includes a synchronization mechanism. This can be used as a handshake
mechanism between slow and fast devices or between masters in a multi-master session.
When a slow slave (slow in terms of internal execution) is attached to the bus then problems
may occur. Let's consider a serial EEPROM. The actual writing process inside the EEPROM might
take some time. Now if you send multiple bytes to such a device, the risk exists that you send new
data to it before it has completed the write cycle. This would corrupt the data or cause data loss.
The slave must have some means to tell the master that it is busy. It could of course simply not
respond to the ACK cycle. This would cause the master to send a stop condition and retry. (That's
how it is done in hardware in EEPROMs.)
Other cases might not be so simple. Think about an A/D converter. It might take some time for
the conversion to complete. If the master would just go on it would be reading the result of the
previous conversion instead of the newly acquired data.
Now the synchronization mechanism can come in handy. This mechanism works on the SCL
line only. The slave that wants the master to wait simply pulls the SCL low as long as needed. This
is like adding "wait states" to the I2C bus cycle.
The master is then not able to produce the ACK clock pulse because it cannot get the SCL line
to go high. Of course the master software must check this condition and act appropriately. In this
case, the master simply waits until it can get the SCL line to go HIGH and then just goes on with
whatever it was doing.
There are a number of minor drawbacks involved when implementing this. If the SCL gets
stuck due to an electrical failure of a circuit, the master can go into deadlock. Of course this can be
handled by timeout counters. Plus, if the bus gets stuck like this, the communication is not working
anyway.
Another drawback is speed. The bus is locked at that moment. If you have rather long delays
(long conversion time in our example above), then this penalizes the total bus speed a lot. Other
masters cannot use the bus at that time either.
This technique does not interfere with the previously introduced arbitration mechanism
because the low SCL line will lead to back-off situations in other devices which possibly would
want to "claim" the bus. So there is no real drawback to this technique except the loss of speed /
bandwidth and some software overhead in the masters.
You can use this mechanism between masters in a multi-master environment. This can prevent
other master from taking over the bus. In a two-master system this is not useful. But as soon as you
have three or more masters this is very handy. A third master cannot interrupt a transfer between
master 1 and 2 in this way. For some mission-critical situations this can be a very nice feature.
You can make this technique rigid by not pulling only the SCL line low, but also the SDA line.
Then any master other than the two masters talking to each other will immediately back off. Before
you continue, you first let SDA go back high, and then SCL, representing a stop condition. Any
master which attempted to communicate in the meantime would have detected a back-off situation
and would be waiting for a STOP to appear.
I2C Bus Events: Giving Acknowledge to a slave
Upon reception of a byte from a slave, the master must acknowledge this to the slave device.
The master is in full control of the SDA and the SCL line.
After transmission of the last bit to the master (1) the slave will release the SDA line.
The SDA line should then go high (2). The Master will now pull the SDA line low (3) .
Next, the master will put a clock pulse on the SCL line (4). After completion of this clock
pulse, the master will again release the SDA line (5).
The slave will now regain control of the SDA line (6).
Note: The above waveform is slightly exaggerated. You will not notice SDA going high in (2)
and (5). A small spike might barely be visible.
Note: An Acknowledge of a byte received from a slave is always necessary, EXCEPT on the
last byte received.
If the master wants to stop receiving data from the slave, it must be able to send a stop
condition.
Since the slave regains control of the SDA line after the ACK cycle issued by the master, this
could lead to problems.
Let's assume the next bit ready to be sent to the master is a 0. The SDA line would be pulled
low by the slave immediately after the master takes the SCL line low. The master now attempts to
generate a Stop condition on the bus. It releases the SCL line first and then tries to release the SDA
line - which is held low by the slave. Conclusion: No Stop condition has been generated on the bus.
This condition is called a NACK : Not ACKnowledge . Do not confuse this with No
ACKnowledge:
Condition
Can only occur...
Not acknowledge
(NACK)
after a master has read a byte
from a slave
No acknowledge
after a master has written a byte
to a slave
I2C Bus Events: No Acknowledge (from slave to master)
This is not exactly a condition. It is merely a state in the data flow between master and slave.
If, after transmission of the 8th bit from the master to the slave the slave does not pull the SDA line
low, then this is considered a No ACK condition.
This means that either :
 The slave is not there (in case of an address)
 The slave missed a pulse and got out of sync with the SCL line of the master.
 The bus is "stuck". One of the lines could be held low permanently.
In any case the master should abort by attempting to send a stop condition on the bus.
A test for a "stuck bus" can be performed in the stop condition cycle.
Special Addresses and Exceptions
In the I2C address map there are so-called "reserved addresses". This section contains some
more details on these addresses and what they do. For information about the Extended Addressing
Mode, please refer to the corresponding chapter.
Address
R/W Designation
0000-000
0
General Call address (see note 1)
0000-000
1
START byte (see note 2)
0000-001
x
reserved for the (now obsolete) C-Bus format (note 3 )
0000-010
x
Reserved for a different bus format (note 4)
0000-011
x
Reserved for future purposes (note 5)
0000-1xx
x
Reserved for future purposes
1111-1xx
x
Reserved for future purposes
1111-0xx
x
10-bit slave addressing mode (note 6)
Note 1: The general call address
This address is being used to access all devices on the bus which are capable of handling the
general call and need this data. Devices which are capable of handling this general call but do not
need it will not answer.
All bytes transferred after this address may or may not be taken in by the slaves that are
responding to it. If no slave is acknowledging a transmitted byte, the operation is stopped by issuing
a STOP on the bus.
The meaning of the general call address is specified in the 1st byte transmitted after this
"general call". This first byte can contain the following information:
If the LSB is set to 0:
0000-0110
Reset and write programmable part of slave address. All
devices who respond to this will reset and take in the
programmable part of their address. This is done by
re-reading the levels on the address select pins of the
device (if any). This command can be used to reset an
entire I2C system.
0000-0100
The same as above but without the reset . This can be
useful if the state of the address select pins of a device are
configurable. This way the device address will change.
If the LSB is set to 1:
xxxx-xxx1
This is a Hardware Call. If a device needs urgent attention
from a master device without knowing which master it
needs to turn to, it can use this call. This is a call "to whom
it may concern". The device then embeds its own address
into the message. This call means as much as: Please
contact me, I need to be serviced. All masters will listen and
the master that knows how to handle the device with the
address transmitted will contact its slave and act
appropriately.
Note 2: The START address
This can be used between masters. A master which does not have an I2C interface in hardware
but in software needs to monitor the bus all the time. Since this can require a lot of processing time,
the START address was introduced. The masters can sample the bus at a low rate. As soon as they
detect that the SDA line is low (it is held low for over 7 clock periods) it can switch to a higher
sampling rate to detect the Start condition.
This address is not followed by a stop condition but rather by a repeated start condition.
Notes 3 and 4: These addresses are used when data other than I2C data has to be transmitted
over the bus.
Note 5: These addresses are for further expansion and are currently not allowed.
Note 6: This will be discussed in detail in the section about 10-bit addressing.
Enhanced I2C (FAST mode)
Since the first I2C spec release (which dates back from 1982), a couple of improvements have
been made. In 1992, a newer version of the I2C spec was released. This new spec contained some
additional sections covering FAST mode and 10-bit addressing.
In the FAST mode, the physical bus parameters are not altered. The protocol, bus levels,
capacitive load etc. remain unchanged. However, the data rate has been increased to 400 Kbit/s and
a constraint has been set on the level of noise that can be present in the system. To accomplish this
task, a number of changes have been made to the I2C bus timing.
Since all CBUS activities have been canceled, there is no compatibility anymore with CBUS
timing. The development of ICs with CBUS interface has long been stopped. The existing CBUS
IC's are discontinued. Furthermore, the CBUS devices cannot handle these higher clock rates.
The input of the FAST mode devices all include Schmitt triggers to suppress noise. The output
buffers include slope control for the falling edges of the SDA and SCL signals. If the power supply
of a FAST mode device is switched off, the bus pins must be floating so that they do not obstruct
the bus.
The pull-up resistor must be adapted. For loads up to 200 pF, a resistor is sufficient. For loads
between 200pF and 400pF, a current source (active pull-up) is preferred.
High-Speed I2C (Hs-mode)
High-speed mode (Hs-mode) devices offer a quantum leap in I2C-bus transfer speeds.
Hs-mode devices can transfer information at bit rates of up to 3.4 Mbit/s, yet they remain fully
downward compatible with Fast- or Standard-mode (F/S-mode) devices for bi-directional
communication in a mixed-speed bus system. With the exception that arbitration and clock
synchronization is not performed during the Hs-mode transfer, the same serial bus protocol and data
format is maintained as with the F/S-mode system. Depending on the application, new devices may
have a Fast or Hs-mode I2C-bus interface, although Hs-mode devices are preferred as they can be
designed-in to a greater number of applications.
High speed transfer
To achieve a bit transfer of up to 3.4 Mbit/s the following improvements have been made to the
regular I 2 C-bus specification:
 Hs-mode master devices have an open-drain output buffer for the SDAH signal and a






combination of an open-drain pull-down and current-source pull-up circuit on the SCLH
output (1) . This current-source circuit shortens the rise time of the SCLH signal. Only the
current-source of one master is enabled at any one time, and only during Hs-mode.
No arbitration or clock synchronization is performed during Hs-mode transfer in multi-master
systems, which speeds-up bit handling capabilities. The arbitration procedure always finishes
after a preceding master code transmission in F/S-mode.
Hs-mode master devices generate a serial clock signal with a HIGH to LOW ratio of 1 to 2.
This relieves the timing requirements for set-up and hold times.
As an option, Hs-mode master devices can have a built-in bridge (1) . During Hs-mode transfer,
the high speed data (SDAH) and high-speed serial clock (SCLH) lines of Hs-mode devices are
separated by this bridge from the SDA and SCL lines of F/S-mode devices. This reduces the
capacitive load of the SDAH and SCLH lines resulting in faster rise and fall times.
The only difference between Hs-mode slave devices and F/S-mode slave devices is the speed
at which they operate. Hs-mode slaves have open-drain output buffers on the SCLH and
SDAH outputs. Optional pull-down transistors on the SCLH pin can be used to stretch the
LOW level of the SCLH signal, although this is only allowed after the acknowledge bit in
Hs-mode transfers.
The inputs of Hs-mode devices incorporate spike suppression and a Schmitt trigger at the
SDAH and SCLH inputs.
The output buffers of Hs-mode devices incorporate slope control of the falling edges of the
SDAH and SCLH signals.
The figure below shows the physical I 2 C-bus configuration in a system with only Hs-mode
devices. Pins SDA and SCL on the master devices are only used in mixed-speed bus systems and
are not connected in an Hs-mode only system. In such cases, these pins can be used for other
functions.
Optional series resistors Rs protect the I/O stages of the I2C-bus devices from high-voltage
spikes on the bus lines and minimize ringing and interference. Pull-up resistors Rp maintain the
SDAH and SCLH lines at a HIGH level when the bus is free and ensure the signals are pulled up
from a LOW to a HIGH level within the required rise time. For higher capacitive bus-line loads
(>100 pF), the resistor Rp can be replaced by external current source pull-ups to meet the rise time
requirements. Unless proceeded by an acknowledge bit, the rise time of the SCLH clock pulses in
Hs-mode transfers is shortened by the internal current-source pull-up circuit MCS of the active
master.
Extended addressing (10-bit)
Due to the increasing popularity of the I2C bus the 7-bit address space got exhausted. This
started posing problems for people currently in the phase of designing a new I2C compatible IC.
Therefore the I2C standard has been updated to implement a 10-bit addressing mode.
A chip that conforms to the new standard receives two address bytes. The first consists of the
extended addressing reserved address including the 2 MSB's of the device address and the
Read/Write bit. The second byte contains the 8 LSB's of the address.
This scheme insures that the 10 bit addressing mode stays completely transparent for the other
devices on the bus. Any new design should implement this new addressing scheme.
Frequently asked question section I2C FAQ
A number of commonly asked questions are answered here.

What is the maximum distance of the I2C bus?
This depends on the load of the bus and the speed you run at. In typical applications, the length
is a few meters (9-12ft). The maximum capacitive load has been specified (see also the electrical
Spec's in the I2C FAQ). Another thing to be taken into account is the amount of noise picked up by
long cabling. This noise can disturb the signal transmitted over the bus so badly that it becomes
unreadable.
The length can be increased significantly by running at a lower clock frequency. One particular
application - clocked at about 500Hz - had a bus length of about 100m (300ft). If you are careful in
routing your PCB's and use proper cabling (twisted pair and/or shielded cable), you can also gain
some length.
If you need to go far at high speed, you can use an active current source instead of a simple
pull-up resistor. Philips has a standalone product for this purpose. Using a charge pump also reduces
"ghost signals" caused by reflections at the end of the bus lines.

I'd like to extend the I2C bus. Is there something like a repeater for I2C?
Yes indeed this exists. Philips manufactures a special chip to buffer the bi-directional lines of
the I2C bus. Typically, this is a current amplifier. It forces current into the wiring (a couple of
mA). That way you can overcome the capacitance of long wiring.
However, you will need this component on both sides of the line. The charge pump in this
devices can deliver currents up to 30mA which is way too much for a normal I2C chip to handle.
With these buffers you can handle loads up to 2nF. The charge amplifier 'transforms' this load down
to a 200pF load which is still acceptable by I2C components.

Can I do galvanic decoupling of my I2C bus?
This is possible. The circuit is rather complex due to the bi-directional nature of the I2C bus.
The following figure shows a possible solution:
Component Values:
5 and 5' : PNP like 2n2219 or BC557
6 and 6' : NPN like 2n2222 or BC 547
1 and 1' : 270 Ohm
2 and 2' : 3300 Ohm
3 and 3' : 1800 Ohm
4 and 4' : 1000 Ohm
Optocouplers : 6n139 , 4n27 or Til 111
Note: Since the speed of the I2C bus can be rather high, it is recommended to use a fast
optocoupler. However, this circuit will not work on speeds higher then 10KHz. A 6N139 will do the
job in all cases. The two PNP and the two NPN transistors can be any standard type, e.g. 2N2219
and 2N2222 (USA) or BC547 and BC557 (EUROPE).
How does it work ?
The problem with bi-directional lines is that a buffer tends to get stuck on a certain level. This
case has been taken into account in the above schematic. In the following explanation we assume
that the left side is transmitting and the right side is receiving (the circuit is symmetrical)
Let's assume we send a logic 1 into the left side. The LED of the top optocoupler will stay dark.
Since its transistor does not receive any light, it is not turned on. The next transistor does not get
driven and the line at the end is being pulled high via resistors 1' and 3'. The PNP transistor 5' will
not get driven. Therefore the LED connected to it will not light up and there is no feedback signal.
Now let's see what will happen if we send a logic 0. The first transistor 5 will be turned on,
therefore the led connected to it will start emitting light. This results in the fact that its matching
transistor will turn on. The transistor connected to the emitter will be turned on also. The output line
is now being pulled low via resistor 3'. This low level would turn on the PNP transistor, which
would result in the other optocoupler to light, its transistor to turn on etc. In other words, the circuit
would go into a lock-up. However, since the NPN transistor is pulling the anode of the LED to
ground, this will not happen. This way we have eliminated the deadlock.

Are there stand-alone I2C controllers?
Yes indeed. There is a special chip to do the I2C interfacing. The PCD8584 or PCF8584
incorporate a complete I2C interface. These chips are designed in such way that they can interface
to almost any microcontroller around.

How can I generate a repeated start condition?
Let's assume the following situation: The controller lets the SCL line go high and the device
pulls SDA low to acknowledge. So far no problem but how do you generate a repeated start
condition now? The device is pulling SDA low.
First you have to complete the ACK cycle. To do this, you must pull SCL low again. The slave
will release the data line when it detects that SCL is low. Now you can issue a stop command. To do
this, you let the SCL go high again and then pull low the SDA line.
This is the confusing part of the procedure. Normally, you would suspect that by letting the
clock line go high again you will be clocking in the first bit of a new byte. As a matter of fact that is
the case. But since the chip will detect a START condition, this operation gets cancelled.

Can I abort an ongoing I2C bus transmission?
Is it okay to abort an on-going transmission any time.
According to the specification, this should work. It depends on the layout of the component. A
real I2C compatible IC will be able to handle this. It might make sense to test this before you use it.
Usually, when a START or STOP condition is detected, the internal logic of the chip is forced
into a certain state. Internally, the logic that detects START and STOP is different from the logic
that does all other processing. The START together with the address register is to be considered as a
functional unit inside the chip.
When a START is detected, all internal operations are cancelled and the chip will compare the
incoming data with its own address.
When a STOP is detected, ALL chips on the bus will reset their internal logic to IDLE mode
except for the START detector (this is also used to cut power consumption). Therefore, when a start
condition is issued on the bus, the START detector will 'wake-up' the rest of the internal logic.

Do I need to generate an ACK in read mode on the last byte?
This is a somewhat puzzling question. Indeed this is a bit strange. Usually, if you have read the
last byte in a chip and generate an ACK, the chip should do nothing anymore, so the bus should be
clear for you to create a STOP condition. Apparently, there are some chips that start transmitting
data again. One such chip is the PCF 8574 I/O expander.
Though not always desirable, this feature can come in handy. If you need to sample incoming
data fast, then you just continue reading from the chip. This prevents that you lose 'arbitration' of
the bus in a multi-master environment.
It also speeds things up. You don't have to address the chip over and over again so you save the
time for START, Address, ACK and STOP stage for every next byte read. This can lead to a more
than doubled transfer rate.

Why does the SCL line have to be bi-directional?
The clock line needs to be bi-directional when using a MULTI-MASTER protocol and when
using the synchronization protocol.
When you are using only one Master then this is not required since the clock will always be
generated by this device. If you run Multi-master then this changes. One master must be able to
receive data from another master. At that time it must be able to receive clock information via the
clock line also.

How can I implement an active pull-up resistor to enhance the bus length?
You can use an IC or build it with discrete components. All you will need is some resistors and
an off-the-shelf analog switch. Here comes the schematic:
How it works:
Rs are serial resistors used to minimize cross talk and undershoot. They also protect the I/O
drivers of the I2C devices against higher than allowed voltages and current injection. These
resistors are advised if you run a long bus on high speed (such as in enhanced I2C mode).
When the bus becomes idle, all output stages on the bus are turned off and SCL and SDA) go
high. This will not happen immediately, the voltage will rather rise during a certain time. Now
assume the switch (IC1) is not there. The charge time of the bus capacitor would only be
determined by the value of R1. The larger R1 and Rs, the longer it will take for the bus to reach a
sufficient stable HIGH level.
We can't make the Rs resistors too small because then we would go out of spec on the
maximum allowable current into one I2C device when turning on its output driver.
When we calculate for a current of 3mA, we end up at approximately 1800 Ohms for the serial
resistance.
5V / 3mA = 1666 Ohms.
To stay somewhere below this 3mA rating, we pick 1800 Ohms. The charge time for a bus
capacitance of about 200pF would be around 360 ns. That is out of spec. The spec for rise or fall
time in Fast I2C is set to approx 300ns.
But we can't drop the value of our resistor without breaking the other spec of 3mA of
maximum current.
The idea is to change the value of the resistor temporarily using the analog switch IC1. If the
voltage level sensed by the switch is in the range 0.8 to 2 volts then it will turn on. This means that
as soon as the voltage on the SDA line starts rising, resistor R2 will kick in. R1 and R2 in parallel
result in a resistance of 720 Ohms. This increases the charge current to a value of
5 volts / 720 Ohms = 7 mA.
This is allowable for a brief period of time. Of course all of this is a dynamic process. The
actual charge current will change due to the fact that the bus voltage will rise.
A small graphical representation will explain more:
Waveform 1 represents turning off the I2C device, which will release the bus lines so that they
can go HIGH.
Waveform 2 is what you get if you only use a resistor. The bus slowly comes up to 5 volts due
to RC constant of the pull-up resistor R1 and the parasitic capacitance of the bus line Cp.
Waveform 3 shows the analog switch kicking in. If the bus line is at approx 0.7 volts it closes.
It opens again when the bus reaches approx 3 volts.
Waveform 4 is how the voltage on the bus changes. You can see that it rises much faster when
the switch is turned on.
Finally, waveform 5 shows the current flowing into the I2C device. It starts at approx 3mA.
When the output stage is turned off, this current slightly drops due to the fact that the voltage
on the bus is rising. The moment our switch kicks in you see the current doubling. The same effect
is then present as before the switch closed: the current drops as the bus voltage rises. When the
switch opens again the current drops a little to charge the capacitor up to 5 volts. But at that time, all
chips already detect a logic one and are well within the 300ns rise time.

How can I monitor the I2C bus?
There are a few commercial I2C monitor / debuggers around that can do this. Information on
these devices can be found here. http://www.esacademy.com/faq/i2c/general/i2cdebug.htm
There is another possibility to do this: By using the stand-alone I2C controller PCF8584 from
Philips. This chip has a certain mode in which it does not take part in the real I2C action but only
records what is going on. It listens to all addresses, but does not generate any acknowledge. Using
some software routines and a MCU you could build a universal I2C data logger.

How can I test / debug the I2C bus?
There is no general way to debug an I2C bus. However, a few guidelines might help to get it
running.
First thing is to check the levels on the bus. You should see a clear signal that has a low level
that is lower then 0.8 volt and a high level which is at least 3.5 volts.
If the high level is not high enough or does not rise fast enough then you can try to lower the
value of the pull up resistor. You must take care however not to surpass the maximum allowable
current in the I2C driver stage. The minimum allowable resistor for a 5 volt driven I2C bus is 5 V /
3mA = 1600 Ohms. A typical value of 4700 ohm should work fine.
Make sure the bus is not 'stuck' to '0'. This could be the result of a bad power supply (chips go
into latch up during power-on) or a bad chip.
There are a few commercial I2C monitor / debuggers around. Information on these devices can
be found here. http://www.esacademy.com/faq/i2c/general/i2cdebug.htm
 Is there an RS232 / I2C converter?
Yes, there are at least two of them. Please visit one of the following links:
http://www.emicros.com/i2c232.htm
http://www.pickeringswitch.com/simrc/simrcspec.html
 Are there I2C bus evaluation kits available?
Yes there are:
Company: Philips Semiconductors
Product Name: Development tools for 8048 and 8051-based systems
Product Description: Philips Semiconductors has developed a number of demonstration boards for
analysis and testing of I2C-bus devices. The demonstration boards connect via a cable to the
Centronics printer port of a PC and have a 4-stake I2C-bus connector for convenient lab use.
Software supplied with each board provides interactive control of devices on the I2C-bus and
allows the user to construct, send and receive I2C messages.

Which microcontrollers do have an on-chip I2C interface?
A LOT of MCU's have a real I2C interface implemented in hardware, but this should not
restrict the use of the I2C bus on other MCU's. ANY MCU can be made to talk to I2C using some
small software routines.
There are microcontrollers with on-chip I2C modules as well as stand-alone I2C bus
peripherals.
To list all the devices here would be impossible. A good overview can be found here:
http://www.embeddedlinks.com/chipdir
(search for keyword I2C)

Are there PC cards available with an I2C interface?
There are a number of debugging tools out there which can monitor an I2C bus: click here.
http://www.esacademy.com/faq/i2c/general/i2cdebug.htm

How can I use my oscilloscope to trigger on an I2C start condition?
Everybody who ever tried to make a simple oscilloscope Sync on I2C signals knows that this
is almost impossible. You will need a very advanced (read: very expensive) scope or logic analyzer
to monitor I2C signals. You can do it if your scope has the possibility to trigger on 2 independent
channels and if you can program the conditions like level, high-to-low or low-to-high. One such a
scope is a Tektronix TDS540.
Here is a little piece of hardware which can help us out.
How it works:
The Start condition in I2C is defined as: Pulling the SDA line low while SCL line is high which is exactly what the little circuit monitors.
Every transition of the SDA line from HIGH to LOW will make the D-latch sample the level
of the SCL line. If at that time the SCL line is low, then the output of the D-latch will go or remain
low.
On the other hand, if the SCL line is HIGH (which indicates a start condition), the output of
the D-latch will become high.
If you connect the output of the D-latch to the trigger input of a common oscilloscope and set
the scope to trigger on RISING edge of the trigger channel, then you have exactly what you want.
Every time a start condition is transmitted on the bus, the D-latch will trigger the scope.

What bus speeds are available with I2C?
The bus speed for I2C was increased over the years. The following modes are available:
Standard mode, with a bit rate up to 100kbit/s
Fast-mode, with a bit rate up to 400 kbit/s
High-speed mode (Hs-mode), with a bit rate up to 3.4 Mbit/s
Miscellaneous information
Overview about the different versions of the I2C bus specification
http://www.esacademy.com/faq/i2c/general/i2cspecver.htm
I2C driver in Pseudocode
http://www.esacademy.com/faq/i2c/general/i2cpseud.htm
I2C Monitoring and Debugging Tools
http://www.esacademy.com/faq/i2c/general/i2cdebug.htm
Legal notes and Copyrights
The use and manufacturing of I2C devices is subject to a copyright and patents from Philips.
This means that you (as a semiconductor manufacturer or system developer) need to purchase
a license from Philips to use I2C technology in your system.
However, if you buy components which carry the I2C logo from Philips or another
manufacturer then you immediately have the license to use these components.
For further legal information about this please contact your local Philips representative.
Standard Philips Copyright notice :
"Purchase of Philips I2C components conveys a license under the Philips I2C patent to use the
components in the I2C system, provided the system conforms to the I2C specifications defined by
Philips."
 Introduction to I2C - Embedded.com
By David Kalinsky and Roee Kalinsky Embedded Systems Programming
(07/31/01, 09:35:16 H EDT) http://www.embedded.com/story/OEG20010718S0073
An Inter-IC bus is often used to communicate across circuit-board distances. Here's a primer
on the protocol.
At the low end of the spectrum of communication options for "inside the box" communication
is I2C ("eye-squared-see"). The name I2C is shorthand for a standard Inter-IC (integrated circuit)
bus.
I2C provides good support for communication with various slow, on-board peripheral devices
that are accessed intermittently, while being extremely modest in its hardware resource needs. It is a
simple, low-bandwidth, short-distance protocol. Most available I2C devices operate at speeds up to
400Kbps, with some venturing up into the low megahertz range. I2C is easy to use to link multiple
devices together since it has a built-in addressing scheme.
Philips originally developed I2C for communication between devices inside of a TV set.
Examples of simple I2C-compatible devices found in embedded systems include EEPROMs,
thermal sensors, and real-time clocks. I2C is also used as a control interface to signal processing
devices that have separate, application-specific data interfaces. For instance, it's commonly used in
multimedia applications, where typical devices include RF tuners, video decoders and encoders, and
audio processors. In all, Philips, National Semiconductor, Xicor, Siemens, and other manufacturers
offer hundreds of I2C-compatible devices.
Inside the box
I2C is appropriate for interfacing to devices on a single board, and can be stretched across
multiple boards inside a closed system, but not much further. An example is a host CPU on a main
embedded board using I2C to communicate with user interface devices located on a separate front
panel board. A second example is SDRAM DIMMs, which can feature an I2C EEPROM containing
parameters needed to correctly configure a memory controller for that module.
I2C is a two-wire serial bus, as shown in Figure 1. There's no need for chip select or arbitration
logic, making it cheap and simple to implement in hardware.
The two I2C signals are serial data (SDA) and serial clock (SCL). Together, these signals make
it possible to support serial transmission of 8-bit bytes of data-7-bit device addresses plus control
bits-over the two-wire serial bus. The device that initiates a transaction on the I2C bus is termed the
master. The master normally controls the clock signal. A device being addressed by the master is
called a slave.
In a bind, an I2C slave can hold off the master in the middle of a transaction using what's
called clock stretching (the slave keeps SCL pulled low until it's ready to continue). Most I2C slave
devices don't use this feature, but every master should support it.
The I2C protocol supports multiple masters, but most system designs include only one. There
may be one or more slaves on the bus. Both masters and slaves can receive and transmit data bytes.
Each I2C-compatible hardware slave device comes with a predefined device address, the lower
bits of which may be configurable at the board level. The master transmits the device address of the
intended slave at the beginning of every transaction. Each slave is responsible for monitoring the
bus and responding only to its own address. This addressing scheme limits the number of identical
slave devices that can exist on an I2C bus without contention, with the limit set by the number of
user-configurable address bits (typically two bits, allowing up to four identical devices).
Communication
As you can see in Figure 2, the master begins the communication by issuing the start condition
(S). The master continues by sending a unique 7-bit slave device address, with the most significant
bit (MSB) first. The eighth bit after the start, read/not-write (), specifies whether the slave is now to
receive (0) or to transmit (1). This is followed by an ACK bit issued by the receiver, acknowledging
receipt of the previous byte. Then the transmitter (slave or master, as indicated by the bit) transmits
a byte of data starting with the MSB. At the end of the byte, the receiver (whether master or slave)
issues a new ACK bit. This 9-bit pattern is repeated if more bytes need to be transmitted.
In a write transaction (slave receiving), when the master is done transmitting all of the data
bytes it wants to send, it monitors the last ACK and then issues the stop condition (P). In a read
transaction (slave transmitting), the master does not acknowledge the final byte it receives. This
tells the slave that its transmission is done. The master then issues the stop condition.
A simple bus
As we've seen, the I2C signaling protocol provides device addressing, a read/write flag, and a
simple acknowledgement mechanism. There are a few more elements to the I2C protocol, such as
general call (broadcast) and 10-bit extended addressing. Beyond that, each device defines its own
command interface or address-indexing scheme.
Standard I2C devices operate up to 100Kbps, while fast-mode devices operate at up to
400Kbps. A 1998 revision of the I2C specification (v. 2.0) added a high-speed mode running at up
to 3.4Mbps. Most of the I2C devices available today support 400Kbps operation. Higher-speed
operation may allow I2C to keep up with the rising demand for bandwidth in multimedia and other
applications.
Most often, the I2C master is the CPU or microcontroller in the system. Some microcontrollers
even feature hardware to implement the I2C protocol. You can also build an all-software
implementation using a pair of general-purpose I/O pins (single master implementations only).
Since the I2C master controls transaction timing, the bus protocol doesn't impose any real-time
constraints on the CPU beyond those of the application. (This is in contrast with other serial buses
that are timeslot-based and, therefore, take their service overhead even when no real communication
is taking place.)
The elegance of I2C
I2C offers good support for communication with on-board devices that are accessed on an
occasional basis. I2C's competitive advantage over other low-speed short-distance communication
schemes is that its cost and complexity don't scale up with the number of devices on the bus. On the
other hand, the complexity of the supporting I2C software components can be significantly higher
than that of several competing schemes (SPI and MicroWire, to name two) in a very simple
configuration. With its built-in addressing scheme and straightforward means to transfer strings of
bytes, I2C is an elegant, minimalist solution for modest, "inside the box" communication needs.
Resources
1. Willey, H. Michael. "One Cheap Network Topology," Embedded Systems Programming, January
2001, p. 59.
2. Sarns, Steven and Jack Woehr. "Exploring I2C," Embedded Systems Programming, September
1991, p. 46.
3. Philips' web site for I2C: www-us.semiconductors.philips.com/I2C/
 I2C - Open Directory Project Listing
http://dmoz.org/Computers/Hardware/Buses/I2C/ many i2c links
I2C Glossary
Master: The device which initiates a transfer, generates clock signals and terminates a transfer.
Slave: The device addressed by a master.
Transmitter: The device which sends the data to the bus.
Receiver: The device which receives data from the bus.
Standard Mode: Maximum bit rate of 100 kbps.
Fast Mode: Maximum bit rate of 400 kbps.
High Speed Mode: Maximum bit rate of 3.4 Mbps.
SDA: Serial Data line. The signal used to transfer data between the transmitter and the receiver.
SCL: Serial Clock line. The signal used to synchronize communication between the master and the
slave.
Multi-Master: More than one master can attempt to control the bus at the same time without
corrupting the message.
Arbitration: Procedure to ensure that, if mroe than one master simultaneously tries to control the
bus, only one is allowed to do so and the winning message is not corrupted.
Synchronization: Procedure to synchronize the clock signals of two or more devices.
Slave Address: Each slave has a unique address to identify it on the bus. These addresses are
pre-defined, but the least significant bits can be set by the user to allow for multiples of the same
device. In standard I2C, the slave address is 7-bits, but the protocol has been extended to also
support 10-bit addresses.