I receive SPI data from a remote processor which acts as the SPI slave. Per this thread, I’ve set the SPI transfer word length to 32 bits, to minimise the loss in transfer rate incurred by the momentary pause between word transfers. If I use a word length of 8 bits, the following issue doesn’t occur, but the total throughput of the interface is reduced due to the ~1us delay between each 8 bit transfer.
The remote processor packs a buffer with data, which is sent out on the MISO line via DMA. I have verified the byte ordering of this data to be correct with an oscilloscope. An example of this SPI slave data is as follows:
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
The data is received into an unsigned char buffer, and while the data is correct, the byte ordering is not. It appears that each of the 32-bit words has been processed as 4 SPI slave uint8_t integers in reverse order. As such, the receiving buffer looks like this:
3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8
I can correct the byte ordering in software, but I was wondering whether there was a hardware method for correcting the SPI reordering. I’ve tried using the SPI_LSB_FIRST flag when setting up the SPI interface, as well as explicitly setting SPI_IOC_RD_LSB_FIRST and SPI_IOC_WR_LSB_FIRST in ioctl(), but these don’t have any effect.
Is there a way to correct this in hardware, or is the only option to address the incorrect ordering in software?