I2C and SPI: The Two Buses That Connected the Embedded World
I2C and SPI became the board-level lingua francas connecting microcontrollers to sensors, memories, displays and other peripheral chips.
Embedded systems needed a simpler way to connect many small chips
A typical embedded product contains a controller plus memories, clocks, converters, sensors, displays and other peripheral devices. If every device requires a wide parallel bus and dedicated control signals, pin counts and circuit-board wiring grow quickly. Philips Semiconductors created I2C to reduce this burden in consumer electronics, while Motorola’s SPI became a fast synchronous interface associated with its microcontroller families. The two buses solved similar board-level problems with different tradeoffs and became enduring conventions across the embedded industry.[1][2]
Board-level communication is an architectural problem
The interface chosen between chips determines pin count, speed, addressing, software complexity and how easily a product can add new peripherals.
I2C reduced inter-chip control to two shared wires
NXP’s current I2C specification traces the first release to 1982 and explains the original goal: a simple bidirectional two-wire bus for efficient inter-IC control.[1] Serial data travels on SDA and a shared clock on SCL. Devices are addressed in software, so multiple peripherals can share the same two signal lines. Pull-up resistors and open-drain signaling allow participants to share the wires safely, while acknowledgement and arbitration are part of the protocol. The result is economical wiring and a relatively rich bus discipline.
I2C was designed for many devices and more than one controller
The specification describes unique addresses, controller/target relationships and multi-controller arbitration.[1] This makes I2C useful when several intelligent devices may need bus access or when a board must expose many low-bandwidth peripherals without dedicating one select line to each. The bus also supports several speed grades, from the original 100 kbit/s Standard-mode through faster revisions. Its protocol overhead buys flexibility: addressing, acknowledgement and arbitration are built into the shared medium.
I2C made the PCB behave like a small network
Peripherals could be added or removed while preserving the same physical pair of signal lines, provided their addresses and electrical loading remained compatible.
SPI chose fewer protocol rules in exchange for more wires and higher throughput
SPI is a synchronous serial interface historically associated with Motorola and later documented throughout the 68HC11 family. Motorola/Freescale documentation describes the familiar clock, data-in, data-out and select signals together with programmable clock polarity and phase.[2] Unlike I2C, classic SPI does not define a shared device-addressing scheme. A host normally selects a target with a dedicated chip-select signal. This can increase wiring, but it eliminates address cycles and makes the electrical transaction straightforward.
Full-duplex shifting made SPI natural for memories, converters and displays
SPI commonly uses separate transmit and receive data paths, allowing bits to move in both directions during the same clock pulses. Microchip describes the bus as a short-distance, high-speed synchronous interface typically using three or four wires and full-duplex communication.[3] This makes SPI attractive for flash memories, displays, ADCs and other devices where throughput matters more than minimizing every signal. The protocol is simple enough that controllers frequently implement it directly in hardware.
Simplicity moved responsibility into device-specific conventions
SPI defines the electrical transfer pattern, but the meaning of commands, addresses and transaction lengths usually comes from each peripheral’s data sheet.
The two buses created different extension patterns for embedded boards
I2C scales the number of targets through addresses on a shared pair of wires. SPI often scales by adding chip-select signals, sometimes with decoders or daisy chains. The tradeoff is visible in modern MCU documentation: vendors routinely provide both interfaces because neither dominates every use case.[4] A low-rate temperature sensor may fit naturally on I2C, while a fast display or external flash chip may favor SPI. Designers choose according to bandwidth, latency, pins, topology and software needs.
Standard peripheral blocks spread the buses far beyond their original vendors
The most important historical transition was from proprietary feature to de facto ecosystem interface. NXP notes that I2C became implemented in more than a thousand different ICs and influenced related standards such as SMBus and PMBus.[1] SPI likewise spread across microcontroller vendors and peripheral makers; NXP documentation explicitly supports Motorola SPI framing in later devices, demonstrating how the interface outlived the company and chip family that first popularized it.[5]
Peripheral ecosystems reinforce interface longevity
Once thousands of sensors, memories and controllers expose the same bus, the installed catalog becomes a reason for new chips to support it too.
Why I2C and SPI belong in the history of embedded computing
I2C and SPI matter because they made modular embedded design routine. They created small, dependable boundaries between processors and the physical world. A microcontroller vendor did not need to manufacture every sensor, and a sensor vendor did not need to design for one CPU. Shared buses let components from different companies meet at a familiar electrical and software contract.[1][3]
The two standards also demonstrate that interoperability does not require one universal solution. I2C optimized shared addressing and low pin count; SPI optimized simple synchronous transfers and speed. Their coexistence became a strength. Modern embedded boards still use both because the history of interfaces is often a history of complementary compromises rather than winner-take-all replacement.
Works Cited
- 01
- 02
- 03Microchip — Serial Peripheral Interface (SPI) Peripheral microchip.com
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead