Struggles and suggestions with master/slave terminology - Embedded.com

Struggles and suggestions with master/slave terminology

Advertisement

Removing the use of Master/Slave terminology across the industry is doable, but I suspect it will take a long time and generate a lot of heated debate.

Over the last few years, the pressure to remove terminology like master and slave from engineering has intensified. Within the culture here in the U.S., the language evokes imagery of racism and repression at the least; and can be offensive to some. On the other hand, there have been calls to update standards to provide less harsh terms, such as Leonard Ellis’ “It’s Time for IEEE to Retire ‘Master / Slave”. As a consultant, I’ve had the opportunity to argue both sides, playing devil’s advocate to ensure that changing the terminology or not changing it is properly justified. This post will share some simple observations and recommendations for removing master/slave terminology without introducing confusion, bugs, and other issues.

The standard terminology switcharoo

I recently worked on a project with a talented, early career engineer. I received some schematics with what appeared to be standard terminology net names for the SPI bus:

  • SDO – Slave Data Out
  • SDI – Slave Data In
  • CLK – Clock
  • CS – Chip select

With 20 years of experience, I’ve seen these acronyms before. I jumped into my microcontroller peripheral configurator, mapped the pins, generated code, and moved on to the next activity. When it came time to interface the device to the microcontroller, I wrote some test code to communicate with it. I could not get the device to respond. I scoped the connection lines and tried everything I could. The device was silent.

When a developer does everything they can, and it still doesn’t work, our go-to response is to blame the hardware. So, I set up a call to review the hardware with the electrical engineer to ensure that neither of us had missed anything. Unfortunately, I discovered that the engineer, bless his heart, had changed the standard definitions to avoid offending anyone! The actual definitions were:

  • SDO – Serial Data Out
  • SDI – Serial Data In
  • CLK – Clock
  • CS – Chip Select

How to handle changing terminology that is not in the “standard”

Now there were several problems with renaming the SPI lines that came up here that I think we can all learn a few lessons from. First, if you remove master/slave terminology and use terminology, not in the official standard, you can’t use acronyms with other meanings within the engineering industry. As we just saw, it creates confusion and, in this case, resulted in a few hours of unproductive debugging. Make sure that any acronym or naming convention you use is unique or different enough for an engineer to ask, “what does that mean?” so that they go and look up what you mean.

Second, if you change your terminology, document it everywhere. Put little notes wherever those data lines start and end. The key is to avoid confusion. Most developers I know don’t mind changing the terminology if it avoids confusion, which I find far too often.

Finally, ensure the employees, managers, subcontractors, and partners understand the desired terminology. You might be rolling your eyes that this sounds like a lot of work; However, it can be simplified by adding a dictionary of terms during your company’s onboarding process. If you partner with someone, share the dictionary. Hire a new employee and share the dictionary. I’m not suggesting that you write a book, keep it to a page or two of company terminology.

A few ideas for terminology adoption

Another area where I have seen companies struggle is to identify the correct terminology to use. If you look on Wikipedia, they’ve collated a great list of replacement terms. Some are pretty entertaining. For example, I like the idea of using the term minion for devices, but I don’t think it fits from a technical perspective.

When we look at SPI and I2C buses, I think the terms that make the most sense are host and device. There are a few reasons why I believe this. First, the host and device are already commonly used in USB standards. We know the terms and understand the relationship between the host and the device. Second, if a design has multiple microcontrollers, one can be a host and the other a device. Using terms like controller / peripheral or controller/target can be confusing when there are two or more microcontrollers!

With the use of host/device, SPI lines could be represented by:

  • DDA – Device Data Out
  • DDI – Device Data In
  • CLK – Clock
  • CS / DS – Chip Select / Device Select

Other terminology could be replaced like:

  • Master Out / Slave In (MOSI) with Host Out / Device In (HODI)
  • Master In / Slave Out (MISO) with Host In / Data Out (HIDO)

Besides removing terminology that might be offensive, the acronyms are easily remembered and even create a fun little tune if hummed (DI-DA HIDO).

Conclusions

Removing the use of Master/Slave terminology within a company is doable and within short order. Care must be taken, though, to select the new wording and to ensure that it is clear and understood by everyone. Where confusion or overlap with existing terms exist, bugs and wasted development time will result.

Removing the use of Master/Slave terminology within the industry is doable, but I suspect it will take a long time. Standards will need to be updated and accepted. Undoubtedly, a lot of heated debates will ensue. Eventually, all those datasheets for all those devices we use will need to be updated. But, again, it’ll take time, money, and resources.

What is the right answer, or the right terms? That is a question I leave for you.


Jacob Beningo is an embedded software consultant who specializes in real-time, microcontroller-based systems. He actively promotes software best practices through numerous articles, blogs, and webinars on topics from software architecture design, embedded DevOps, and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees including a Masters of Engineering from the University of Michigan.

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.