What Is the I2C Bus?

I²C stands for inter–integrated circuit bus. There is no doubt, though, that the I²C protocol suffers from a serious terminology problem. IIC is the easiest—and presumably least popular—abbreviation. The two capital I’s may have caused this abbreviation to be despised because they resemble two 1s, two lowercase l’s, the 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 I²C (“I two C”), which avoids the inconvenience of superscript formatting and is also somewhat easier to pronounce than “I squared C.”

When you realize that SMB or SMBus is reportedly used as yet another way to refer to the I²C bus, the final layer of fog begins to envelop you. These acronyms actually refer to the System Management Bus, which is different from the I²C bus but nearly identical to it. Phillips Semiconductor created the original I²C protocol, and Intel later defined the SMBus protocol as an expansion of I2C. The minor distinctions between the two buses, if any, are listed on page 57 of the System Management Bus Specification. The two buses are largely interchangeable.

Like attempting to have a crucial conversation in a crowded room

You must consider how challenging it is to achieve dependable yet flexible communication between numerous independent components in order to fully appreciate the clever strategies that make I2C so successful. If you have one chip that is always the master and one chip that is always the slave, the situation is manageable. However, what if you have several slaves? What if the slaves are unaware of their master’s identity? What happens if there are several masters? And What happens if a master asks a slave that has stopped working for some reason for data? What if a transmission is in progress and the slave stops working? What happens if a master requests the bus to make a transmission but crashes before giving it back?

The point is that in this kind of communication environment, a lot of things can go wrong. This is important to remember when learning about I2C because otherwise, the protocol will appear to be incredibly difficult and finicky. The truth is that I2C’s additional complexity makes flexible, extensible, reliable, low-pin-count serial communication possible.

Overview of I2C Bus Communication

Before we get into any details, here are the key characteristics of I²C:

• No matter how many devices are on the bus, only the clock and data signals are used.
• Through the use of suitable resistors of the proper size, both signals are raised to a positive power supply voltage.
• Every device uses open-drain (or open-collector) output drivers to connect to the clock and data signal.
• A 7-bit address uniquely identifies each slave device,. And the master needs to be aware of these addresses in order to communicate with a specific slave.
• A master is the one who starts and stops all transmissions; he can send data to one or more slaves or request data from a slave.
• The terms “master” and “slave” are inherently mutable; any device that has the required hardware and/or firmware can act as a master or a slave. In reality, however, embedded systems frequently use an architecture in which a single master communicates with numerous slaves and collects data from them.
• The rising edge of the clock signal is used to sample the data signal, and the falling edge is used to update it.

• The ACK/NACK (acknowledge or not-acknowledge) bit is a one-bit handshaking signal that follows each byte of data during transmission.

Advantages of I2C? I2C vs UART vs SPI

The advantages of I²C can be summarized as follows:

• adapts to the needs of different slave devices
• maintains low pin/signal count even with numerous devices on the bus
• incorporates ACK/NACK functionality for improved error handling
• readily supports multiple masters

Disadvantages

• imposes protocol overhead that reduces throughput
• increases the complexity of firmware or low-level hardware
• requires pull-up resistors, which
  • limit clock speed
  • consume valuable PCB real estate in extremely space-constrained systems
  • increase power dissipation

These observations show that I2C is best suited when there is a complex, wide-ranging, or large network of communicating devices. Because there is no standardized method of addressing various devices. Or sharing pins, UART interfaces are typically used for point-to-point connections. SPI works well when there is only one master and a small number of slaves,. But when there are many devices on the bus, routing becomes challenging because each slave requires a separate “slave select” signal. Additionally, SPI is awkward when supporting multiple masters. If throughput is your primary concern, I2C may need to be specifically avoided. Because SPI supports higher clock frequencies and has less 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, I²C should probably be considered a last resort.