[Argh, forgot the tag. Sorry for the dupe.]

Hello all,

I seem to have stumbled across a limitation of the 16F SPI peripheral.
I'm trying to implement an SPI slave that communicates with a master
with the following simple protocol (as seen from the master):

Assert SS
SEND 16bit 0x0000 (discard received data)
RECEIVE 32bit
Deassert SS

Clockrate = 1Mhz.

As far as I can tell, implementing this properly on a slave with CKE=1
CKP=0 is not possible, or at least not practical. The transaction is
multibyte, and there is no wait between the two 8-bit halves of, say,
the 16-bit part (and only a small wait between the 16bit and the 32bit
part, since the master here is *very* fast) - the clock just keeps
running. In CKE=1 mode, the first bit of the output data has to be
available as soon as the clock switches into the idle state. However,
that is also (going by the diagrams) the precise moment that BF is set.
Even if the PIC is okay with having SSPBUF loaded after the clock goes
low, I would only have 0.5us to do so before the clock goes high again
and the master samples the data. This isn't enough if you take into
account the BF check latency and the time needed to read, store, and
write to SSPBUF (8 cycles). I'd need a PIC running at over 64Mhz :(

The main problem here is that the TX side of SSPBUF isn't double
buffered, so I have to wait until the first byte is transmitted and then
somehow set up the second byte in the impossibly short amount of time
between them.

When actually trying to implement this, ignoring the timing constraints
(i.e. I'm sure I'm late loading SSPBUF after the first byte), what I see
is that the PIC's SPI peripheral just refuses to perform any
transmissions after the first byte, until SS is reset. Even BF never
gets set again after the first byte is done, and the master just sees
zeroes for the rest. Although I can control the master for debugging
purposes, the protocol is fixed and I can't change it in the final
application.

Have I missed something, or is implementing what I say, in fact, not
possible?

Thanks,
Hector Martin



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist