How to read ADC data at 48ksps

[Bastien LS]

I use the STM32U585, and an external ADC (ADS127L11). The ADC output 48000 sample per second, and rise a signal "Data Ready" for each sample. There is no data buffer in the ADC, thus the STM32U5 must communicate through SPI with the ADC 48000 times each second. 

What is the best way to do that ?

I already have a working solution using multiple DMA channels, but it looks a bit clumsy in my opinion. And the solution has a very small (but not 0%) chance of triggering an undetectable error (and lose 1 sample) if the DMAs get too busy.

Is there an "official" way to achieve that ? 

[TDK · Accepted solution]

There's probably a few ways here. Set up a DMA channel to send X bytes to SPI->TX when DRDY goes high (EXTI trigger). Set up another DMA channel to store SPI->RX into a buffer.

At 100kB/sec this won't begin to stress the DMA controller, and there is a FIFO to smooth things out if it does.

[MasterT]

Default way is to trigger interrupt on GPIO connected to DRDY , than you have over 20 usec to complete SPI transaction. Using SPI at 24-40 MHz all it takes < 1usec, plus another 1usec to jump into and out intrerrupt, Less than 10% uCPU load

[Bastien LS]

Thank for your answers. We aim continuous acquisition, and low power, so the DMA solution is prefered.

@TDK This is the solution I am using currently, with multiple buffers to store the data. I am glad to read this.

Yet, this solution comes with a risk, as said earlier. Now I remember posting about this issue : 

Solved: Is this possible to disable / monitor trigger memo... - STMicroelectronics Community

In short, if the DMA SPI-TX gets stuck for more than 1 period of data (1/48000 s), but less than 2 periods of data, no error will be triggered (the second trigger is "memorized"), but the same sample will be read twice (and the sample before is lost).

Can you think of an other solution that prevent this risk ?

[TDK]

> if the DMA SPI-TX gets stuck

This is not a credible scenario. DMA works as described in the RM, is very responsive, and is not subject to random intermittent delays.