SPI, shoelaces and the future of wireless sensor design

February 16, 2012

Bernard Cole-February 16, 2012

In his most recent column, “A SPIFI new idea,” Jack Gannsle expresses his pleasure in the capabilities of a new flash memory interface from NXP, which uses a Serial Peripheral Interface to access serially organized flash nonvolatile memory devices over what it refers to as the SPI Flash Interface. Gannsle feels the new interface gives developers of resource-constrained MCU designs capabilities they did not have before. To see what the fuss is all about read:

Eliminate parallel/serial tradeoffs with SPIFI-equipped Cortex-M3
Program SPI flash in-circuit via JTAG
Program SPI serial flash from Xilinx FPGAs and CPLDs

The SPI Flash Interface is yet another application of the Serial Peripheral Interface protocol, which has been around almost as long as I have been covering electronics.SPI is a name Motorola gave to a circuit technique used in the late 1970s in its first 68000-based MCU to connect it to peripheral functions.

But I am sure that it pre-existed in many designs before Motorola’s implementation. I remember a comment to me at the time by an engineer who was familiar with both it and similar devices from National Semiconductor: He said SPI is the sort of defacto standard that did not emerge out of the brain of any one engineer or company, but was something any digital electronic engineer would think of to communicate between two digital devices on a board with a minimum number of wires.

When I first saw an implementation of SPI in a design being done by an engineer I immediately thought of the process involved in tying shoelaces. As children, introduced to shoes and the need to keep from stepping on the untied laces, we are either taught, or figure out with a little experimentation, how to tie them. The basic steps are the same and depending on circumstances there are a number of variations which build upon the basic knot, such as the Alpine butterfly, Figure-of-eight and the Monkey's Fist. After that,  when the situation arises, such as the need to make your shoes fit snugly, the process is automatic.  

It is much the same with the basic SPI. It is is not complicated and is simple to implement and, as a result, is as automatic tying your shoelaces. It is nothing more than a signal line protocol that defines simple communication between two digital devices. It includes the following: 1) a clock signal sent from the bus master to all slaves; 2) synchronization of all signals to this basic clock output; 3) A slave select signal for each slave to select the slave with which the master communicates; 4) a data line from the master to the slaves; and 5) data lines from the slaves to the master.  

Unlike later specs, including I2C, USB, and PCI, it is hard to find a formal separate ‘specification’ of the SPI bus. As a result, nearly every IC vendor out there has come up with improvements which they use to establish their imprimatur through branding or patenting. The last comprehensive summary of   SPI parts I have seen, both basic and enhanced with proprietary "improvements," listed about 200. Also unlike those later specs, there is no Special Interest Group or IEEE committee that maintains a formal separate ‘specification’ for the SPI bus.

Indeed embedded developers used to designing within the constrainsts of those specifications would be, I suspect, very uncomfortable with SPI.  Other than what is summarized above, that is basically all that is defined for the SPI protocol. It doesn't define any maximum data rate, nor a particular addressing scheme. It also doesn't have an acknowledgment mechanism for confirming receipt of data. Scandolously, it also does not offer any flow control.

As near as I have been able to determine, the SPI master really has no information about whether a slave exists, unless it is so defined outside the SPI protocol. It  also has no concern about the physical interface specs such as I/O voltages, or even clocking. The earliest designs I was aware of used a non-continuous clock and byte-by-byte scheme. But many present variants of the protocol use a continuous clock signal and arbitrary transfer lengths. The closest to any specific description for SPI is what has appeared in publications such as ESD Magazine and on Embedded.com. (See “Serial protocols compared,” by John Patrick and “Introduction to Serial Peripheral Interface,” by David and Roee Kalinsky.)

Despite all these "drawbacks," SPI is now ubiquitous in embedded designs, an integral element in microcontrollers and FPGAs, and in applications such as instrument panel clusters, digitally controlled potentiometers, M2M applications, industrial controller area networks (CAN), temperature measurement and robotics. Several recent articles in UBM’s EDN Magazine attest to its continued usefulness:

Two wires control an SPI high-speed ADC.
C# application controls simple ADC
Emulate SPI signals with a digital I/O card

Whether its' ubiquity is due to the fact that that it has no formalized standards group protecting it - or in spite of it - I do not know. But in research I have been doing recently about leading edge wireless machine to machine and 6LoWPAN applications, the sheer number of articles I have come across making use of it was surprising. A few of the more interesting articles I found include:

A low power wireless  medical sensor platform (PDF)
A compact modular wireless sensor platform (PDF)
A wireless image sensor application platform (PDF)
Wireless sensor networks for personal health monitoring (PDF)
Application development in vision-enabled wireless sensor nets (PDF)

This convinces me that we can expect  to see SPI even more widely used - not less -  in embedded applications as we move into an era of ubiquitous MCU-based, wirelessly connected sensors, due to its ability to operate effectively in resource-constrained environments - and to the freedom its' somewhat ad hoc flexible nature provides to developers.

Embedded.com Site Editor Bernard Cole is also a partner in TechRite Associates editorial services consultancy. He welcomes your feedback. Call 928-525-9087 begin_of_the_skype_highlighting            928-525-9087      end_of_the_skype_highlighting or send an email to bccole@techrite-associates.com or bernard.c.cole@gmail.com.

This article provided courtesy of Embedded.com and Embedded Systems Design Magazine. Sign up for subscriptions and newsletters. Copyright © 2011 UBM--All rights reserved.

Loading comments...

Most Commented

Parts Search Datasheets.com

KNOWLEDGE CENTER