Serial Communications Protocols Part Six - I2C

Mark Harris
|  Created: May 24, 2021  |  Updated: July 8, 2021
Serial Communications Protocols Part Six - I2C

In this next installment in our series on serial communications protocols, we’re looking at the popular I2C protocol. This follows on from the preceding articles where we are looking at some of the different types of Serial Communication Protocols available. These provide a practical solution to the transfer of data between devices over reasonably short distances. Typical applications include the capture of large amounts of data from data-producing peripherals by microcontrollers.

This series covers some of the more popular protocols. At the end of this series, we will conclude by looking at each protocol's advantages and disadvantages. We hope you will find this series valuable next time you want to implement a serial communication bus as part of your design

I2C (pronounced I-squared-C) stands for Inter-Integrated Circuit. In a nutshell, it’s a single-ended, synchronous, multi-master, multi-slave, package switched serial communication bus. We’ll now explain what this mouthful means.

As it is synchronous, this means that it has a clock line. This type of communication protocol is very widely used by microcontrollers to transmit data or communicate with devices over short distances. Although the I2C was invented by Philips Semiconductor (now NXP), many other manufacturers produce ICs that are compatible with or utilize the I2C communications protocol. SMBus is a protocol that is essentially compatible with I2C with the primary difference being SMBus having a lower maximum frequency, a timeout function, and lower maximum current - the discussion in this article there is therefore highly applicable to SMBus as well.

The I2C bus has devices designated as master devices and slave devices. The master device is the one that generates the clock signal and initiates communication with slaves. The slave device is the one that receives the clock signal and responds when addressed by the master. The I2C bus can be multi-slave, and multi-master, which means that one master device can have several slaves, and one slave device can have several masters:

I2C multi-slave and multi-master wiring example
I2C multi-slave and multi-master wiring example

The I2C protocol has three basic message format types; each message begins with a START signal and then ends with a STOP signal. In the first message format, a single message is sent by a master to a slave, which transfers data to the slave. In the second message format, a single message is sent by a master to a slave, which transfers data from the slave back to the master. In the final combined message format, a master sends multiple read or write commands to one or more slave devices. Each command must include the address of the target slave device.

The I2C bus consists of two transmission lines, excluding the ground. Typically, an I2C bus consists of an SCL line, which is the clock signal, and an SDA line, which is the data signal. The clock line is unidirectional, going from the master to the slave. 

This is a half-duplex serial communication, which means that the data can be sent only in one direction at any one time, so the master and slave cannot send data simultaneously.

I2C wiring example with pull-up resistors
I2C wiring example with pull-up resistors

The I2C has either an open-drain or an open-collector output, which means that the driver can pull the line low but cannot drive it high. The bus requires external pull-up resistors which set each line’s idle state to high, i.e. when no device is pulling it low:

I2C masters and slave drivers simplified hardware example
I2C masters and slave drivers simplified hardware example

The pull-up resistors also determine the bus’s communication speed, dependent on the bus’s total capacitance. Higher value pull-up resistors will lower the communications rate, while a lower resistance value will give a higher communication rate. The communication speed will also be significantly determined by the internal drivers. More substantial (higher current capability) drivers will produce a faster rise and fall time and increase the potential communication rates. A good rule of thumb is to start by considering using pull-up resistors with a value of 4.7 kΩ and then adjust if necessary. Also, reducing communication rates when higher speeds are not required can be good practice, as it makes the capacitance effect much lower, and the bus’s power consumption will also be lower. However, the resistor value must be somewhere between the specified allowable limits, or else it could result in transmission errors as demonstrated in the diagram below:

Signal examples for different chosen values of pull-up resistors
Signal examples for different chosen values of pull-up resistors

The required pull-up resistor value also can be calculated using the following formula:

Where the minimum resistance value is calculated using:


VCC– Is the I2C High level (pull-up) voltage
VOL - Is the valid logical low level for an I2C driver
IOL - Is the required driver current to pull the logic level low (discharging the capacitance)

And the maximum resistance value is calculated using:


Tr – Is the rise time of both SCL and SDA lines
Cb – Is the capacitance load of each bus line

The typical parameters of an I2C bus are as follows:


