SBAA565 November   2022 ADC081C021 , ADC081C027 , ADC101C021 , ADC101C027 , ADC121C021 , ADC121C021-Q1 , ADC121C027 , ADC128D818 , ADS1000 , ADS1000-Q1 , ADS1013 , ADS1014 , ADS1015 , ADS1015-Q1 , ADS1100 , ADS1110 , ADS1112 , ADS1113 , ADS1114 , ADS1115 , ADS1115-Q1 , ADS7823 , ADS7827 , ADS7828 , ADS7828-Q1 , ADS7830 , ADS7924 , AFE539A4 , DAC081C081 , DAC081C085 , DAC101C081 , DAC101C081Q , DAC101C085 , DAC121C081 , DAC121C085 , DAC43204 , DAC43401 , DAC43401-Q1 , DAC43608 , DAC43701 , DAC43701-Q1 , DAC53002 , DAC53004 , DAC53202 , DAC53204 , DAC53204W , DAC53401 , DAC53401-Q1 , DAC53608 , DAC53701 , DAC53701-Q1 , DAC5571 , DAC5573 , DAC5574 , DAC5578 , DAC60501 , DAC60502 , DAC63002 , DAC63004 , DAC63202 , DAC63204 , DAC6571 , DAC6573 , DAC6574 , DAC6578 , DAC70501 , DAC70502 , DAC7571 , DAC7573 , DAC7574 , DAC7578 , DAC7678 , DAC80501 , DAC80502 , DAC8571 , DAC8574

 

  1.   Abstract
  2.   Trademarks
  3. 1I2C Overview
    1. 1.1 History
    2. 1.2 I2C Speed Modes
  4. 2I2C Physical Layer
    1. 2.1 Two-Wire Communication
    2. 2.2 Open-Drain Connection
    3. 2.3 Non-Destructive Bus Contention
  5. 3I2C Protocol
    1. 3.1 I2C START and STOP
    2. 3.2 Logical Ones and Zeros
    3. 3.3 I2C Communication Frames
  6. 4I2C Examples
    1. 4.1 DAC80501 Example
      1. 4.1.1 DAC80501 DAC Data Register
      2. 4.1.2 DAC80501 I2C Example Write
    2. 4.2 ADS1115 Example
      1. 4.2.1 ADS1115 Configuration Register
      2. 4.2.2 ADS1115 I2C Example Read
      3. 4.2.3 ADS1115 Conversion Result
  7. 5Reserved Addresses
    1. 5.1 General Call
    2. 5.2 START Byte
    3. 5.3 C-Bus Address, Different Bus Format, Future Purposes
    4. 5.4 HS-Mode Controller Code
    5. 5.5 Device ID
    6. 5.6 10-Bit Target Addressing
      1. 5.6.1 10-Bit Target Addressing Write
      2. 5.6.2 10-Bit Target Addressing Read
  8. 6Advanced Topics
    1. 6.1 Clock Synchronization and Arbitration
    2. 6.2 Clock Stretching
    3. 6.3 Electrical Specifications
    4. 6.4 Voltage Level Translation
      1. 6.4.1 Example 1
      2. 6.4.2 Example 2
      3. 6.4.3 Example 3
      4. 6.4.4 Example 4
    5. 6.5 Pullup Resistor Sizing
      1. 6.5.1 Minimum Pullup Resistance Sizing
      2. 6.5.2 Maximum Pullup Resistance Sizing
  9. 7Protocols Similar to I2C
  10. 8Summary

3.3 I2C Communication Frames

The I2C protocol is broken up into frames. Communication begins with the controller device sending an address frame after a START. The address frame is followed by one or more data frames each consisting of one byte. Each frame also has an acknowledge bit to alert the controller that the target device or the controller device has received communication. Figure 3-3 shows a diagram of two I2C communication frames.

Figure 3-3 I2C Address and Data Frames

At the beginning of the address frame, the controller device initiates a START condition. The controller device first pulls SDA low and then pulls SCL low for the START. This allows the controller device to claim the bus without contention from other controller devices on the bus. Each I2C target device has an associated I2C address. When beginning communications with a particular target device the controller uses the target device address to send or receive data in the following I2C frames. The I2C address consists of 7 bits and devices on the I2C bus, each have a unique address on the bus.

A 7-bit address implies 27 (or 128) unique addresses. However, there are several reserved I2C addresses which limits the number of possible devices. Reserved addresses are discussed in Section 5. The address is sent with the SDA as the data and SCL as the serial clock. With this information, you can to read through the I2C communication of a device and understand what is being sent back and forth from the controller device and the target device.

The 8th bit of this frame following the address, is the read-write (R/W) bit. If this bit is 1, the controller is asking to read data from the target device. If this bit is 0, the controller asks to write data to the target device.

After any communication byte, an extra 9th bit is used to verify the communication was successful. At the end of the address byte communication, the target device pulls down the SDA during the SCL pulse to indicate to the controller that the address was received. This is known as an acknowledge (ACK) bit. If this bit is high, then no target device received the address and the communication was unsuccessful. If the bit is high, this is known as a NACK and there was no ACK.

The address frame is followed by one or more data frames. These frames are sent one byte at a time. After each data byte is transferred, there is another ACK. If the data byte is a write to the device, then the target device pulls the SDA low to ACK the transfer. If the data byte is a read from the device, the controller pulls the SDA low to acknowledge the data has been received. The ACK is a useful debugging tool. The absence of this bit can indicate that the target peripheral did not receive the proper I2C address for communication, or that the controller peripheral did not receive the expected data.

After the communication is completed, the controller issues an I2C STOP condition. SCL is first released and then SDA is released. The controller uses the STOP to indicate that the communication is completed and the I2C bus is released.

This is the basic protocol for any I2C communication between the controller device and the target device. Communication can consist of more than one byte of data. In some cases where a target device has multiple data and configuration registers, a read from a device can begin with a write to the device to indicate which register is to be read. The following sections show examples on how to read from and write to different data converter devices.