Open almost any embedded project today -- an ESP32 reading a temperature sensor, an Arduino driving a small display, a data logger writing to an SD card -- and you will find SPI wiring it all together. It is one of the most widely used interfaces in embedded systems and IoT hardware. It is also, officially, not a standard at all.
Where SPI came from
SPI (Serial Peripheral Interface) traces back to Motorola in the mid-1980s, where engineers needed a simple, fast way for a microcontroller to talk to peripheral chips -- shift registers, ADCs, EEPROMs, and later displays and sensors -- without the overhead of a more complex bus. It first became widely known through Motorola's 68HC11 microcontroller family, which built SPI hardware directly into the chip and documented it in application notes and datasheets.
That is the key detail: Motorola documented SPI well enough for engineers to implement it, but never submitted it to a standards body for ratification. There is no SPI specification maintained by an IEEE working group, no formal document with a version number that vendors are required to conform to. Compare that to I2C, which Philips (now NXP) formally specified and continues to publish and update, or USB, which is governed by the USB Implementers Forum. SPI has none of that. It became universal purely because it was simple enough to implement in silicon cheaply, fast enough for most peripheral communication, and useful enough that chipmaker after chipmaker copied the idea into their own parts.
What "no official spec" actually costs you
For most day-to-day embedded work, this is invisible -- until it isn't. Because there was never a governing document, the details that a real specification would pin down were left to each vendor to decide independently, and they did not always decide the same way. Clock polarity and clock phase, commonly called SPI "modes" 0 through 3, describe whether data is sampled on a rising or falling clock edge and whether the clock idles high or low. A sensor that expects mode 0 and a microcontroller driver defaulting to mode 3 will produce garbled or silent output, and the failure looks electrical -- a wiring or noise problem -- long before it looks like a software configuration mismatch.
Chip-select behavior varies just as much. Most SPI peripherals use an active-low select line, but not all, and there is no universal rule for how multiple devices share a bus: separate chip-select lines per device is common, but some parts expect daisy-chaining instead. Word size, bit ordering (MSB-first versus LSB-first), and maximum clock speed are all left to the datasheet of whatever chip you happen to be wiring up. Two chips can both correctly claim to speak "SPI" and still fail to talk to each other until every one of these parameters is matched by hand.
The practical lesson for IoT and embedded engineering
This is a useful case study in how de facto standards behave differently from formal ones. Modbus and I2C were each published as documented specifications that other vendors could implement against with confidence. SPI spread the opposite way -- through sheer adoption, with the actual behavior defined by whatever a given chip's datasheet says, not by a shared rulebook. Both paths can produce a standard that lasts decades, but only one of them requires reading the datasheet every single time.
For engineers building embedded products or IoT devices -- whether it is a university thesis prototype in the Philippines wiring an ESP32 to an off-the-shelf sensor breakout, or a production PCB design integrating a dozen SPI peripherals -- the practical takeaway is simple: never assume "SPI" alone means two parts will interoperate. Check the mode, the idle clock state, the bit order, and the chip-select convention in the datasheet before you power anything on. It is one of the most common sources of "it should just work" debugging sessions in embedded firmware, and it exists precisely because SPI never had an official spec to standardize those details in the first place.
If you are debugging a stubborn SPI interface, choosing between SPI, I2C, or another bus for a new design, or need help getting a PCB and firmware from prototype to production, get in touch -- protocol-level embedded debugging and hardware bring-up is part of the IoT and embedded development work we do at Fluidwire.
Top comments (0)