Is it possible to improve delay between two LL_SPI_TransmitData16

[SVans.1]

Hello,

currently reading out an ADC sensor with SPI. The goal is to achieve a fast readout. Currently I am at around 200000 readouts per second, but I am wondering if this delay between two LL_SPI_TransmitData16 is because of the LL_SPI_ReceiveData16 or just because of the way LL works. Is it possible to even get faster readouts with adjusting some code? (clocks are maxed out already)

See code below:

GPIOD->BSRR = PIN_SPI_CS << 16U; // CS LOW
 for(int i = 0; i < 2; i++)
 {
     while(!LL_SPI_IsActiveFlag_TXE(SPI1));
     LL_SPI_TransmitData16(SPI1, 0x0000);
     while(!LL_SPI_IsActiveFlag_RXNE(SPI1));
     spiRxBuf[i] = LL_SPI_ReceiveData16(SPI1);
  }
GPIOD->BSRR = PIN_SPI_CS; // CS HIGH

And here is the signal capture: (MOSI, CS, CLK, MISO)

Thanks!

[MM..1]

Hmm CLK i dont see but hexa codes shows 8bit nums, then why you use Data16 ? For high speed yuo can try DMA

[TDK]

The delay is there since it has to complete the transmission before a byte is received.

DMA will eliminate the delay, but also add some delay for setting up the DMA. Might be a wash for only 4 bytes.

You could unroll the loop for a slight improvement.

Higher compiler optimization levels, if possible, will probably reduce the delay.

You can also send the first byte and queue up the second before reading the first returned response. This can cause trouble (overrun) if it jumps to an interrupt before you read the first response.

[waclawek.jan · Accepted solution]

Which STM32?

Start with switching on compiler optimalization.

Then read thoroughly the SPI chapter and make use of the FIFO (I suspect your SPI does have it). There's probably also NSS pulsing switched on unnecessarily, but that's only a small detail.

JW

[SVans.1]

Hello,

compiler optimisation boosted the readout to around 350 kSamples/s !

Thanks for the help

Sebastiaan