Should I2C and SPI Compete?

Nowadays, in the field of low-end digital communication applications, we often see I²C (Inter-Integrated Circuit) and SPI (Serial Peripheral Interface). The reason is that these two communication protocols are very suitable for short-distance low-speed communication between chips. Philips (for I²C) and Motorola (for SPI) developed these two standard communication protocols based on different backgrounds and market needs.

I²C was developed in 1982 to provide a simpler interconnection method for the CPU and peripheral chips inside televisions. Televisions were among the earliest embedded systems, and the initial embedded systems used memory-mapped I/O to interconnect microcontrollers and peripheral devices. To achieve memory mapping, devices had to be connected in parallel to the data and address lines of the microcontroller, which required many lines and additional address decoding chips, making it inconvenient and costly.

To save the microcontroller’s pins and additional logic chips, simplifying the printed circuit board and reducing costs, Philips Laboratories in the Netherlands developed the ‘Inter-Integrated Circuit’, IIC or I²C, a bus protocol that connects all peripheral chips using only two wires. The initial standard defined a bus speed of 100kbps. After several revisions, the main ones being 400kbps in 1995 and 3.4Mbps in 1998.

There are indications that the SPI bus was first introduced in 1979, with Motorola integrating the SPI bus into their first microcontroller chip modified from the 68000 microprocessor. The SPI bus is an external bus with four lines for microcontrollers (as opposed to an internal bus). Unlike I²C, SPI does not have a formal standard; it is merely a de facto standard, providing only a general abstract description of the communication operations, with chip manufacturers and driver developers communicating implementation details through data sheets and application notes.

SPI

For experienced digital electronics engineers, interconnecting two digital devices using SPI is quite intuitive. SPI is a four-signal line protocol (as shown):

• SCLK: Serial Clock (output from master);
• MOSI; SIMO: Master Output, Slave Input (output from master);
• MISO; SOMI: Master Input, Slave Output (output from slave);
• SS: Slave Select (active low, output from master).

SPI is a single-master communication protocol, which means that only one central device on the bus can initiate communication. When the SPI master device wants to read/write to a slave device, it first pulls down the corresponding SS line (SS is active low), then begins sending clock pulses on the clock line. During the corresponding pulse time, the master device sends signals to MOSI to achieve “write”, while sampling MISO to achieve “read”, as shown in the figure:

SPI has four operating modes—mode 0, mode 1, mode 2, and mode 3. The difference between them is defined by which edge of the clock pulse toggles the output signal and which edge samples the input signal, as well as the stable level of the clock pulse (whether the clock signal is high or low when inactive). Each mode is characterized by a pair of parameters known as clock polarity (CPOL) and clock phase (CPHA).

The master and slave devices must use the same working parameters—SCLK, CPOL, and CPHA—to function correctly. If there are multiple slave devices using different working parameters, the master device must reconfigure these parameters when reading/writing different slave devices. That summarizes the main content of the SPI bus protocol. SPI does not specify a maximum transmission rate, has no addressing scheme; SPI also does not define a communication acknowledgment mechanism and has no flow control rules. In fact, the SPI master device does not even know if the specified slave device exists. All these communication controls must be implemented outside the SPI protocol. For example, to connect a command-response control decoder chip using SPI, a higher-level communication protocol must be implemented on top of SPI. SPI does not care about the electrical characteristics of the physical interface, such as signal standard voltages. Initially, most SPI applications used intermittent clock pulses and transmitted data in bytes, but many variants now implement continuous clock pulses and arbitrary-length data frames.

I2C

Unlike the single-master nature of SPI, I²C is a multi-master bus. I²C does not have physical chip select signal lines or arbitration logic circuits, using only two signal lines—’serial data’ (SDA) and ‘serial clock’ (SCL). The I²C protocol specifies:

• First, each IIC device has a unique seven-bit device address;
• Second, the data frame size is 8-bit bytes;
• Third, certain bits in the data (frame) are used to control the start, stop, direction (read/write), and acknowledgment mechanisms of the communication. I²C data transmission rates include standard mode (100 kbps), fast mode (400 kbps), and high-speed mode (3.4 Mbps), with some variants implementing low-speed mode (10 kbps) and fast+ mode (1 Mbps). Physically, the I²C bus consists of two signal lines and one ground line. Both signal lines are bi-directional, as shown in the figure. The I²C protocol standard specifies that the device initiating communication is called the master device, and all other devices are slave devices.

The I²C communication process is roughly as follows. First, the master device sends a START signal, which is like shouting to all other devices: pay attention! Then the other devices start listening to the bus in preparation to receive data. Next, the master device sends a data frame consisting of a 7-bit device address plus one bit indicating read/write operation. When the target device receives the data, it compares the address to see if it matches. If it does not match, the device enters a waiting state until the STOP signal arrives; if it matches, the device sends an acknowledgment signal—ACKNOWLEDGE in response.

Once the master device receives the acknowledgment, it begins to send or receive data. The data frame size is 8 bits, followed by an acknowledgment signal. The master device sends data, and the slave device acknowledges; conversely, when the master device receives data, it acknowledges. When data transfer is complete, the master device sends a STOP signal to declare the bus is released, and the other devices return to their initial states.

Based on the physical structure of the I²C bus, the START and STOP signals on the bus must be unique. Additionally, the I²C bus standard stipulates that data transitions on the SDA line must occur during the low period of the SCL line, while the data on the SDA line is stable during the high period of the SCL line.

