What is I2C?

I2C (Inter-Integrated Circuit) is a multi-controller, multi-target, half-duplex synchronous communication protocol over a 2-wire interface.

Advantages:

  • Addressable nodes for low pin count requirement
  • Improved error handling by incorporating ACK/NACK functionality
  • Supports multiple controllers through bus arbitration

Disadvantages:

  • Increased firmware complexity
  • Slower throughput due to protocol overhead and half-duplex design
  • Required pull-up resistors limit clock speed, use extra PCB space, and increase power consumption
  • Used only over short to medium distances

The I2C protocol is half-duplex, so information travels in only one direction on the bus at a given time. One clock source is shared between all devices which determines the communication speed. The physical layer of the bus is set up with two wires labeled SDA for serial data and SCL for serial clock. Drivers only pull down the communication lines so pull-up resistors are needed to complete the physical layer. I2C is generally used for short to medium distances and requires less board space due to the reduction of wires needed.

One or more controller devices control who sends data and where. One or more target devices simply wait to be addressed. I2C can be configured to use either 7- or 10-bit addressing, which means it can support up to 128 or 1024 devices on the bus, although you will likely exceed maximum bus capacitance before reaching those limits.

8-bit_I2C_Master3.png

The basic structure of a read transaction is a start bit, a control byte, one or more data bytes followed by a stop bit. Each transmission is followed by an acknowledge (ACK) bit or a non-acknowledge (NACK) bit.

I2C Read

Let’s review an example of a controller device reading one byte from a target. The bus starts in Idle mode, which means the SDA and SCL are both high. To start the transaction, the controller pulls the SDA link low while SCL is high to send a start bit (S).

I2C-Read.png

This example is based on 7-bit addressing so the controller sends a unique 7-bit target address to identify the required node by controlling the SDA line for each SCK pulse. For a data bit to be valid, the SDA line must remain constant between the rising and falling edge of clock pulses.

The controller then sends a single R/W bit indicating whether data will be read or written to complete the control byte. This is a read operation so this bit will be 1. The target then sends an ACK bit by pulling the SDA line low before the falling edge of the ninth clock pulse.

Having acknowledged the transmission, the target sends the requested data byte across the data line. The controller then acknowledges the received byte, and the target starts transmitting the next byte. The controller sends a stop bit (P) by releasing the SDA before SCL to complete the data frame.

Here’s a flowchart for the I2C read operation from the perspective of the controller to better see the process from a software implementation perspective:

I2C-Read-Flowchart.png

Now imagine having tens to hundreds of controllers attempting to control the bus simultaneously! This condition is resolved through “clock arbitration” and is covered by the protocol definition. Essentially, the controller with the earliest dominant low data bit wins control of the bus and the others drop off to try again later.

I2C Write

An I2C write is very similar. The differences are the R/W bit in the last position of the control byte is 0, data is provided by the controller, ACK/NACKs are provided by the target after each data byte and a stop bit is sent by the controller to end the transaction.

I2C-Write.png
I2C-Write-Flowchart.png

For more information about I2C operations, the following information is available:

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.