Is SPI safe to be interrupted?

Question

I'm writing to a microSD card from within my firmware, but it's the lowest priority task, so it can be interrupted by other tasks while it's in the middle of reading/writing.

Now suppose I communicated with this microSD card using a UART. The problem during reads would be that the hardware RX FIFO would overflow, so the maximum delay I can effort would be (FIFO size × bytes/second), and during writes there would be no problem, because the other end would just wait until I send the next character.

How does this work now I'm using SPI? Is the situation the same that for writes it doesn't matter, and for reads it depends on the SPI FIFO size?

Answer 1

The vast majority of SPI devices will be perfectly happy at any data rate below the specified maximum. One could perform part of a transaction, take a break at any point, come back a few years later, and finish it. Provided that there were no glitches on the clock, select, or power lines, the transaction would be completed normally.

There are three main caveats to be aware of:

1. In general, once a transaction has begun on an SPI bus, none of the wires on the bus may be used for any other purpose until that transaction is complete. In general, this means that an interrupt may not use an SPI bus except when it is the only thing that will be using the bus (it may be possible for the interrupt to have exclusive use of the bus at some times, and for the main program to have exclusive use at other times). Some devices include special pins to let them "ignore" the bus in the middle of a transaction, but even with such features I would not recommend trying to have an interrupt suspend an SPI transaction with one device, perform a transaction with some other device, and then let the underlying code resume its transaction with the first. Better to have the interrupt use a separate SPI bus.
2. Some devices may behave oddly if a transaction goes on for too long. Some real-time clock chips, for example, don't double-buffer the time/date registers but instead latch any "time-advance" events that would occur during a transaction and apply them after the transaction is complete. If a transaction takes so long that a second time-advance event arrives, the latter event will be ignored, causing the clock to slip by that amount of time. I really see no excuse for designing a chip in such fashion (even if one didn't want the cost of double-buffering the data, specifying that software was responsible for ensuring its coherence would be cheaper than adding the "update deferral" logic, and would minimize the likelihood of clock disturbance), but such chips exist.
3. There are a few devices which use a clock and data signal, but which use a "pause" to signify framing. The most recent example of this I've encountered was a controller-per-bulb LED light string. I don't particularly like such designs (one could just as well indicate framing using three consecutive rising edges on the data wire without any intervening clock) but again, such devices do exist.

While certain types of communications require the use of particular timings, there is seldom any reason for SPI devices to require them. Nonetheless, one must be mindful of the existence of such devices.

Answer 2

Checking a copy of the specification (which I can't quote for copyright / NDA reasons) the SPI rate is specified starting at 0Hz implying static operation is fine. Under SPI you only get data back while the device is being clocked, so if using a hardware SPI you'll only receive something after data (even if 0 / don't care) has been sent. So in that regard it's different to a UART where you can receive back unsolicited data at any time.