This article covers the essential characteristics and prominent advantages of the Inter–Integrated Circuit (aka I2C) serial-communications protocol.

Communicating via Alphabet Soup

It should come as no surprise that a common feature of electronic systems is the need to share information among two or three or ten separate components. Engineers have developed a number of standard protocols that help different chips communicate successfully—a fact that becomes apparent when you confront the barrage of acronyms under “Communications” in the list of features for a microcontroller or digital signal processor: UART, USART, SPI, I2C, CAN. . . . Each protocol has its pros and cons, and it is important to know a little about each one so that you can make an informed decision when choosing components or interfaces.

This article is about I2C, which is typically used for communications between individual integrated circuits located on the same PCB. Two other common protocols that also fit into this general category are UART (Universal Asynchronous Receiver/Transmitter) and SPI (Serial Peripheral Interface). You need to know the basic characteristics of I2C before you can thoroughly understand a comparison between these three interfaces, so we will discuss that topic at the end of this article.

Many Names, One Bus

There is no doubt that the I2C protocol suffers from a serious terminology problem. The actual name is Inter–Integrated Circuit Bus. The most straightforward—and probably theleastcommon—abbreviation is IIC. Perhaps this abbreviation has been disdained because the two capital I’s look like two 1s, or two lowercase l’s, or roman numeral II, or the symbol for parallel resistors. . . . In any event, the abbreviation I²C (spoken as “I squared C”) gained popularity, despite the questionable logic of treating a normal letter as if it is a variable subject to exponentiation. The third option is I2C (“I two C”), which avoids the inconvenience of superscript formatting and is also somewhat easier to pronounce than “I squared C.”

The final layer of fog settles in when you notice that SMB or SMBus is apparently used as yet another way of referring to the I2C bus. Actually, these abbreviations refer to the System Management Bus, which is distinct from, though almost identical to, the I2C bus. The original I2C protocol was developed by Phillips Semiconductor, and years later Intel defined the SMBus protocol as an extension of I2C. The two buses are largely interchangeable; if you are interested in the minor differences between them, refer to page 57 of the System Management Bus Specification.

Like Trying to Have an Important Conversation in a Room Full of People . . .

To appreciate the clever techniques that make I2C so effective, you need to think about the difficulty of achievingreliableyetversatilecommunication between multiple independent components. The situation is simple enough if you have one chip that is always the master and one chip that is always the slave. But what if you have multiple slaves? What if the slaves don’t know who the master is? What if there are multiple masters? What happens if a master requests data from a slave that for some reason has become nonfunctional? Or what if the slave becomes nonfunctional in the middle of a transmission? What if a master claims the bus to make a transmission then crashes before releasing the bus?

The point is,there are a lot of things that can go wrong in this sort of communication environment. You have to keep this in mind when you are learning about I2C, because otherwise the protocol will seem insufferably complicated and finicky. The fact is, this extra complexity is what allows I2C to provide flexible, extensible, robust, low-pin-count serial communication.

Overview

I2C vs. UART and SPI

The advantages of I2C can be summarized as follows:

And here are some disadvantages:

We can see from these points that I2C is especially suitable when you have a complicated, diverse, or extensive network of communicating devices. UART interfaces are generally used for point-to-point connections because there is no standard way of addressing different devices or sharing pins. SPI is great when you have one master and a few slaves, but each slave requires a separate “slave select” signal, leading to high pin count and routing difficulties when numerous devices are on the bus. And SPI is awkward when you need to support multiple masters.

You may need to intentionallyavoidI2C if throughput is a dominant concern; SPI supports higher clock frequencies and minimizes overhead. Also, the low-level hardware design for SPI (or UART) is much simpler, so if you are working with an FPGA and developing your serial interface from scratch, I2C should probably be considered a last resort.

Conclusion

We have presented the salient characteristics of I2C, and we now know enough about the protocol’s pros and cons to allow for an informed decision on which serial bus you might choose for a given application. In future articles we will explore the protocol, and how to actually implement it, in more detail.