In addition, the following graphs show how the different requirements affect the minimum and maximum pull-up resistor limits:

Minimum and maximum pull-up resistor value graphs
Minimum and maximum pull-up resistor value graphs​​​​​​

We also have to consider that the I2C bus can be used with multiple voltage level devices. For example, you can connect a common bus to both 5 V and 3.3 V devices by connecting the pull-up resistors to a 3.3 V source. This will then be compatible with both device types. However, in some cases, this would not work as, for example, where both 5 V and 1.2 V devices are used. Here the highest voltage of 1.2 V used by one device would be read as a low or unknown voltage by the other. In these circumstances, a logic level converter is the right solution to enable both device types to use a common bus.

Below is an example time diagram showing the data bits on the I2C bus:

An example of data packages in I2C
An example of data packages in I2C
  1. In the data transfer start condition (S), SDA is pulled low, while SCL is kept high
  2. The SCL is then pulled low, and the SDA sets the first data bit level while keeping SCL low. (Blue bar)
  3. The data from SDA is sampled while SLC stays high. The SDA must not change state between the rising and falling edge of the SLC (Green bar)
  4. The process repeats at the set bit rate
  5. The final bit is set by a clock pulse during which SDA is pulled low in preparation for the stop bit
  6. The stop condition (P) appears when SCL rises and follows the rising edge of the SDA

Usually, one master I2C communication device can support up to 1008 slave devices. However, this makes the hardware design very complicated and requires the I2C bus to be operated at its lowest speeds. This is because the very long transmission line’s capacitance increases, making the signal rise and fall times slower. The problem for a high-speed bus is that when capacitance increases too much, the bits can overlap because of the signal’s increased rise and fall times.

One solution is that if the  bus includes too many slave devices, buffering or multiplexing techniques can be used to split the single long bus into smaller segments. This will help keep the bus segment’s capacitance below the maximum allowable value and even allow several devices with the same address to be separated using a multiplexer.

Buffering is used to isolate the capacitance of each segment from the others and allowing separate slaves and masters to be used over longer wires or traces. 

Buffering and multiplexing techniques on I2C bus
Buffering and multiplexing techniques on I2C bus

There are occasions when a slave device may need to force the clock low when it needs to delay the master sending more data. Typically, this occurs when the slave needs time to prepare data before sending it to the master. For example, to complete an analog to digital conversion or if an EEPROM store command hasn’t completed writing to non-volatile memory yet. This operation is known as “Clock Stretching.”

For a master device to communicate with several slave devices, an addressing mechanism is required. Most of the time, the slave device address will be set by pins on the device being pulled low or high. When the master device sends a command, this is received by all devices connected to the bus. However, at the beginning of each message, the master sends a set of addressing bits. The result is that only one device will respond to the command, which will be the one to which the command is addressed. The other slave devices will ignore the command.

There are a considerable number of ICs available that can use an I2C bus. Some examples of these components and their applications are:

  • RTC (Real-Time Clock)
  • Low-speed DAC (Digital to Analog Converter) or ADC (Analog to Digital Converter)
  • Color balance settings for a display data channel
  • Changing sound volume in intelligent digital speakers
  • Communicating with external memory devices, such as EEPROM
  • Controlling OLED or LCD displays
  • Turning power supplies ON and OFF 


This article has looked at some features of the popular I2C protocol and discussed some of its advantages and implementation details. In the other articles in this series, we will look at some of the alternate serial communication protocols available.

Have more questions? Call an expert at Altium and discover how we can help you with your next PCB design.

About Author

About Author

Mark Harris is an engineer's engineer, with over 12 years of diverse experience within the electronics industry, varying from aerospace and defense contracts to small product startups, hobbies and everything in between. Before moving to the United Kingdom, Mark was employed by one of the largest research organizations in Canada; every day brought a different project or challenge involving electronics, mechanics, and software. He also publishes the most extensive open source database library of components for Altium Designer called the Celestial Database Library. Mark has an affinity for open-source hardware and software and the innovative problem-solving required for the day-to-day challenges such projects offer. Electronics are passion; watching a product go from an idea to reality and start interacting with the world is a never-ending source of enjoyment. 

You can contact Mark directly at:

Recent Articles

Back to Home