I²C Bus

This file uses the W3C HTML Slidy format. The "a" key toggles between one-slide-at-a-time and single-page mode, and the "c" key toggles on and off the table of contents. The ← and → keys can be used to page forward and backward. For more help on controls see the "help?" link at the bottom.

Image of a AUV using I²C bus from http://www.ncsurobotics.com/site/pages/auv1.1.php

The I²C Bus

A simple, cheap, low-speed bus, used in many embedded systemss

Image from http://www.lammertbies.nl/comm/info/I2C-bus.html

The I²C Bus

• Each device has a unique 8-bit address
• Each device can function as bus master or slave, if designed to do so
• Whoever initiates a data transfer is the current Bus Master (MCU)
• Two wires, that can be viewed as two variable bits by the master:
  • the Serial Clock Line (SCL)
  • the Serial DAta Line (SDA)

Image from http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1163405566/2

Protocol to Send a Message

1. MCU sends START; everyone else listens for incoming data
2. MCU sends ADDRESS of the target & whether it is a read or write
3. Devices that don't match the address stay silent until the MCU sends a STOP
4. Target replies, with an ACKNOWLEDGE
5. Once MCU receives the ACKNOWLEDGE, it begins sending or receiving data
6. When the communication is done, MCU issues a STOP

Image from http://www.8051projects.net/i2c-twi-tutorial/introduction.php

The Bus Conditions/States

START: (1) SDA pulled low; (2) SCL pulled low It is OK to repeat STARTs within message
STOP: (1) SCL released; (2) SDA released There can be no STOPs within a message

Sending A Byte to a Slave

• First byte identifies the target slave
• At the beginning of a byte, both SDA and SCL should be low, from the preceding START or the preceding ACK cycle
• Master follows the following protocol for each of the 8 bits sent:
  1. SDA is set to the bit value (high = 1, low = 0)
  2. SCL is then released (high) -- this is a clock "pulse"
  3. SCL is pulled low -- this is the end of the clock pulse

Slave Acknowledging Receipt of Byte

• After last bit of the byte is transmitted, the slave acknowledges it, as follows:

  SDA is released by master SDA is pulled down by slave (concurrently with the above) SCL is released by master -- a clock pulse SCL is pulled low by master -- end of clock pulse SDA released by slave

• Bus is now ready for master to send the next byte, or STOP

Hazards

• Protocol is the opposite of robust
• Bus state depends on the previous data bits
• One error and the bus gets out of sync
  • If master does not hold signals long enough the slave gets out of sync
  • If slave does not acknowledge the master is stuck in wait state
  • If master misses acknowledgement the slave is stuck in wait state
• Recovery: Master can try sending STOP, wait a bit, and then try to restart
  • How well this works depends on the slave implementation
  • Worst case scenario: entire system needs to be power-cycled

The Linux I²C Core

• Linux provides generic code for communicating with an I² bus
  • A specific driver provides implementations of the bit-level operations to the core layer, via a i2c_algo_bit_data
  • It call the core layer to perform byte-level operations
  • The core calls back to perform bit-level operations
• For an example of how a driver uses the I2C core, see bttv-i2c.c
• It is not clear how robust this implementation is

References

• http://en.wikipedia.org/wiki/I2c : Wikpedia Introduction to I²C
• http://www.esacademy.com/faq/i2c/index.htm : Embedded Systems Academy I²C overview and FAQ
• http://www.i2c-bus.org/references/ : I²C spec and other references