4
\$\begingroup\$

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)??

enter image description here

\$\endgroup\$
1
  • 1
    \$\begingroup\$ For the specific case of the timing diagram that you show in your question it looks like to get the status out you simply send the instruction equal to 00000101. The "D" pin thereafter shows that the output data could be 1 or 0 and that as long as the C toggles with the S pin low the status register output will continue to come out each eight clocks. \$\endgroup\$ Commented May 27, 2015 at 13:34

5 Answers 5

6
\$\begingroup\$

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.

\$\endgroup\$
6
  • \$\begingroup\$ in fact im using company function (should not modify). there is one function used : transmit series of data and then set CS high. each time transmit finish (data register empty), we check receive register for data. in this case you think I should transmit some 0x00 after transmitting the instruction in order to get the result in receive register?? \$\endgroup\$ Commented May 27, 2015 at 13:41
  • 1
    \$\begingroup\$ You "company function" may or may not be up to the demands of what your SPI device requires to operate. You have provided far too little information to allow us to get it working for you. As I said before you have to look at the data sheet. If your "company function" can only send one byte (8 clocks) per call and each call entails an S transition from from H to L and then back to H after the 8th clock time they you will NOT be able to use it as is to read out the status as per the timing diagram you provided. \$\endgroup\$ Commented May 27, 2015 at 13:57
  • \$\begingroup\$ after S is low, this function send a set of one byte (8 clocks) {0x44,0x52,0x21,.....}.then the S is driven high. so what I want to say is that, I should send instruction code, and send another 0x00 in order to keep S low {inscode, 0x00} \$\endgroup\$ Commented May 27, 2015 at 14:04
  • \$\begingroup\$ Like I said before - Every SPI device will be somewhat different and there is no set guarantee that someone else's "generic" SPI routine is going to be compatible with every single SPI device. It is common practice to have hosts work in 8-bit chunks but that will fail to work with one SPI device I worked with in the past that has a hard requirement of 25 clocks per transaction. That crazy device also had a change of phase between C (SCK) and Q (MISO) between the initial command out part and the data readback portion of the protocol. I had no choice but to design a customized bitbang for it. \$\endgroup\$ Commented May 27, 2015 at 14:04
  • \$\begingroup\$ if for example the SPI used with a an OS with scheduler, and the scheduler interrupt the process in the middle of a byte transfer (4 clock tops only send), then resume. the slave should not care???? \$\endgroup\$ Commented May 27, 2015 at 20:31
2
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.