Post by thread:16F SPI slave multibyte transfers

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

Well, it is tricky, but you might be able to do the following: Track the master clock carefully (maybe use a CCP pin?) to get your timing right, and don't wait for the BF to be set - prepare and then shove the data into the SSBUF according to a timer you have setup that's as close to the master clock as possible. You can probably safely load it during the last half of the last transmitted bit, rather than waiting for it to complete before loading. If you use a PIC with two SPI peripherals (there are 47 18F pics with two MSSP channels) then you could use external logic to switch between the two in a sort of double buffering arrangement. Load the data in one and while it's feeding the master load the next chunk in the other. Switch the clock and data lines to the other (maybe be able to merely switch the clock line), and reload the first. Beyond that - you may want to look at using programmable logic chips (FPGA/CPLD/etc). This should be able to fit into the simplest/cheapest of them... -Adam On 8/6/08, Hector Martin <spam_OUThectorTakeThisOuTmarcansoft.com> wrote: {Quote hidden}> 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 > > > -