SPI bus transmit buffering?

[dbaltz]

We are using SPI slave mode on a PIC18F46K22 to exchange messages with and PXA270 board. Receiving on the PIC is not a problem as the shift register is copied to SSP1BUF on receipt and I have 8 clocks to read it. When transmitting, the documentation says that the transmitted byte is copied to the shift register simultaneously with the write to SSP1BUF--meaning there is no buffering. As a result, since the PXA270 sends a continuous clock while receiving, I have only one clock (maybe) to load the next character after the previous byte is transmitted. I can't believe that this is how it is supposed to work? What I am seeing is a WCOL collision flag getting set after the first byte is sent.

Hopefully, someone out there has found a way to make this work.

[Ttelmah]

That is the way SPI works. You have to pre-load the next byte. This is what is sent on the next transaction.
You load the SSPBUF, and this is transferred to the physical shift register on the _next_ clock from the master. If a master is expecting a reply, it has to allow enough time for this load to take place.
The code on your master would have to be changed to allow enough time for this to happen. The only devices that would support continuous 'unbroken' clocks would be ones using a double buffered RAM array, implemented in something like a FPGA. If you can't change the master code, then you'd have to add hardware buffering like this....

Best Wishes

[dbaltz]

That is really unfortunate (and inefficient) that the Master must send and receive a byte at a time. The overhead of the WriteFile and ReadFile is quite high. It would seem more useful if Microchip had buffered both the transmit and receive. I guess I know what to do now to make it work though. Thanks for the clarification.

[Ttelmah]

This is not only Microchip. 90+% of simpler microprocessors, do not double buffer the returned data in a slave transmit. The few that do, are a couple of later Motorola chips, some Texas chips, and faster chips like the PIC32.
The PIC32 does double buffer, and remember that chips supporting DMA, can auto load the byte for you (this is what most processors do). So most PIC24's for example, and few more exotic PIC18's.
Remember that the basic 'PIC', is a device with very limited RAM, so the idea of doing more than a few bytes in a transfer is not really handled, and a small amount like this can be handled by sitting polling the flag and loading immediately.

Best Wishes

[ckielstra]

Many of the PIC24 chips have a selectable 1- or 8-level FIFO on SPI.

[dbaltz]

I'll probably use the PIC UART on future revs. It sounds like it will be faster and a lot easier.