Hi,

I've been looking at connecting a few PICs on a board through SPI. While
doing that, I had to find out that the SSP is really not very well designed
for an SPI slave implementation: if they had separated the receive buffer
from the transmit buffer and added double-buffering for the transmit byte,
that would do it perfectly for most applications, but not as it is. The
slave simply can't send data back to the master... :(

So what I did was to add a 5th line to the already four (3 SPI, 1 CS) that
goes from the slave to the master and works as a handshake control. After
sending the first byte (and receiving with it a default status byte), the
master waits for the handshake line to go active before it sends the next
byte. (I've actually put it on an interrupt input to make that easier.) The
slave will only activate that handshake line after it has read the byte
that just came in and fed the SSP buffer with the new data to be
transmitted. It knows that a byte came in because the SSP interrupt called.

I'm using the -SS input at the slave to control the SPO line (to tri-state
it under control of the master).

Does this all work? I've read some horror stories about SPI slave mode with
the SSP. The datasheets are not really very explicit about SPI slave mode.
(I'm talking about the 16F767 here.) But I can't really see where it
shouldn't...

I'm pretty sure that somebody has already done an SPI slave that sends more
than 8 bits. Can maybe somebody confirm that this can work, or has somebody
gone to great lengths with that and found out that it actually doesn't? Any
pitfalls to watch for? Or pointers to helpful material?

(I'm still in the hardware design phase, and I'd like to know whether this
all has a chance to work or whether I need to rethink the whole approach.)

Thanks,
Gerhard

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.