MSP432 8-bit and 16-bit SPI Framing support

May I also participate?
Look at SPI implementation on the CC3200.
It has some significant enhancements:
- Selection of SPI word lengths at 8, 16, and 32 bits;
- Multiple SPI word access with a channel using an enabled FIFO (up to 64 bytes);
- No dead cycle between two successive words in slave mode.
So, why do not implement this in a new generation of MSP432 (32-bit with FIFO) and MSP430 (16-bit with FIFO)? It will give a significant impact on overall performance characteristic when external SPI displays or DACs are used.
But specially for DACs (where precise timings is essential) should be good to have additional trigger in SPI FIFO to send TX data controlled by an interrupt trigger from a timer. (In some DACs there is an additional data buffer with interrupt pin, so such specs for SPI are optional or useless for differential analog outputs).

Thanks,
Alexey

All my practical experience gives such results: MSP432 has very large SPI data buffer (which is not documented), but MSP430FR - has only one byte.

Thanks Folks,

We've come to the conclusion that although the MSP432 SPI implementation is indeed on an 8-bit framing mechanism, with a SPI Master implementation, both 8 and 16-bit is certainly possible given that one byte is transferred after the other…since the Master provides the clock in that case, as Robert noted above.  So yes, this should work fine and I appreciate the input from you all.  

From the customer, having an 8bits framing on the Master does not prevent you sending the required numbers of bytes to a particular slave, as long it matches the slave data length. So for a 16bits slave, you just activate the CS, send two bytes, de activate CS. The clock should be maintained for the two consecutive bytes.  And even if the clock pulse is maintained high/low longer between the end of the first byte and the beginning of the second byte, the data is actually sampled on one of the clock edges so it does not really matter.

In summary, the Master is able to support 8bits and 16bits framing for this type of application. 

Thanks,
CY

Chris Yorkey said:

In summary, the Master is able to support 8bits and 16bits framing for this type of application.

Why would they have thought otherwise. Seems like they didn't fully understand how SPI works. This interface has been around a long time (I was doing SPI slave designs in ASICs 20 years ago) and is fairly well understood.

The one thing that does seem to come up often is the "gap" between successive bytes do to the lack of a FIFO on the MSP USCI interface. But this can be mitigated by the use of DMA to load the bytes. Basically in your "transmit" function:

1. Program DMA for "many to one" starting at 2nd byte.
2. Optionally program a 2nd DMA channel for "one to many" to handle RX data
3. Set your chip select GPIO pin appropriately
4. Kick off the USCI by putting 1st byte into TXBUF
5. Wait for TX DMA channel complete interrupt, or
5A. Wait for RX DMA channel complete interrupt
6. Set CS back to inactive state.

You should get a continuous stream of bits out of the USCI with no inter-byte gaps. This will work even as SPI clock speed approaches CPU clock speed (for one-way transaction) or 75% of CPU speed (for two-way transaction). (NOTE: Those speed numbers are for MSP430. I have not had an opportunity to learn the intricacies of the MSP432 DMA controller overhead)

Robert Cowsill said:

I'm curious... what test conditions reveal the presence of this hidden buffer on MSP432?

Pushing a big amount of data (160kB) to SPI in closed loop to external device without waiting for completion and without loosing any single bit of data. (Condition 48 MHz MCLK / 24 MHz SPI clock).

Alexey Bagaev said:

Pushing a big amount of data (160kB) to SPI in closed loop to external device without waiting for completion and without loosing any single bit of data. (Condition 48 MHz MCLK / 24 MHz SPI clock).

Interesting... I'll have to do some investigation. Did you measure the time delay between the CPU (or was it DMA?) transferring the last byte and the output of that byte on the SPI bus?

Robert Cowsill said:

Did you measure the time delay between the CPU (or was it DMA?) transferring the last byte and the output of that byte on the SPI bus?

It has no delay. So, the answer is no, - there is only one byte SPI buffer on MSP432. (Data is transferring at full speed). The last ticks was spent to complete loop cycle. So after exiting the loop SPI busy flag is cleared.