I have a design using an SPI slave (PSoC 3/5) with the following parameters:
The application requires that, while SCLK is in its idle state, MISO be a steady high to indicate that the device is ready for a data transfer. Immediately after the last SCLK, the MISO must go low to indicate that the device is not yet ready for another transfer. Once the device is ready, the MISO will go high. I can add logic to the SPIS to force these conditions, but before I do that, I think I should better understand the SPI slave.
I will only transfer 4 bytes at a time. And, since the clock is much faster than SCLK, I consider a delay of a few clock cycles to be essentially instantaneous. I don't want to use the SS input, but if I have to, I'll use internal signals to "fake it out". That being said, I want to determine/control the MISO state before and after the transfer.
Assume that the FIFO is full and I have written directly to the shift register using SPIS_WriteTxData() before the first leading (falling) SCLK edge. What is the MISO state? Is it equal to the MSb of the first byte, already in the shift register?
Also, what would the MISO state be after the trailing (rising) edge of SCLK? Would it be the LSb of the final byte, the MSb of the next byte from the FIFO, or something else?
Any help would be appreciated.
We can't say surely whether it will be MSB or LSB,it depends on the clock and at the instant at which SPIS_WriteTxData() API was called ,at that particular instant which byte was getting transferred
Oops. I really goofed when I worded the 2nd question. What I meant to ask was: What is the MISO state after the trailing (rising) edge of the final SCLK of the 4th byte (note that one byte would still be left in the FIFO)? If the MISO is equal to the LSb of the 4th byte at this time, would it be equal to the MSb of the next (5th) byte within a couple of sample clock cycles?
Assuming that it is a 4 byte hardware FIFO (let us number the byte positions as 0,1,2,3) - the 5th byte will not be written to the FIFO unless and until the buffer has at-least one byte space. The API SPIS_WriteTxData internally checks if the buffer is free to write the new data. As in SPI, slave transmits the data only when master provides the clock, master should at-least provide 8 clock cycles so that a new byte (5th byte) can be added to the FIFO. If you want more bytes, then you have to enable the Software buffer.
Now, assume that before CPU fills the 5th byte to the buffer (at offset 0), at-least one byte has been shifted out of the FIFO. And assume now you are transferring the 4th byte (offset 3) and assume SPI is configured to transfer MSB first. In that case, MSB of the 5th byte will be shifted out in the next clock cycle (after LSB of the 4th byte has been shifted out). Once entire bits are shifted out, the last bit status will be retained on the MISO line.
I did some experimentation. Here's what happened:
I wrote the first byte (0x80) directly to to the transfer register (the SS line was already low). The MISO line immediately (or within a sample clock cycle or two) went HIGH. This is one of the things I wanted, since the protocol I'm trying to mimic requires that this line be high when the data clock is idle, to let the master know that the slave is ready for a new measurement.
I then wrote bytes 2, 3, 4, & 5 to the FIFO (no software buffer). Byte 4 was 0xFF -- byte 5 was 0. Thus, five bytes were loaded and ready to send (although only the first 4 would actually be sent).
In software, I generated 32 clock pulses and captured the output with a logic analyzer. At the end of the last data clock pulse (or within a sample clock or two), the MISO was LOW, indicating that the next (and last) byte in the FIFO had been moved to the transfer register. This is also what I wanted, since the protocol requires that the slave keep its output low until it is ready for another measurement.
To answer my own question, after the final data clock, the MISO was equal to the MSb of the 5th (unsent) byte.
I should point out that I was using a CPHA=0 mode and the SPIS sample clock frequency was much higher (4 - 10x) than that of the data clock.