【Translation】Understanding the I2C bus

Welcome to visit my personal blog at the same time: https://codinglover.top

This is the Chinese translation of the Texas Instruments application document SLVA704, the original title is: Understanding the I2C Bus. Compared with the dozens of pages of I2C standard documents produced by Philips, this document has only 8 pages, but it is enough for those who want to understand the standard I2C bus and apply it.
Original address: https://www.ti.com/lit/an/slva704/slva704.pdf

overview

The I2C bus is a very popular and powerful bus, which is mostly used in scenarios where one (or more) hosts communicate with one or more slave devices. Figure 1 shows that many different peripherals can share this bus, which requires only two wires to connect to the processor, which is one of the biggest advantages that the I2C bus can provide compared to other interfaces.
The goal of this application note is to help users understand how the I2C bus works.
Figure 1 shows a typical I2C bus used in an embedded system, on which various slave devices are mounted. The slave microcontroller acting as the I2C master controls the IO expansion, various sensors, EEPROM, multiple ADCs/multiple DACs, etc. All these devices need only be controlled by two pins from the host.

insert image description here
Quoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

1 Electrical Characteristics

The I2C bus uses an open-drain output controller with an input buffer on the same line, which allows bidirectional data streaming on a single data line.

1.1 Open-drain for bi-directional communication

An open-drain output allows pulling the voltage on the bus low (to ground in most cases), or releasing the bus to allow it to be pulled high by a pull-up resistor. When the bus is released by the master or slave, the pull-up resistor on the line is responsible for pulling the voltage on the line up to the power rail. Since there is no device that can output a high level on the bus, this means that the bus will not encounter a short circuit problem caused by one device outputting high and another device trying to output low (power rail to ground) during communication. ). The I2C bus requires a single master in a multi-master environment to abort communication when the output is high while the actual bus level read back is low (meaning another device pulled it low) because another device is using the bus. The interface using the push-pull output mode is not so free, which is also a priority of the I2C bus.

insert image description here
Quoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

Figure 2 shows the simplified internal structure of the master-slave device on the SDA/SCL line, which consists of a buffer for reading data and a pull-down FET for sending data. A device is only allowed to pull the bus down (specified as a short to ground) or release the bus (high impedance to ground) to allow the pull-up resistor to pull the bus level up. When dealing with I2C devices, there is an important concept to clarify: no device can hold the bus high. This feature enables two-way communication.

1.1.1 Open-drain pull-down

As mentioned in the previous chapter, the open-drain output can only pull the bus low, or release the bus and then pull the bus high by the pull-up resistor. Figure 3 shows the current flow when the bus is pulled low. When the logic circuit wants to send a low level, it enables the pull-down FET, which pulls the line low by shorting it to ground.

insert image description here
Quoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

1.1.2 Open-drain release bus

When the slave or master wants to transmit a logic level high, it can only release the bus by enabling the FET. This will leave the bus in a floating state, and the pull-up resistor will pull the bus level up to the supply rail, which is treated as a high level. Figure 4 shows how current flows through a pull-up resistor used to pull the bus high.

insert image description here
Quoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

2 I2C interface

2.1 Common operations of I2C

The I2C bus is a bidirectional interface that communicates with slave devices using a controller called a master. The slave will not actively transmit any data unless it is addressed by the master. Each device on the I2C bus has a unique device address to distinguish it from other devices on the same bus. Many slaves require configuration after startup to set device behavior. This is usually done when the master accesses the slave's internal register map, which has a unique register address. A single device can have one or more registers that can be used to store or read and write data.
The physical interface of the I2C bus consists of a serial clock line (SCL) and a serial data line (SDA). Both SCL and SDA need to be connected to Vcc through pull-up resistors. The size of the pull-up resistor is determined by the equivalent capacitance on the I2C line (for more information, please refer to the document I2C Pull-up Resistor Calculation, document number: SLVA689). Data transfers can only be initiated when the bus is free. If both SDA and SCL are in a high level state after a STOP flag, the bus can be considered to be in an idle state at this time.
The general process of the master accessing the slave is as follows:

  1. Suppose a master wants to send data to a slave:
    1. The sending master sends a START flag and addresses the receiving slave
    2. The sender master sends data to the receiver slave
    3. The sending host ends the transfer by sending a STOP flag
  2. If master wants to receive/read data from slave:
    1. The receiver master sends a START flag and addresses the sender slave
    2. The receiver host sends the address of the register to be read to the sender slave
    3. Receiver master receives data from sender slave
    4. The receiver host ends the communication by sending a STOP flag

2.1.1 START and STOP signs

