What is the I2C Communication Protocol?

Inter-Integrated Circuit Protocol (I²C or IIC) is a serial, synchronous, multi-master, board-to-board, half-duplex communication protocol. As the name suggests, it is mainly used for communication within printed circuit boards (PCBs). Philips Semiconductors invented it in 1982 with the agenda of using fewer microcontroller pins to work with other electronic devices. It uses only two lines to communicate with the connected devices; therefore, it is also called the Two Wire protocol at times. I²C supports master-slave configuration, but the terminologies here change from master-slave to controller-target or controller–peripheral.

The physical interface of I²C consists of two lines: SDA and SCL. SCL (Serial Clock) is the bus master's clock signal, and SDA (Serial Data) is the data signal. I²C drivers are “open-drain,” meaning the device can only ground the output, or place its output in a high-impedance state, meaning it cannot drive its output to logic 1. A high impedance state means the output is connected to nothing, i.e., it is in a floating state. A pair of external resistors, each on SDA and SCA lines, are connected to pull up the lines when the devices put their outputs in the high-impedance state. This open-drain configuration prevents a short circuit in the lines, as the master and all slaves connected together can never assert conflicting voltages to the same line.

The Clock In and Data In buffers of the I²C drivers serve as the input to the I²C devices as they are used to read the state of the lines. On the other hand, the MOSFET controls the output on the lines when the device is writing on the bus.

The I²C bus supports different modes, which support different bit rates for the data exchange.

It should be noted that these bit rates determine the speed of the data transfer across the bus, and not the processing speed of the device.

I²C protocol operates in the master-slave (controller-peripheral) configuration, therefore, read/write privileges on the bus are held only by the master. Master decides which slave will receive or send data to the master. I²C has a specialized data frame and can communicate with up to 128 devices on the bus.

In the idle state of communication, the SDA and SCL lines are pulled up. To initiate the communication, the master pulls the SDA line low while the SCL line is still high and alerts the slave devices on the bus to be ready for communication.

After this start condition, the master sends out a 7-bit address for the slave it wants to communicate with. The address is read by all the devices connected to the bus, and the device with that address responds to the master’s requests.

The 7-bit address is followed by a single R/W bit - ‘1’ is for a read operation, and ‘0’ is for a write operation. R/W decides who will take over the SDA line for data transfer, master or slave. The read and write operations are carried out from the master’s perspective and are as follows:

• Read operation - The master will receive the data that the slave transmits, hence it is also referred to as reading from the bus.
• Write operation - The master will transmit the data to the slave. Hence it is called writing to the bus.

It is important to note that it is the master (not the slave) which generates the clock signal on the SCL line to sample the data on the SDA line.

To check if the slave is connected to the bus or if it is busy or not, the master waits for an acknowledgment from the slave, i.e., the master waits for the slave to pull the SDA line low on the 9th clock cycle. If such a condition is satisfied, the master receives a positive response from the slave, called ACK. But if the SDA line remains high on the 9th clock cycle, it is called NACK. This mechanism enables the master to check whether the slave with the given address is present on the bus or not. Another use for ACK/NACK is to determine whether the slave has received the transmitted bits without any error or not.

The data sent or received by the master is the actual data for which the communication is being carried out. All other sections of the data frame are supporting mechanisms of the protocol. As mentioned earlier, there are two operations: Write and Read.

First, the master addresses the slave on the bus by sending out the 7-bit address. If the slave is present or active on the bus, it gets ready for the transfer. After that, the W bit is sent out by the master to notify the slave that the master will take over the SDA line and send the data to the slave. The master awaits an ACK from the slave on the next clock cycle. After receiving ACK from the slave, the master sends out the “data” bit by bit on every clock cycle. The master writes the data on the bus and hence it is referred to as the “write” operation in the I²C protocol.

If the master wants to receive the data from the slave, it addresses the slave on the bus and sends out a R bit, and awaits an ACK from the slave. After receiving ACK from the slave, the slave is permitted by the master to take over the SDA line to transmit the data to the master. The master here reads the data from the bus, hence this is referred to as “read” operation in the I²C protocol.

