Does the ADC conversion time need to be shorter than the timer interrupt if the ADC is driven by a timer interrupt?

[Riaan Laubscher]

I am driving ADC1 using the timer interrupt from TIM2. At the moment it is only converting one channel at certain intervals.

The ADC is set up with the following:

• ABP2 peripheral clock = 84 MHz
• PCLK2 divided by 8
• Timer 2 trigger out event as source
• Sampling time is 84 cycles

The TIM2 is set up as:

• ABP1 Timer clock = 84 MHz
• Prescaler = 83
• Counter period = 19
• Trigger event is set as Update Event

According to the reference manual the total conversion time for the ADC can be calculated as:

This means my Tconv = (84 + 12)/(84 000 000 / 8) = 9.143 us.

The timer is set for a frequency of F = (84 000 000) / (83+1) / (19 + 1) = 50 kHz, which is the formula according to the manual.

This means that TIM2 triggers a conversion event every 20 us (50 kHz).

What I would like to know is the following:

1) Does my ADC conversion time (Tconv) need to be shorter than the TIM2 trigger event? To me it seems as though this should always be true since you can't have a conversion time longer than the interrupt events.

2) If I read the ADC value from the HAL_ADC_ConvCpltCallback function like this:

does it mean that the callback will only be called every (20 + 9.143) = 29.143 uS? My gut feeling says yes since this called when the ADC is done converting. This means it starts converting every 20 uS, but only finishes 9.143 uS after that?

PS, I am assuming the best case scenario here according to the theoretical calculations that are provided. This does not include the overhead from any other code.

Thanks!

[Uwe Bonnes]

Of course, the timer should not trigger faster than the ADC conversion time. But you also should account for Interupt latency and such. And for such fast sampling, as you intend, set up DMA so only IRQ with DMA half and full complete are needed.

[Tesla DeLorean]

In a more normative sense you should have the TIM *TRIGGER* the ADC, and not start the new conversion in the callback.

[Riaan Laubscher]

Hi @Community member​. I do indeed let the TIM trigger the ADC. Thanks for the input!

[Tesla DeLorean]

Ok, but you're not allowing DMA to handle the capture of the data, and the HAL_ADC_GetValue() which will either stall the next conversion, or cause an overrun.

ST's model is to have DMA service the ADC, and you can either drive it in saturation (continuous mode, and double/triple interleave) based on the sample/conversion time, or pace it with a TIM a rates approaching the continuous limit.

IRQ loading at high rates can be decimated using deeper DMA buffering. I'd be wary of interrupting at rates beyond a few hundred KHz.