I²C (
/ˈaɪ skwɛərd ˈsiː/ or
/ˈaɪ tuː ˈsiː/;
Inter-Integrated Circuit; generically referred to as "two-wire interface") is a
multi-master serial single-ended computer bus invented by
Philips that is used to attach low-speed peripherals to a
motherboard,
embedded system, or
cellphone or other electronics. Since the mid 1990s several competitors (e.g. Siemens AG (later Infineon Technologies AG), NEC, Texas Instruments, STMicroelectronics (formerly SGS-Thomson), Motorola (later Freescale), Intersil, etc.) brought I²C products on the market, which are fully compatible with the
NXP (formerly Philips' semiconductor division) I²C-system. As of October 10, 2006, no licensing fees are required to implement the I²C protocol. However, fees are still required to obtain I²C slave addresses allocated by NXP.
[1]SMBus, defined by Intel in 1995, is a subset of I²C that defines the protocols more strictly. One purpose of SMBus is to promote robustness and interoperability. Accordingly, modern I²C systems incorporate policies and rules from SMBus, sometimes supporting both I²C and SMBus with minimal re-configuration required.
Design
I²C uses only two bidirectional
open-drain lines, Serial Data Line (SDA) and Serial Clock (SCL),
pulled up with
resistors. Typical voltages used are +5 V or +3.3 V although systems with other voltages are permitted.
The I²C
reference design has a 7-bit
address space with 16 reserved addresses, so a maximum of 112 nodes can communicate on the same bus. Common I²C bus speeds are the 100
kbit/s standard mode and the 10 kbit/s
low-speed mode, but arbitrarily low clock frequencies are also allowed. Recent revisions of I²C can host more nodes and run at faster speeds (400 kbit/s
Fast mode, 1 Mbit/s
Fast mode plus or Fm+, and 3.4
Mbit/s High Speed mode). These speeds are more widely used on embedded systems than on PCs. There are also other features, such as 16-bit addressing.
Note that the bit rates quoted are for the transactions between master and slave without clock stretching or other hardware overhead. Protocol overheads include a slave address and perhaps a register address within the slave device as well as per-byte ACK/NACK bits. So the actual transfer rate of user data is lower than those peak bit rates alone would imply. For example, if each interaction with a slave inefficiently allows only 1 byte of data to be transferred, the data rate will be less than half the peak bit rate.
The maximum number of nodes is limited by the address space, and also by the total bus
capacitance of 400
pF, which restricts practical communication distances to a few meters.
[edit] Reference design
The reference design, as mentioned above, is a bus with a
clock (SCL) and data (SDA) lines with 7-bit addressing. The bus has two roles for nodes: master and slave:
- Master node — node that issues the clock and addresses slaves
- Slave node — node that receives the clock line and address.
The bus is a
multi-master bus which means any number of master nodes can be present. Additionally, master and slave roles may be changed between messages (after a STOP is sent).
There are four potential modes of operation for a given bus device, although most devices only use a single role and its two modes:
- master transmit — master node is sending data to a slave
- master receive — master node is receiving data from a slave
- slave transmit — slave node is sending data to the master
- slave receive — slave node is receiving data from the master
The master is initially in master transmit mode by sending a
start bit followed by the 7-bit address of the slave it wishes to communicate with, which is finally followed by a single bit representing whether it wishes to write(0) to or read(1) from the slave.
If the slave exists on the bus then it will respond with an
ACK bit (active low for acknowledged) for that address. The master then continues in either transmit or receive mode (according to the read/write bit it sent), and the slave continues in its complementary mode (receive or transmit, respectively).
The address and the data bytes are sent
most significant bit first. The start bit is indicated by a high-to-low transition of SDA with SCL high; the stop bit is indicated by a low-to-high transition of SDA with SCL high.
If the master wishes to write to the slave then it repeatedly sends a byte with the slave sending an ACK bit. (In this situation, the master is in master transmit mode and the slave is in slave receive mode.)
If the master wishes to read from the slave then it repeatedly receives a byte from the slave, the master sending an ACK bit after every byte but the last one. (In this situation, the master is in master receive mode and the slave is in slave transmit mode.)
The master then ends transmission with a
stop bit, or it may send another START bit if it wishes to retain control of the bus for another transfer (a "combined message").
[edit] Message protocols
I²C defines three basic types of messages, each of which begins with a START and ends with a STOP:
- Single message where a master writes data to a slave;
- Single message where a master reads data from a slave;
- Combined messages, where a master issues at least two reads and/or writes to one or more slaves.
In a combined message, each read or write begins with a START and the slave address. After the first START, these are also called
repeated START bits; repeated START bits are not preceded by STOP bits, which is how slaves know the next transfer is part of the same message.
Any given slave will only respond to particular messages, as defined by its product documentation.
Pure I²C systems support arbitrary message structures.
SMBus is restricted to nine of those structures, such as
read word N and
write word N, involving a single slave.
PMBus extends SMBus with a
Group protocol, allowing multiple such SMBus transactions to be sent in one combined message. The terminating STOP indicates when those grouped actions should take effect. For example, one PMBus operation might reconfigure three power supplies (using three different I2C slave addresses), and their new configurations would take effect at the same time: when they receive that STOP.
With only a few exceptions, neither I²C nor SMBus define message semantics, such as the meaning of data bytes in messages. Message semantics are otherwise product-specific. Those exceptions include messages addressed to the I²C
general call address (0x00) or to the SMBus
Alert Response Address; and messages involved in the SMBus
Address Resolution Protocol (ARP) for dynamic address allocation and management.
In practice, most slaves adopt request/response control models, where one or more bytes following a write command are treated as a command or address. Those bytes determine how subsequent written bytes are treated and/or how the slave responds on subsequent reads. Most SMBus operations involve single byte commands.
[edit] Messaging example: 24c32 EEPROM
One specific example is the 24c32 type
EEPROM, which uses two request bytes that are called Address High and Address Low. (Accordingly, these EEPROMs aren't usable by pure SMBus hosts, which only support single byte commands or addresses.) These bytes are used to address bytes within the 32
kbit (4
kB) supported by that EEPROM; the same two byte addressing is also used by larger EEPROMs, such as 24c512 ones storing 512 kbits (64 kB). Writing and reading data to these EEPROMs uses a simple protocol: the address is written, and then data is transferred until the end of the message. (That data transfer part of the protocol also makes trouble for SMBus, since the data bytes are not preceded by a count and more than 32 bytes can be transferred at once. I2C EEPROMs smaller than 32 kbits, such as 2 kbit 24c02 ones, are often used on SMBus with inefficient single byte data transfers.)
To write to the EEPROM, a single message is used. After the START, the master sends the chip's bus address with the direction bit clear (
write), then sends the two byte address of data within the EEPROM and then sends data bytes to be written starting at that address, followed by a STOP. When writing multiple bytes, all the bytes must be in the same 32 byte page. While it's busy saving those bytes to memory, the EEPROM won't respond to further I2C requests. (That's another incompatibility with SMBus: SMBus devices must always respond to their bus addresses.)
To read starting at a particular address in the EEPROM, a combined message is used. After a START, the master first writes that chip's bus address with the direction bit clear (
write) and then the two bytes of EEPROM data address. It then sends a (repeated) START and the EEPROM's bus address with the direction bit set (
read). The EEPROM will then respond with the data bytes beginning at the specified EEPROM data address—a combined message, first a write then a read. The master issues a STOP after the first data byte it NACKs rather than ACKs (when it's read all it wants). The EEPROM increments the address after each data byte transferred; multi-byte reads can retrieve the entire contents of the EEPROM using one combined message.
[edit] Physical layer
At the
physical layer, both SCL & SDA lines are of
open-drain design, thus,
pull-up resistors are needed. Pulling the line to ground is considered a logical zero while letting the line float is a logical one. This is used as a
channel access method. High speed systems (and some others) also add a
current source pull up, at least on SCL; this supports faster rise times and higher bus capacitance.
Transitions for data bits are always performed while the clock is low; transitions while it is high are "start" and "stop" markers delimiting a bus transaction.
When idle, both lines are high. To start a transaction, SDA is pulled low while SCL remains high. Releasing SDA to float high again would be a stop marker, which would be pointless immediately after a start, so the next step is to pull SCL low.
When one node is transmitting a logical one (i.e., letting the line float to Vdd) and another transmits a logical zero then the first node can sense this because the line is not in a logical one state — it is not pulled up to Vdd. When used on SCL, this is called "clock stretching" and gives slaves a flow control mechanism. When used on SDA, this is called
arbitration and ensures there is only one transmitter at a time.
While SCL is low, the transmitter (initially the master) sets SDA to the desired value and (after a small delay to let the value propagate) lets SCL float high. The master then waits for SCL to actually go high; this will be delayed by the finite rise-time of the SCL signal (the
RC time constant of the
pull-up resistor and the
parasitic capacitance of the bus). and may be additionally delayed by a slave's clock stretching.
When SCL is high, the receiver latches the bit, and the master waits a minimum time (4 μs for standard speed I²C), then pulls it low again. This completes transmission of one bit.
After every 8 data bits in one direction, an "acknowledge" bit is transmitted in the other. The transmitter and receiver switch roles for one bit and the erstwhile receiver transmits a single 0 bit (ACK) back. If the transmitter sees a 1 bit (NACK) instead, it learns that:
- If the master is transmitting, the slave is unable to accept the data. No such slave, command not understood, or unable to accept any more data.
- If the slave is transmitting, the master wishes it to stop after this data byte.
After the acknowledge bit, the master may do one of three things:
- Prepare to transmit another byte of data: set SDA to the desired bit value and pulse SCL high..
- Send a "Stop": Set SDA low, let SCL go high, then let SDA go high. This releases the I²C bus.
- Send a "Repeated start": Set SDA high, let SCL go high, and pull SDA low again. This starts a new I²C bus transaction without releasing the bus.
[edit] Clock stretching using SCL
One of the more significant features of the I²C protocol is clock stretching. An addressed slave device may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data. The master that is communicating with the slave will attempt to raise the clock to transfer the next bit, but must verify that the clock line was actually raised. If the slave is clock stretching, the clock line will still be low (because the connections are
open-drain). The same is true if a second, slower, master tries to drive the clock at the same time. (If there is more than one master, all but one of them will normally lose arbitration.)
Although the master may also hold the SCL line low for as long as it desires, the term "clock stretching" is normally used only when slaves do it. If the slave is a
microcontroller, its I²C interface will stretch the clock after every byte, until the software decides what to transmit next.
Some masters, such as those found inside custom
ASICs may not support clock stretching; often these devices will be labeled as a "two-wire interface" and not I²C.
To ensure a minimum bus
throughput,
SMBus places limits on how far clocks may be stretched. Hosts and slaves adhering to those limits can't block access to the bus for more than a short time, which is not a guarantee made by pure I²C systems.
[edit] Arbitration using SDA
Every master monitors the bus for start and stop bits, and does not start a message while another master is keeping the bus busy. However, two masters may start transmission at about the same time; in this case, arbitration occurs. Slave transmit mode can also be arbitrated, when a master addresses multiple slaves, but this is less common. In contrast to protocols (such as
Ethernet) that use random back-off delays before issuing a retry, I²C has a deterministic arbitration policy. Each transmitter checks the level of the data line (SDA) and compares them with the levels it expects; if they don't match, that transmitter has lost arbitration, and drops out of this protocol interaction.
For example, if one transmitter sets SDA to 1 (not driving a signal) and a second transmitter sets it to 0 (pull to ground), the result is that the line is low. The first transmitter then observes that the level of the line is different than expected, and concludes that another node is transmitting. The first node to notice such a difference is the one that loses arbitration: it stops driving SDA. If it's a master, it also stops driving SCL and waits for a STOP; then it may try to reissue its entire message. In the meantime, the other node has not noticed any difference between the expected and actual levels on SDA, and therefore continues transmission. It can do so without problems because so far the signal has been exactly as it expected; no other transmitter has disturbed its message.
If the two masters are sending a message to two different slaves, the one sending the lower slave address always "wins" arbitration in the address stage. Since the two masters may send messages to the same slave address—and addresses sometimes refer to multiple slaves—arbitration must continue into the data stages.
Arbitration occurs very rarely, but is necessary for proper multi-master support. As with clock-stretching, not all devices support arbitration. Those that do generally label themselves as supporting "multi-master" communication.
In the extremely rare case that two masters simulaneously send the identical messages. then both will regard the communication as successful, but the slave will only see one message. Slaves that can be accessed by multiple masters must have commands that are
idempotent for this reason.
SMBus uses arbitration in two additional contexts, both of which are used to pass information asynchronously from slaves to the (single) host. The first context is that hosts must support the "host notify protocol". That is a restricted multi-master mode in which slaves write messages to the reserved "SMBus Host" address (0x08), passing their address and two bytes of data. When two slaves try to notify the host at the same time, one of them will lose arbitration and need to retry. The other context is that pure slave devices which issue the SMBALERT# interrupt need to arbitrate when they reply to requests issued to the reserved "SMBus Alert Response Address" (0x0c), which is a kind of broadcast address. When they successfully reply with their own address, winning an arbitration in "slave transmit" mode, they stop raising that interrupt. In both cases, arbitration applies when the slave address is transmitted.
[edit] Timing diagram
Data transfer is initiated with the START bit (
S) when SDA is pulled low while SCL stays high. Then, SDA sets the transferred bit while SCL is low (blue) and the data is sampled (received) when SCL rises (green). When the transfer is complete, a STOP bit (
P) is sent by releasing the data line to allow it to be pulled up while SCL is constantly high.
[edit] Example of bit-banging the I2C Master protocol
Below is an example of Bit-banging the I2C protocol as an I2C master. The example is written in
pseudo C. It illustrates all of the i2c features described before (Clock stretching, Arbitration, start/stop bit, ack/nack)
/* Hardware-Specific Support Functions That MUST Be Customized */
#define I2CSPEED 100
void I2CDELAY() {volatile int v; int i; for(i=0;i<I2CSPEED/2;i++) v;}
bool READSCL(void) {return 1;} /* Set SCL as input and return current level of line, 0 or 1 */
bool READSDA(void) {return 1;} /* Set SDA as input and return current level of line, 0 or 1 */
void CLRSCL(void) {} /* Actively drive SCL signal low */
void CLRSDA(void) {} /* Actively drive SDA signal low */
void ARBITRATION_LOST(void) {}
/* Global Data */
bool started = false;
void i2c_start_cond(void)
{
/* if started, do a restart cond */
if (started) {
/* set SDA to 1 */
READSDA();
I2CDELAY();
/* Clock stretching */
while (READSCL() == 0)
; /* You should add timeout to this loop */
}
if (READSDA() == 0)
ARBITRATION_LOST();
/* SCL is high, set SDA from 1 to 0 */
CLRSDA();
I2CDELAY();
CLRSCL();
started = true;
}
void i2c_stop_cond(void)
{
/* set SDA to 0 */
CLRSDA();
I2CDELAY();
/* Clock stretching */
while (READSCL() == 0)
; /* You should add timeout to this loop */
/* SCL is high, set SDA from 0 to 1 */
if (READSDA() == 0)
ARBITRATION_LOST();
I2CDELAY();
started = false;
}
/* Write a bit to I2C bus */
void i2c_write_bit(bool bit)
{
if (bit)
READSDA();
else
CLRSDA();
I2CDELAY();
/* Clock stretching */
while (READSCL() == 0)
; /* You should add timeout to this loop */
/* SCL is high, now data is valid */
/* If SDA is high, check that nobody else is driving SDA */
if (bit && READSDA() == 0)
ARBITRATION_LOST();
I2CDELAY();
CLRSCL();
}
/* Read a bit from I2C bus */
bool i2c_read_bit(void)
{
bool bit;
/* Let the slave drive data */
READSDA();
I2CDELAY();
/* Clock stretching */
while (READSCL() == 0)
; /* You should add timeout to this loop */
/* SCL is high, now data is valid */
bit = READSDA();
I2CDELAY();
CLRSCL();
return bit;
}
/* Write a byte to I2C bus. Return 0 if ack by the slave */
bool i2c_write_byte(bool send_start, bool send_stop, unsigned char byte)
{
unsigned bit;
bool nack;
if (send_start)
i2c_start_cond();
for (bit = 0; bit < 8; bit++) {
i2c_write_bit((byte & 0x80) != 0);
byte <<= 1;
}
nack = i2c_read_bit();
if (send_stop)
i2c_stop_cond();
return nack;
}
/* Read a byte from I2C bus */
unsigned char i2c_read_byte(bool nack, bool send_stop)
{
unsigned char byte = 0;
unsigned bit;
for (bit = 0; bit < 8; bit++)
byte = (byte << 1) | i2c_read_bit();
i2c_write_bit(nack);
if (send_stop)
i2c_stop_cond();
return byte;
}
4430 and OMAP4440 in February. At the same time TI introduced a Linux- and Android-compatible "Blaze" hardware/software development platform in smartphone format. The Blaze (pictured) sports a pico projector, dual 3.7-inch displays, three cameras, an HDMI output, a compass, plus a barometer and other sensors. 
