Introduction
This is the first of a series of articles about using the Serial Peripheral Interface (SPI) to communicate with devices attached to a Raspberry Pi Pico. In this article we'll look at the electrical signals SPI uses to transfer data. In Part 2, we'll look at programming the Pi Pico to interface to a real-world SPI device, the WIZnet Ethernet HAT.
SPI is widely used as a mechanism to move data between electronic devices - typically between a microcontroller and attached peripherals. In reality, SPI encompasses a family of interfaces - the sort of family that does not communicate! Although the basic principles are similar, any particular SPI implementation may have subtle quirks in both the hardware signalling and in the protocol for exchanging data that have to be accounted for.
SPI may simply connect two devices or it may connect more. However, one device is always in control - typically, this will be the microcontroller. In "old" terminology this was referred to as the master and the other device(s) were slaves: this persists in the naming of some of the signal lines. These days, the controlling device is sometimes called main and the others sub, retaining the initial letters.
Principle of Operation
The principle of operation is very simple as it essentially involves two shift registers as illustrated in the following diagram:
In this example, n=4, the transmitter is the controller and the receiver is the device. The receiver's shift register contains 0000 and the transmitter loads the word 1011 into its shift register. On each clock pulse, this is shifted one bit at a time from the least significant bit of the transmitter's shift register into the most significant bit of the receiver's, the contents of each shift register moving one bit to the right at each clock pulse. After four clock pulses, the receiver has 1011.
It's a serial protocol in that the word is clocked serially onto the data connection between the devices. SPI is normally understood to be a full duplex communication link (though it doesn't have to be) and so it's usual for each device to have both a transmitter and receiver so that messages can be exchanged in both directions at the same time: this means two data lines are required. Note that all the devices and both directions of communication use the same clock.
This means that to receive data, a device inevitably transmits at the same time (as its transmit shift register is being clocked by the same signal as its receive shift register) - and vice versa. In the above example, the device is transmitting 1101 at the same time as it is receiving 1011. Many devices use a command/response protocol and simply ignore the data they receive when they're transmitting, but some may expect to receive specific values or may operate their transmit and receive channels entirely independently.
The signal line that transmits data from the controller to the device is usually known as MOSI (from master-out, slave-in) and that from device to controller as MISO.
Note that there's no electrical means for the devices to request a delay or to signal they're "not ready" - if a device needs a certain time to provide a valid response that has to be known a priori or communicated by other means.
Unlike other peripheral interconnects, SPI has no intrinsic notion of addressing and where multiple devices are connected together, wiring determines how they're selected (see later). Note also that so far we've said nothing about framing - marking either the start and end of each word, or the entire message. In the absence of a regular framing signal, the loss (or addition) of a clock pulse owing to noise would be unrecoverable as there would be no means of clearing the shift registers to a known state. That, too, we'll see later.
SPI is typically used for faster connections, often operating at several MHz, though there are no specifications for timing or the electrical characteristics of the wiring.
Even this apparently simple interconnection leaves a surprising scope for variation. Usually, the most significant bit of the word is the first to be shifted out onto the data line (the opposite of the illustration above), but that's largely a matter of convention. The shared clock only operates when data is being transferred, but its idle state can be either high or low. Furthermore, the data can be sampled on either the leading or trailing edge of the clock pulse. That makes four different possible combinations of signal timings, usually numbered 0-3. In the case of the even numbers, the leading edge of the clock samples the data, for the odd-numbered modes it's the trailing edge. All of these possibilities can be observed in real devices.
There's a further complication in that we need a means to deal with multiple devices connected to the same controller. The simplest way to do this is shown below:
In this case, the devices are simply cascaded: the controller must run its clock for the right amount of time for the data to reach the required device and the devices that receive the data first must have a means of knowing the data is not for them (they may have some private agreement that a certain number of bits represent a device id, for example).
However, there'd probably need to be some means of recovering from framing errors and there's an increasing delay in communication depending on how far the target device is down the chain.
The most usual method of connecting multiple devices is for the devices to have tri-state buffers, enabling them to be connected together in parallel:
In this case, the devices have an active-low "chip select" signal (CS or /CS). In the default state (signal high), the device ignores the clock signal and its output is disconnected. When the signal is active (low) the device receives and transmits data in response to the clock signal. Obviously, only one device should be selected at a time.
The CS signal usually also serves as a framing signal: when it transitions low, it resets the shift-register so the first clock pulse will operate on the first bit of the word.
The exact timing and duration of CS is affected by a number of factors. The most significant is the relative timing of the clock and data signals because it needs to become active before the first clock transition that results in data transfer and remain active until at least a word has been exchanged. If the total message consists of a series of words, then the signal may be held low throughout the exchange to signal the words are part of a sequence or it may be raised between individual words: it's normally the former, but not always.
You can see the signal timings for a single word cycle in the even modes (0 and 2) in the following diagram:
In theory, in these modes, the chip select line going low latches the data the peripheral device is going to send to the controller and so, in the case of multiword transfers, the chip select line should return high for a short period at the end of each word and this is how the Pi Pico SPI hardware operates (see below). Many devices simply count clock pulses and expect the chip select line to remain low throughout the multiword transfer and may fail to operate correctly using the Pico's hardware chip select in these modes.
The situation for the odd modes (1 and 3) is a little different:
The valid data in these modes is supposed to be latched on the leading edge of the first clock pulse of the word and so the chip select line can remain low throughout multiword transfers.
Where multiple devices are present, they're not, of course, guaranteed to use the same combination of signalling parameters. The signals may be generated in software or in hardware (the latter sometimes supporting only a subset of the myriad possible combinations), but it may be necessary to reconfigure the parameters after communicating with one device and before communicating with the next.
Common Variations
National Semiconductor have a similar interconnect called Microwire. It's similar to SPI, but it's a half-duplex protocol (still using separate transmit and receive lines). The controller sends an 8-bit command word after which the device sends a zero bit followed by a message of between 4 and 16 bits.
The Texas Instruments synchronous serial frame format uses an active-high chip select line that pulses high for one clock period before the data word (starting with the most significant bit) is clocked out starting with the next clock period. If several successive words are being sent as part of the same transmission, the chip select line pulses high during the least significant bit of every word but the last.
Pi Pico SPI
It is, of course, possible to "bit bang" the appropriate variant of SPI simply using software to manipulate the GPIO pins. The Pi Pico has dedicated hardware support for two SPI channels in various word-lengths, clock speeds and signalling modes. This can be handy as when coupled with DMA, you can set up the hardware and let it get on with the job while the processor does other things.
You can also use the PIO hardware to generate the required signals which may be helpful if you need more than the two channels or have particular exotic hardware that the SPI hardware can't support; there are helpful examples provided of how to do this.
As mentioned above, in addition to the data and clock signals, the SPI hardware can also generate the chip select signal. In odd-numbered SPI modes, it will hold the signal low during multiword messages, whereas in even-numbered modes, it pulses the line high between each word. Some devices that operate using modes 0 or 2 expect the line to remain low throughout regardless. In these cases, it may be necessary to control the signal in software. You can see the difference in the figure below captured from a live system with a logic analyzer. In mode 3, the chip select line remains low as all the data is transferred, but in mode 0 the clock is interrupted and the chip select signal returns high between each word.
We'll look further at using the SPI hardware in the next article.
Comments
Post a Comment