Updating the Language of SPI Pin Labels to Remove Casual References to Slavery

-

This morning the Open Source Hardware Association (OSHWA) announced a resolution for changing the way SPI (Serial Peripheral Interface) pins are labelled on hardware and in datasheets. The protocol originally included MOSI/MISO references that stand for “Master Out, Slave In” and “Master In, Slave Out”. Some companies and individuals have stopped using these terms over the years, but an effort is being taken up to affect widespread change, lead by Nathan Seidle of Sparkfun.

The new language for SPI pin labeling recommends the use of SDO/SDI (Serial Data Out/In) for single-role hardware, and COPI/CIPO for “Controller Out, Peripheral In” and “Controller In, Peripheral Out” for devices that can be either the controller or the peripheral. The change also updates the “SS” (Slave Select) pin to use “CS” (Chip Select).

SPI is widely used in embedded system design and appears in a huge range of devices, with the pin labels published numerous times in everything from datasheets and application notes to written and video tutorials posted online. Changing the labels removes unnecessary references to slavery without affecting the technology itself. This move makes embedded engineering more inclusive, an ideal that’s easy to get behind.

The Technology Itself

Even though the terminology needs an update, the approach to how SPI data lines are designated is one of the best of all protocols because the *O*I/*I*O format stays the same even when the device changes. This is easiest to understand when thinking about a microcontroller that can act as either the “Controller” or “Peripheral”. A controller will always send out its data on the COPI line (controller out) and receive data back on the CIPO (controller in). Now, the same device acting in the peripheral role retains the exact same pin labels. It just begins listening on the COPI line (peripheral in) and sending on the CIPO line (peripheral out). Under this naming scheme, the controller is always the device that controls the clock.

The SDI/SDO labels have most commonly appeared on devices that lack the ability to serve as an SPI controller (think sensors or LCD screens). But here’s the problem, when you have three or more chips in a design, which SDI lines get connected to SDO lines? Even with two chips, if one port is called SDI and the other is called SDO, what name do you assign to the wire? It’s the UART RX/TX problem all over again.

Retaining the COPI/CIPO paradigm, the problem is answered without any knowledge at all of function: all COPI lines should be connected to one another, as should all CIPO lines. Brilliant.

We Can All Decide to Make This Change

SPI is a de facto standard which Motorola published starting back in the 1980s. It’s simple and it works well, becoming one of the two most widely used chip to chip communication protocols along with I2C. But it’s not governed by a ruling body. That means, to change the pin names, all it takes is for people to decide we should change them. That’s what’s happening here.

With hardware manufacturers like Sparkfun and Adafruit, and the Open Source Hardware Association adopting the SDO/SDI and COPI/CIPO labels, the effort gets a jump start. I encourage you to make the changes in your own schematics, software, and documentation.

The hardware world isn’t the only place removing references to slavery from design specs. The OpenZFS project changed references to “slave” in the code base to “dependent” which was also abbreviated as “dep” for variable names. An article in Ars Technica published on the OpenZFS change also references a paper published by the Internet Engineering Task Force (IETF) standards organization recommending a shift away from oppressive language being included in defined standards.

The history of slavery is a dark and disturbing one, and its casual inclusion in engineering can be hurtful. In this time of introspection sparked by massive protests over racial inequality, systemic racism, and violence within law enforcement, this is one small but meaningful change the hardware world should choose to adopt. And one that I wish had been adopted long ago.



from Blog – Hackaday https://ift.tt/38dgtJZ

Comments

Post a Comment

Popular posts from this blog

Modern Radio Receiver Architecture: From Regenerative to Direct Conversion

-
Image
Modern radio receivers have a distinct advantage over the common early designs which I covered in my previous article . Most of the receivers you will have worked with over the past couple decades are designs by Edwin Armstrong ; regenerative, superregenerative, or most commonly superheterodyne. These are distinguished by a few fascinating key traits that bring both benefits and drawbacks. Today let’s dive into Mr. Armstrong’s receivers. I’ll also talk about DC receivers which, despite the name, are not made to listen to batteries. These are receivers you are much more likely to encounter in modern equipment. Regenerative and Superregenerative The regenerative receiver is all about doing more with less. You still see some of these in simple applications like RF remote controls. The idea derives from how an oscillator works. In a simple way of thinking, an oscillator is an amplifier with enough positive feedback that any tiny signal at the right frequency will amplify and then, throu
Get this one»

Hackaday Links: May 31, 2020

-
We begin with sad news indeed as we mark the passing of Marcel van Kervinck on Monday. The name might not ring a bell, but his project, the Gigatron TTL computer , certainly will. We did a deep dive on the microprocessor-less computer a while back, and Marcel was a regular at conferences and on the Gigatron forums, supporting users and extending what the computer can do. He was pretty candid about his health issues, and I’ll add that when I approached him a few weeks ago out of the blue about perhaps doing a Hack Chat about Gigatron, he was brutally honest about how little time he had left and that he wouldn’t make it that long. I was blown away by the grace and courage he displayed. His co-conspirator Walter Belger will carry on the Gigatron mission, including joining us for a Hack Chat on June 24. In the meantime, this might be a great time to pick up a Gigatron kit before they’re all sold out and get busy soldering all those delicious through-hole TTL chips. May of 2020 is the mo
Get this one»

Homebrew 68K Micro-ATX Computer Runs Its Own OS

-
Image
We’re no stranger to home built Motorola 68000 computers here at Hackaday, but more often than not, they tend to be an experiment in retro minimalism. The venerable processor is usually joined by only a handful of components, and there’s an excellent chance they’ll have taken up residence on a piece of perfboard. Then [NotArtyom] sent in his Blitz , and launched the bar into the stratosphere. Make no mistake, the Blitz isn’t just some simple demo of classic chips. The open hardware motherboard has onboard floppy, IDE, and PS/2 interfaces, with a trio of 8-bit ISA expansion slots for good measure. The  Motorola 68030 CPU is humming along at 50 MHz, with 4 MB of RAM and 512 KB of ROM along for the ride. Designed to fit the Micro-ATX motherboard standard, you can even mount the Blitz in a contemporary PC case and run it on a standard ATX power supply. An earlier prototype of the Blitz motherboard. As if the hardware wasn’t impressive enough, [NotArtyom] went ahead and created his ow
Get this one»