Inter-Integrated Circuits — I2C Basics (Part 1)
The Serial Communication protocol
In this post, we will discuss all the theoretical concepts that you need to know regarding I2C before programming/testing it on real devices.
This will be a 3 part series Inter-Integrated Circuits — I2C Basics and Inter-Integrated Circuits — I2C Basics (Part 2) and Inter-Integrated Circuits — I2C Basics (Part 3)
Inter-Integrated Circuit (I2C)
As the name suggests, Inter-IC (or the Inter-Integrated Circuit), often shortened as I2C (pronounced eye-two-see), I2C (pronounced eye-squared-see), or IIC, was developed as a communication protocol to interact between different ICs on a motherboard, a simple internal bus system. It is a revolutionary technology developed by Philips Semiconductor (now NXP Semiconductors) in 1982, and is used to connect low speed peripherals (like keyboard, mouse, memory, IO/serial/parallel ports, etc.) to the motherboard (containing the CPU) operating at much higher speed.
These days you can find a lot of devices which are I2C compatible manufactured by a variety of companies (like Intel, TI, Freescale, STMicroelectronics, etc). Somewhere around the mid-1990s, Intel devised the SMBus protocol, a subset of I2C with strict protocols. Most modern day I2C devices support both, I2C and SMBus with little reconfiguration.
I2C Bus Interface
The most compelling thing about the I2C interface is that the devices are hooked up to the I2C bus with just two pins (and hence it is sometimes referred to as Two Wire Interface, or the TWI). Well of course, we do need two more pins for Vcc and ground, but that goes without saying.
As you can see in the above diagram (taken from eeweb.com), all the devices are hooked up to the same I2C bus with just two pins. These devices could be the CPU, or IO devices, or ADC, or any other device which supports the I2C protocol. All the devices connected to the bus are classified as either being Master or Slave (just like SPI). We will discuss about it in a little while.
For now, let’s get to know more about the bus itself. The I2C bus consists of two bidirectional “open-drain” lines — SDA and SCL — pulled up with resistors as shown below.
Serial Data Line (SDA)
The Serial Data Line (SDA) is the data line (of course!). All the data transfer among the devices takes place through this line.
Serial Clock Line (SCL)
The Serial Clock Line (SCL) is the serial clock (obviously!). I2C is a synchronous protocol, and hence, SCL is used to synchronize all the devices and the data transfer together. We’ll learn how it works a little later in this post.
Open-Drain Lines
A little while ago (just above the previous image), I mentioned that SDA and SCL are open-drain (also called open-collector) lines pulled up with resistors. What does that mean? It means that the devices connected to the I2C bus are capable of pulling any of these two lines low, but they cannot drive them high. If any of the devices would ever want to drive the lines high, they would simply need to let go of that line, and it would be driven high by the pull up resistors (R1 and R2 in the previous image, or Rp in the next image).
For those who are interested, let’s have a closer look. Others, please skip this section and go to the next to next section (voltage levels and resistor values).
In the above image, you can clearly see the NMOS transistors inside the devices. In order for the device to pull any of the two lines low, it needs to provide a high voltage to the gate of the transistor (that’s how an NMOS transistor operates, right?). If the gate voltage is low, the NMOS transistor is not activated and the corresponding line is driven high.
I2C Data Validity
For the data to be valid on the SDA line, it must not change while the SCL is high. The data on the SDA line should change only and only when the SCL line goes low. If this standard is not followed, the data transfer becomes flawed, in which case it becomes a start/stop sequence (discussed later in this post). The following image illustrates the same.
Voltage Levels and Resistor Values
I2C supports a wide range of voltage levels, hence you can provide +5 volts, or +3.3 volts as Vcc easily, and other lower/higher voltages as well. This gives us a wide range of choices for the values of the pull-up resistors (R1 and R2). Anything within the range of 1k to 47k should be fine, however values lower than 10k are usually preferred.
Master and Slave
The concept of Master and Slave in I2C is quite similar to that of SPI. Just like SPI, all the devices are either Master or Slave. Master is the device which initiates the transfer and drives the clock line SCL. On a single I2C bus, there are usually multiple Slaves connected to a single Master.
However, just like SPI, we can also have multiple Masters connected to the same I2C bus. Since we want our lives to be a little simpler, we usually avoid such cases, but however I2C supports multi-bus master collision detection and arbitration for such cases (doesn’t make sense? Let’s forget about it for now!).
Speed
I2C supports serial 8-bit bi-directional data transfers up to a speed of 100 kbps, which is the standard clock speed of SCL. However, I2C can also operate at higher speeds — Fast Mode (400 kbps) and High Speed Mode (3.4 Mbps). Most of the devices are built to operate up to speeds of 100 kbps (remember that we discussed that I2C is used to connect low-speed devices?).
I2C Bus Transaction
Alright, now that we are familiar with the I2C bus interface, let’s look into how the data transfer actually takes place through that interface. I2C supports unidirectional as well as bidirectional data transfer as mentioned below. We will discuss about them in detail towards the end of the post.
- Unidirectional Data Transfer
- Master-transmitter to Slave-receiver (Case 1)
- Slave-transmitter to Master-receiver (Case 2)
- Bidirectional Data Transfer
- Master to Slave and Slave to Master (Case 3)
Start/Stop Sequence
In order for the Master to start talking to the Slave(s), it must notify the Slave(s) about it. This is done using a special start sequence. Remember a little while ago we discussed about I2C data validity — that the SDA should not change while the SCL is high? Well, it doesn’t hold good for the start/stop sequence, which is why it makes them special sequences!
When the SCL is high and SDA goes from high to low (as shown in the following diagram), it marks the beginning of the transaction of Master with the Slave(s).
And when the SDA goes from low to high while the SCL is still high (as shown in the following diagram), it marks the end of the transaction of that Masterwith the Slave(s).
Acknowledge Scheme
As mentioned earlier, I2C transfers 8 bits (1 byte) of data at a time. After the transfer of each byte is complete, the receiver must acknowledge it. To acknowledge, the receiver sends an ACK bit back to the transmitter. Here’s how it goes–
- The transmitter (could be either Master or Slave) transmits 1 byte of data (MSB first) to the receiver during 8 clock pulses of SCL, after which it releases the SDA line i.e. the SDA line becomes HIGH for the ACK clock pulse.
- The receiver (could be either Master or Slave, it depends) is obliged to generate an acknowledge after each byte sent by the transmitter by pulling the SDA line LOW for the ACK clock pulse (9th clock pulse) of SCL.
- So overall, there are 9 SCL clock pulses required to transmit a byte of data. This is shown in the diagram below with the assumption that Master is the transmitter.
So far so good. But what if the receiver does not (or could not) acknowledge the data sent to it? What happens then? Does the entire system break down?
Well, there are two cases to that situation.
See these 2 cases here
Check out about author’s life in (My story right now) section at the end of each post from Jan 2020.
My story right now section is at the end of Part 3 of this series.
See you next time
SS
Thanks for reading.
Until next time
Peace, Love and Gratitude.
