SPI, shoelaces and the future of wireless sensor design - Embedded.com

SPI, shoelaces and the future of wireless sensor design


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 circuittechnique used in the late 1970s in its first 68000-based MCU to connectit to peripheral functions.

But I am sure that it pre-existed in many designsbefore Motorola’s implementation. I remember a comment to me at the timeby an engineer who was familiar with both it and similar devices from NationalSemiconductor: He said SPI is the sort of defacto standard that did not emergeout of the brain of any one engineer or company, but was something any digitalelectronic engineer would think of to communicate between two digital deviceson a board with a minimum number of wires.

When I first saw an implementation of SPI in a design being done by anengineer I immediately thought of the process involved in tying shoelaces.As children, introduced to shoes and the need to keep from stepping onthe 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 circumstancesthere are a number of variations which build upon the basic knot, such asthe Alpine butterfly, Figure-of-eight and the Monkey's Fist. After that,  whenthe situation arises, such as the need to make your shoes fit snugly, theprocess is automatic.  

It is much the same with the basic SPI. It is is not complicated and is simpleto implement and, as a result, is as automatic tying your shoelaces. It isnothing more than a signal line protocol that defines simple communicationbetween two digital devices. It includes the following: 1) a clock signalsent from the bus master to all slaves; 2) synchronization of all signalsto this basic clock output; 3) A slave select signal for each slave to selectthe slave with which the master communicates; 4) a data line from the masterto 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 vendorout there has come up with improvements which they use to establish theirimprimatur 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 isdefined for the SPI protocol. It doesn't define any maximum data rate, nora particular addressing scheme. It also doesn't have an acknowledgment mechanismfor confirming receipt of data. Scandolously, it also does not offer anyflow control.

As near as I have been able to determine, the SPI master really has no informationabout 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/Ovoltages, or even clocking. The earliest designs I was aware of used a non-continuousclock and byte-by-byte scheme. But many present variants of the protocol use a continuous clock signal and arbitrary transfer lengths. Theclosest 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 androbotics . 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 inresearch I have been doing recently about leading edge wireless machine tomachine and 6LoWPAN applications, the sheer number of articles I have comeacross making use of it was surprising. A few of the more interesting articlesI 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 widelyused – not less –  in embedded applications as we move into an eraof ubiquitous MCU-based, wirelessly connected sensors, due to its abilityto operate effectively in resource-constrained environments – and to thefreedom 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.

Leave a Reply

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