Custom SPI Datasize

[SJohn.5]

Hello,

I am trying to interface to an external ADC via SPI. I amusing the STM32Cube IDE with a Nucleo-144 STM32L552.

The issue I am having is that the ADC requires an unusual number of clock pulses (18 as per data sheet - see attached screenshot). Note, in this situation the ADC is the slave, the Nucelo the master providing the sclk pulses.

From what I can gather, there is no way to set a custom number of clock pluses in in the Cube IDE, rather you are limited to 2, 4, 8, 16 etc. number of data bits and the clock pulse parodies these values (as to be expected).

My question, is there any easy way to get 18 clock pulses using the existing cube IDE and HAL functions?

Regards,

Sam

[TDK]

> From what I can gather

If you're looking for info, the reference manual is usually the best source.

> My question, is there any easy way to get 18 clock pulses using the existing cube IDE and HAL functions?

The SPI module in the L5 can be set to have a word size anywhere between 4 and 16 bits. Using 2x 9-bit words will get you to an 18 bit transaction size.

 

These are settable in CubeMX:

[S.Ma]

Maybe use 8 bit mode and generate extra clocks at the end of conversion to start easy. The adc uses spi sck as adc clock and should be jitterless. Extra clocks will just trigger another conversion which will be aborted by nss rise edge. The spi has 4x32 bit fifo so the whole frame can go through if you write 3 bytes in tx fifo. Then once 3 bytes received, get the data out. The nss is sw controlled so will it limit the max sampling rate, unless you do use mosi as nss... then dma maybe possible. To dig more. Nss will then require more sck clock pulses.... which you now have...

[SJohn.5]

Thanks for the replies.

I managed to solve the problem, and as you suggested, I used the 8 bit mode to write 3 byte frames worth of clock pulses. It was then just a case of parsing the desired 16 bits together.

initially i was having difficulties as I was trying to use the 16 bit mode i.e. send two blocks of 16 clk pulses to get the required data. What I was finding with this was that in 16 bit mode there was an unwanted delay/dead time between each block of 16 pulses. Oddly, this did not occur in 8 bit mode.

Cheers,

Sam