What's wrong with SPI slave

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
I wrote:
sparrow2: There is no point in checking other received bytes in the SPI ISR - the issue is, that SPI does not have an Rx double buffer so the span between ISRs is 1 byte long, but the latency has to be less than one bit time.
The SPI does have a read buffer, so you have a full byte time to read it before it is lost.

Yeah I got it wrong (it's more than a year since I worked on that): it does not have a Tx double buffer.

It means, that the slave must not output byte to SPI Tx while the "train is in motion". It must output the byte to be transmitted to the master in the space between two consecutive bytes. In other words, the master, before sending the next byte, it must wait until the slave's SPI ISR fires and gets to the point where it writes to the outbound buffer (the inbound buffer is double-buffered so it might be read later).

If one strives for maximum throughput, and does not want to spend an extra pin for handshaking or to perform some fancy signaling on the SS signal, the master must be written with knowledge of the slave's SPI interrupt latency.

This is why sometimes counting cycles matters.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan,

If you have control of both ends, you can manage after a fashion.

For example, I would always send 'reply = spi(question);' as a Master. Even when in a loop, the function overhead ensures a gap between each 8 clocks. Your Slave has to load its reply into its SPDR before a single clock has appeared from the next byte.

If you do not have control of both ends, you cannot ensure any gap at all.

So you either introduce some sort of handshake protocol, or use a different CPU. If you are in control, there is no problem.

But whatever you do, you can never achieve a 'hardware SPI'. e.g. A real 25Cxx chip has the reply value ready as soon as it receives the last address bit.

Even a double-buffered Transmit CPU has to do some software before knowing what to reply. But once you have got the start address, multiple reads are loaded before the Master has even asked.

Look at danni's answer in the other thread. Your worst case is absolutely appalling. Introduce a protocol, and you can live with it. i.e. a reasonable throughput far better than the simple worst case.

David.