原创 SPI, shoelaces and the outlook for wireless sensor design

In his  recent blog "Something SPIFI", Jack Gannsle talks about his pleasure in the capabilities of a new flash memory interface from NXP, which uses a Serial Peripheral Interface to access serially organised 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.

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) synchronisation 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 summarised 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.

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.

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.

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.