Does a SPI master always receive data at the same time it sends data?

Question

I'm trying to communicate with the EEPROM using SPI and the image below illustrates the read status register sequence.

The program I'm using checks the receive data register each time SPI finishes sending (send data register empty).

My question is, does the SPI master receives data on MISO when it sends the instruction data as shown in the image below? and in general, does SPI always receive data on MISO at the same time it sends data on MOSI?

If that is the case, to get the status register's out-data, should I send other NULL data (0x00)??

Answer 1

The general concept of SPI is that it can send and receive bits at each clock time. That said every SPI device will work differently with regard to what bits are used in each path. It is up to you to read the DATASHEET for your device to figure out what bits required are on the MOSI side to get the device to do what you want and provide back what you need on the MISO side.

Answer 2

SPI is a full duplex bus. That means that communication in both ways happen simultaneously.

In hardware it may be implemented by 2 shift registers that are clocked by the SPI clock. The transmit register will clock data out, and the receive register will clock data in. Most microcontrollers will access the transmit register on write, and receive register on read.

Both shift registers are clocked with the same clock. So if you want to clock data into the receive register, you need to send a 00h byte. This is often considered "safe" to send.

In the code bases I have worked on, we have typically implemented SpiTxRx routines. It takes a byte to transmit, and also returns the byte read. In my opinion this is good practice, because if you don't read the SPI receive buffer (e.g. you think can optimize by writing a faster SpiTx routine) at all the hardware may flag a buffer overrun and lock up the SPI peripheral in an error state.

Answer 3

SPI data transfer in either direction means the master sends a clock and whoever wants to say something (including the master itself) puts it onto the data line with the clock cycles.

In principle, the master could just generate the clock without sending data out, but this is the same as sending a 0x00.

Answer 4

SPI decribes only how bits are sent/received, and doesn't prescribe any other aspects of communication except that practically, the master device is in control of when communication happens - a slave can't initiate. Beyond this, the choice of who is writing and who is reading at any given time is implementation-dependent.

In practice most simple devices will not send and receive data simultaneously, because it is simpler and more common to implement communication in the form of commands and responses - the master sends some command, and the slave responds either by replying with data or by readying it to receive some data, and these happen one after the other.

That said, the SPI devices at each end are always writing bits (even if zero) and always receiving bits (even if discarded) upon every clock signal, whether the implementations are actually using these or not.

If you want to take advantage of the full duplex nature of SPI by writing a protocol that will transmit and receive simultaneously, SPI lets you do this.

At the level of your SPI library/abstraction, your library will either provide separate methods for reading, writing, and perhaps doing both at once, or it will simply provide a method for writing and reading at the same time and it's up to you to discard or zero out the parts that are not meaningful in the protocol. Doing a read/write where you send zero is functionally the same as doing only a read, and doing a read/write where you discard what you read, is functionally the same as doing only a write.

Answer 5

Some SPI libraries include only one routine, which sends and receives a byte simultaneously. Others have a separate routine to send a byte and ignore the result. Including the latter function in a library may allow performance to be improved significantly (sometimes almost doubled) on some platforms since the transmit-and-ignore-result routine can return as soon as the hardware starts transmitting the byte in question, even though it wouldn't be able to return data until the action finishes. To allow high speed reception, some libraries may offer a "get a byte and start receiving another" function.

I haven't noticed much consistency in how the higher-performance libraries operate, and avoiding data corruption while overlapping operations can be tricky, but the performance improvements that can be obtained by overlapping I/O and computations can be very significant and worth the effort.