With the help of a few good friends, we’ve authored a resolution to rename the SPI signal names.

See full resolution

Autocross Prototype

Source / This image licensed as CC0 – Public Domain

SPI is short for Serial Peripheral Interface. It’s a great protocol and interface mechanism between multiple devices on a bus. It’s used all the time in the electronics world - it’s what makes your displays, SD cards, sensors and programmers work. The problem is that since its inception in the 1980s, the terms Master and Slave have been used to describe the controller and the peripheral (MOSI = Master Output Slave Input, and vice versa). The technology world can do better than this.

New Signal Names:

  •   SDO – Serial Data Out. An output signal on a device where data is sent out to another SPI device.
  •   SDI – Serial Data In. An input signal on a device where data is received from another SPI device.
  •   CS – Chip Select. Activated by the controller to initiate communication with a given peripheral.
  •   PICO (peripheral in / controller out). For devices that can be either a controller or a peripheral; the signal on which the device sends output when acting as the controller, and receives input when acting as the peripheral.
  •   POCI (peripheral out / controller in). For devices that can be either a controller or a peripheral; the signal on which the device receives input when acting as the controller, and sends output when acting as the peripheral.
  •   SDIO – Serial Data In/Out. A bi-directional serial signal.

Deprecated signal names:

  •   MOSI – Master Out Slave In
  •   MISO – Master In Slave Out
  •   SS – Slave Select
  •   MOMI Master Out Master In
  •   SOSI Slave Out Slave In

Signal names unchanged:

  •   SCK – Serial Clock. The clock for the bus generated by the controller.

Is there really anything wrong with the terms Master and Slave?

Yes, and it’s ok that you asked. These are terms that have centuries of history and violence packed into them. No human should be enslaved.

Why don’t we just change what MOSI and MISO stand for?

Old habits die hard, and given the chance people will resort to Master/Slave terminology. We must abandon MOSI/MISO if we want lasting change. Additionally, choosing what MOSI/MISO stands for quickly devolves (is it Main/Second? Or was it Manager/Subscriber?), leaving Master and Slave in its place.

Why didn’t you ask the community what to name the pins?

Because we would end up with Pinny McPinFace. Humor aside, a group of hardware companies and electronic designers debated at length, ran through the alternatives and while I can’t say we all agreed, we ended up with consensus. The idea is that with the help and influence of the large number of electronics communities, we can sway larger companies and change the way SPI is taught and used.

SDO/SDI was deemed the best way to proceed because there are already numerous companies using the SDO/SDI terminology. The main MOSI/MISO culprit now is controller datasheets, so if you know anyone at ARM, TI, Microchip or Honeywell, please elbow them in the ribs, tell them to endorse this thing, and to start changing the way they write documentation for their products.

Why now?

If not now, when? We can do this. We can try to make a very small corner of the universe a little better. I hope you'll also understand and see just how much you can help, too.

ZOMG this is going to be SO MUCH WORK!

Ya, and it’s the right thing to do. Focus on new content, new designs, new schematics. You may not realize it, but many of you are operating at the forefront of the field. What we write, what we design, and what we teach are absorbed by the next generation of engineers. Change how you name a few pins on your schematic. Change how you talk about SPI on your videos. Do I still say Master/Slave by accident sometimes? Yep. But now I’m proud to point out how foolish those names are.

What about I2C Master/Slave? What about hard drives? What about ZYX?

There’s a lot more work to do. SPI is something we can fix. Let’s do our small part and fix SPI now. We’ll work on I2C next.


Authored by Nathan Seidle