In physical implementation, both the SCL and SDA lines are open-drain, with pull-up resistors and an external voltage source. When the line is grounded, it represents logic 0; when the line is released and idle, it represents logic 1. Based on these characteristics, IIC devices can only perform the operation of “pulling the line to ground”—outputting logic 0.

The I²C bus design uses only two lines but elegantly achieves seamless communication among any number of devices, which is quite remarkable. Let’s imagine what would happen if two devices simultaneously send information to the SCL and SDA lines.

Based on the design of the I²C bus, there can be no level conflict on the line. If one device sends logic 0 while others send logic 1, the line will only see logic 0. In other words, if there is a level conflict, the device sending logic 0 will always be the “winner”.

The physical structure of the bus also allows the master device to write data to the bus while reading data. This way, any device can detect the occurrence of a conflict. When two master devices compete for the bus, the “winner” does not know about the competition; only the “loser” discovers the conflict—when it writes a logic 1 but reads 0—and withdraws from the competition.

10-Bit Device Address

Any IIC device has a 7-bit address, theoretically allowing only 127 different IIC devices. In reality, there are far more types of IIC devices than this limitation, making it quite probable for IIC devices with the same address to appear on the same bus. To overcome this limitation, many devices use a dual address—7-bit address plus pin address (external configuration pins). The I²C standard anticipated this limitation and proposed a 10-bit addressing scheme. The 10-bit addressing scheme impacts the I²C protocol in two ways:

• First, the address frame is two bytes long, compared to one byte previously;
• Second, the first byte’s five most significant bits are used as a 10-bit address identifier, agreed to be “11110”.

In addition to the 10-bit address identifier, the standard also reserves some address codes for other purposes, as shown in the table:

Clock Stretching

In I²C communication, the master device determines the clock speed because the clock pulse signal is explicitly generated by the master device. However, when a slave device cannot keep up with the master device’s speed, it needs a mechanism to request the master device to slow down. This mechanism is called clock stretching, which is made possible by the special structure of I²C. When a slave device needs to lower the transmission speed, it can pull down the clock line, forcing the master device into a wait state until the slave device releases the clock line, at which point communication continues.

High-Speed Mode

In principle, using pull-up resistors to set logic 1 limits the maximum transmission speed of the bus. Speed is one of the factors that limit bus applications. This explains why high-speed mode (3.4 Mbps) was introduced. Before initiating a high-speed mode transmission, the master device must first send a specific “High Speed Master” signal in a lower-speed mode (such as fast mode). To shorten signal cycles and increase bus speed, high-speed mode must use additional I/O buffers. Additionally, bus arbitration can be masked in high-speed mode. For more information, please refer to the bus standard document.

I²C vs SPI: Who Is the Winner?

Let’s compare some key points of I²C and SPI:

First, Bus Topology/Signal Routing/Hardware Resource Consumption

I²C requires only two signal lines, while standard SPI requires at least four signal lines, and more if there are multiple slave devices. Some SPI variants use only three lines—SCLK, SS, and bidirectional MISO/MOSI—but the SS line still needs to connect one-to-one with slave devices. Moreover, if SPI wants to implement a multi-master structure, the bus system requires additional logic and wiring. The only issue with building a system bus using I²C is the limited 7-bit address space, but this problem has been resolved by the new standard—using 10-bit addresses. From this perspective, I²C is clearly the big winner.

Second, Data Throughput/Transmission Speed

If high-speed data transmission is required in an application, then SPI is the obvious choice. This is because SPI is full-duplex, while I²C is not. SPI does not define a speed limit; typical implementations can achieve or exceed 10 Mbps. The highest speed of I²C is only fast+ mode (1 Mbps) and high-speed mode (3.4 Mbps), with the latter requiring additional I/O buffers, which are not always easy to implement.

Third, Elegance

I²C is often considered more elegant than SPI. Fairly speaking, we tend to believe that both are equally elegant and robust. The elegance of I²C lies in its features—achieving multi-master arbitration and device routing with a lightweight architecture. However, for engineers using it, understanding the bus structure is more challenging, and the bus performance is not high.

The advantage of SPI is that its structure is quite intuitive and simple, making it easy to implement and offering good scalability. The simplicity of SPI does not necessarily make it elegant, as building a useful communication platform with SPI requires developing specific communication protocol software on top of SPI. In other words, to achieve the high-speed performance that is unique to SPI but not available in IIC, engineers need to put in more effort. Additionally, this custom work is completely freeform, which also explains why SPI lacks an official standard. Both I²C and SPI provide good support for low-speed device communication, but SPI is more suitable for data streaming applications, while I²C is better suited for multi-master applications involving “byte devices”.

Conclusion

In the cluster of digital communication protocols, I²C and SPI are often referred to as “small” protocols, relative to Ethernet, USB, SATA, PCI-Express, and other buses with transmission speeds reaching hundreds or thousands of gigabytes per second. However, we must not forget what the purpose of various buses is. “Large” protocols are used for communication between entire systems outside the system, while “small” protocols are used for communication between chips within the system. There is no indication that “large” protocols need to replace “small” protocols. The existence and popularity of I²C and SPI reflect the philosophy of “good enough is sufficient.” Responding to the beginning of this article, the popularity of I²C and SPI makes them essential tools for any embedded engineer.