One of the advantages of using I²C over UART is that the communication is kept alive by the master, and there is no need to reinitialize the communication until all the data transfer is completed, meaning there is no limit to the number of bits that can be transmitted per data frame. For example: If the master wants to write 32 bits of data to the slave, there is no need to start and end the communication 4 times (8 bits at a time). After every ACK from the slave, another chunk of 8 bits can be sent to the slave. Unlike UART, I²C reduces the overhead caused by start & stop bits for every data frame. But we need to end the frame if we want to change the operating mode from read to write or vice-versa.

Apart from reducing the overhead of bits, ACK/NACK also works as an error-checking mechanism in the I²C bus. For the write operation, if the master receives NACK from the slave, it resends the data to the slave. And if NACK is received when the master is reading from the slave, the master discards the bits it has received.

When the transfer is complete, the master asserts a stop condition by changing the SDA line from low to high while the SCL is high. This completes the transaction and puts the communication back in the idle state.

With that, we’ve completed the explanation of the I²C data frame and all of its sections. But that’s not all. I²C offers some really cool features which are extremely helpful in creating a robust system. These features are not supported by all I²C devices, yet one needs to be aware of them.

As mentioned earlier, the bit rate supported by the device for I²C communication is not necessarily the data processing speed of the device. So what if the master requests some data from the slave and it is not ready with the requested data yet? As the master will expect ACK from the slave on the next clock cycle, and if the slave fails to pull the SDA line low, the master will consider that communication has failed. To overcome this limitation in communication, ‘clock stretching’ is used by the slave to notify the master that it is busy and needs more time to process the data. The slave achieves this by pulling the SCL line low, which halts the communication as data sampling in I²C is done on the rising edge of the SCL line. Not all I²C devices support clock stretching; therefore, the device's datasheet is required to verify this. This can also cause problems sometimes because if the device is faulty, and keeps the SCL line pulled down, the whole bus is halted, and the master cannot communicate with other slaves.

The I²C bus supports multiple masters and can talk to all the devices connected to the bus. The masters connected on the bus constantly monitor the SDA and SCL lines for start and stop conditions and hold the pending transfers until the bus is free again. This is how they operate concurrently on the same bus, but there may be a situation when the transfer is initiated by both masters simultaneously. To avoid this, the masters on the bus constantly monitor the SDA line to check whether the SDA line is pulled down by another master or not. If one of them detects that SDA is low when it should be high, it concludes that another master is currently active and promptly terminates its own transfer. This procedure is referred to as bus arbitration.

As shown in the above image, both Master A and Master B initiate data transfer at the same time. However, Master B manages to pull the SDA line low, while Master A wants the SDA line to be high. This conflict is detected by Master A, and it loses the arbitration, i.e., stops controlling the SDA line anymore.

Higher bit rates are very crucial for modern communication systems. For the data to be processed fast, it also needs to be fetched from the slaves fast. I²C supports a bit rate of 3.2Mbits per second. This means the I²C lines will change state between high and low 3.2 million times per second. Such fast switching of lines is made difficult by the high-capacitance on traces of PCB or the wires used for communication, and the rise time of the clock line increases. Rise time is the time taken by the line to transition from logic low to logic high. Below is an example of the difference in rise time per the capacitance in the line. The waveform in red has a capacitance of 30nF, and hence it rises much slower compared to the green waveform with a capacitance of 1nF.

To solve the problem of the increased rise time in the clock signal, pull-up resistors with resistance lower than 4.7 kΩ are used. This allows more current to flow in the lines, but that increases the power dissipation of the I²C lines. Hence there is a trade-off between speed and power dissipation in this protocol because, with increased speed, the power dissipation also increases.

I²C is widely used for connecting sensor breakouts, memory devices, displays, and other slaves to microcontrollers - as it requires minimal hardware connections. Due to its popularity in the hobbyist community, resources for implementing and debugging this protocol are available in abundance. We hope this tutorial has provided you with a clear understanding of how I²C works. We recommend checking out a practical tutorial put together by Arduino that shows I²C in action, a beginner-friendly Arduino tutorial on I²C protocol, which explains how to fetch data from an ultrasonic range finder.