The host can initiate I2C communication with the device by sending a START flag, or end the communication by sending a STOP flag. When SCL is high, a falling edge on SDA means a START flag, and a rising edge on SDA means a STOP flag.

insert image description hereQuoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

2.1.2 Repeated START flags

The repeated START flag has a similar effect to the usual START flag, and it is used to replace the two when it is used in the case of the STOP flag followed by the START flag. It looks identical to the START flag, but unlike the START flag, repeated START flags appear before the STOP flag (that is, when the bus is not idle). This is very useful when the master wants to start a new communication, but does not want to send the STOP flag to make the bus idle, which can prevent the current master's bus control from being seized by other masters (when in a multi-master environment).

2.2 Data validity and byte format

A data bit is transferred with every clock pulse on SCL. A single byte consists of 8 bits of data on the SDA line, which can be a device address, register address, or data read from/written to a device. Data is transferred big-endian (MSB). Any number of data bytes can be transferred between the START flag and the STOP flag. The data on the SDA line must remain stable when the clock level is high, because when the SCL line is high, the change on the SDA line will be regarded as a control command (START or STOP).

insert image description hereQuoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

2.3 Acknowledgment (ACK) and non-acknowledgement (NACK)

Every byte of data (including the address byte) is always followed by 1 ACK bit from the receiver. The ACK bit allows the receiver to tell the sender that the current byte was successfully received and that the next byte can be sent.
The sender must release the bus before the receiver sends an ACK bit. The receiver sends an ACK bit by pulling the SDA line low at the low level phase of the ACK/NACK clock cycle (9th clock cycle), so that the SDA line will remain at the high level phase of the ACK/NACK clock cycle is low level. Setup and hold times must be carefully considered.
If the SDA line remains high during the ACK/NACK clock cycle, this will be taken as a NACK. There are several states that will result in a NACK:

  1. The receiver cannot receive or send because it is performing some real-time function and cannot communicate with the host.
  2. During transmission, the receiver received unrecognized data or commands.
  3. During the send, the receiver cannot receive any more data bytes (that is, the buffer is full).
  4. The master as the receiver has finished reading the data, so it notifies the slave by sending a NACK.

insert image description hereQuoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

3 I2C bus data

Data can be written to/read from the slave, but this is done by reading and writing registers inside the slave.
Registers that contain information, whether it is configuration information or some sampled data that needs to be sent back to the master, reside in the slave's memory. In order to instruct the slave to perform a certain task, the master must write information into these registers.
Although it is common for I2C slaves to have multiple registers, it should be noted that not all slaves are like this. For a simple slave with only a single register, the single register can be written directly by sending data directly after the slave address without addressing the register. An 8-bit I2C switch controlled via the I2C bus is a good example of a single-register device. Since it enables/disables a channel through 1 bit, only 1 register is required, and the master can directly write register data after the slave address, skipping the register coding part.

3.1 Write to the slave on the I2C bus

To perform a write operation on the I2C bus, the master sends a START flag and the slave address to the bus, and sets the last 1 bit (read and write bit) to 0 to indicate that this is a write operation. After the slave sends the acknowledge bit, the master sends the address of the register it wants to write. The slave responds again, notifying the master that the slave is ready. After this, the master starts sending register data to the slave. When the host has sent all the data it needs to send (sometimes just a byte), it will end the communication by sending a STOP flag.
Figure 8 shows an example of writing a single byte to a slave register.

insert image description hereQuoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

3.2 Read the slave on the I2C bus

Reading data from a slave is similar to writing data, but with some extra steps. In order to read from a slave, the master must first instruct the slave itself which register it wants to read. This step is done by performing a start communication step similar to the write operation, sending the device address with the read and write bits set to 0 (meaning a write operation), followed by the address of the register to be read. Once the slave responds to this address, the master will send the START flag again and send the device address with the read and write bit set to 1 (meaning a read operation). At this point, the slave will acknowledge the read request, while the master releases the bus but maintains clock supply to the slave. In this part of the communication flow, the master will act as the receiving master, while the slave will act as the sending slave.
The master will continue to send clock pulses, but will release the SDA line for the slave to transfer data. At the end of each byte of data, the master will send an ACK to the slave to let the slave know that the master is ready to receive more data. Once the master has received the expected number of bytes, it will send a NACK, telling the slave to terminate the communication and requesting the slave to release the bus. Then the host will send a STOP flag to end the communication.
Figure 9 shows an example of reading a single byte from a slave register.

insert image description hereQuoted from document: https://www.ti.com/lit/an/slva704/slva704.pdf

Guess you like

Origin blog.csdn.net/lczdk/article/details/117608260