07 September 2012

Tutorial 19a: SPI Theory

When we looked at the UART, we imagined a setup where two people agreed that at a specific time and at specific intervals, one would send a message to the other one letter at a time. Doing so required both sender and receiver to have an accurate clock to prevent frame errors, or mis-reading the message by skipping or duplicating one of the letters. Using a similar analogy, we can think of the Serial Peripheral Interface as having the two people write a message to each other on a piece of paper, then exchange messages by handing them to each other at the same time. As a serial communication, it's still done letter by letter, though there are variations of SPI that allow for exchanging multiple bits simultaneously. We'll focus on single-bit-at-a-time transmission, since that is the only mode available in the USI and USCI peripherals.
There are 3 basic steps in SPI:
(1) Write bit 7 to the output.
(2) Shift register to the left.
(3) Write the other device's output to bit 0.

Let's say our two devices have 8-bit registers. At a given signal, each writes their most significant bit (bit 7) to their output. At the next signal, each shifts their register up one place, and sets the least significant bit (bit 0) to whatever value is on the other device's output. After 8 cycles, the 8 bit value that was in device A's register is now in device B, while the value that was in device B is now in A. Both read the new value (and probably do something with it), and then perhaps write a new message in their registers for the next exchange. This exchange of information makes it possible to very quickly send data from one device to another.

The key to getting the process to work properly is to have all the shifting occur at the same time--the two devices need to be synchronized. This timing is accomplished by sharing a clock between the two devices; one of the two generates its own clock and includes it as an output for the other device's use. By convention, we refer to the device that generates the clock signal as the "master", and any devices listening in as "slaves". Such nomenclature may seem a little non-politically correct, but at the same time it's a reasonable description of how SPI works. We cannot necessarily deem one device as a "sender" and the other as a "receiver", for example, because both devices are simultaneously sending and receiving. Referring to both as "transceivers" doesn't really work either, because the sending and receiving are in fact the same process. Rather, the devices are "exchangers". One device serves as a control of the exchange, while the other depends on the controller in order to make the exchange. Note that, contrary to the connotation of the nomenclature, the master does not necessarily have to be the device that issues commands, nor does a slave have to only receive instructions. In fact, one could envision a system where the clock is external to both master and slave, and neither device operates entirely independently of the other, but rather a third device mediates the exchange between the two by providing the clock synchronization. Generally, however, it's simpler to let one of the exchanging devices mediate, and that device become designated as the master.

You can imagine that the technique used for the SPI protocol lends itself to many variations. (Eg. do we pass the data starting from most to least significant bit or vice-versa? How many bits do we pass at a time?) Do we start the exchange on a rising edge or a falling edge of the clock? (The edge choice also leads to whether a quiet line idles high or low, of course.) To make it more confusing, for whatever reason various manufacturers have created different naming schemes for the lines between the two devices. In particular for our purposes, TI has the three lines between the devices named as Serial Data In (SDI), Serial Data Out (SDO), and Serial Clock (SCLK). Like for UART, the data in line of one device is connected to the data out line of the other: SDI_A-SDO_B and SDO_A-SDI_B for devices A and B. Note that because we must include the clock, SPI requires three lines (plus one more for ground) between the devices as opposed to two lines (plus ground) in the basic UART. (There are some situations where if one of the devices doesn't need to communicate anything to the other ever you can get away with just two lines, but in general you need three.)

The other common nomenclature for SPI connections was given by Motorola: each device has a Master Out-Slave In (MOSI), and a Master In-Slave Out (MISO) rather than SDI and SDO.  In this nomenclature, you connect like pins rather than opposite pins: MOSI_A-MOSI_B and MISO_A-MISO_B. Other devices use a similar nomenclature to TI, dropping the "D" in the abbreviations: SI and SO, connecting as in the TI scheme. You may also encounter SPSCK and SCK for the clock, and devices enabled with a chip select can be labeled as CS, SS (slave select), or sometimes CE (chip enable). Be certain to verify whether tying this pin high or low enables the device. In this blog, I'll stick with TI's nomenclature, and use SDI, SDO, SCLK, and CE.

SPI can also extend to communication with multiple devices by including a "Chip Select" pin-- a slave will only listen when this pin is high or low, depending on the implementation. Thus other peripherals can be attached, and instructions/data can be exchanged only between the master and the pertinent slave. The disadvantage to this means of multiple-party communication is that it requires one more line for each device that needs to communicate independently.

So how do we know what conventions we should use in our designs? Unfortunately, you need to get familiar with reading data sheets, and my experience has been it takes some practice to read data sheets describing exact communication protocols. In the next tutorial, we'll look at how to implement SPI using the USI peripheral, and delve more into the details of how to determine the particular protocol being used and configure the MSP430 properly.

1 comment:

kiranvarma_npeducations said...

The way you presented the tutorials/articles about the MSP430 is really in very high standards. Initially myself find a bit difficult, but later on reading it was interesting! Basically i use write in simple way about the MSP430.
Really nice of your tutorials.