The SAR ADC's S/H window, or: What does ADC really measure? (IDFGH-66)

[HubbyGitter]

This can be seen as an extension to my ADC documentation request #792 which already has a ticket ID.

Presumably, the SAR ADCs have an upstream S/H. The question is, when is that really exposed to the selected source.

My observations (in "digital" / non-RTC domain) seem to suggest that if one has only one source for a given ADC (even when going through the repeated configuration which adc1_get_voltage() does) then the S/H is working continuously for that source, and the actual sample will depend on the signal from after the last measurement until the next measurement is requested. If one switches channels by SW or FSM in the meantime for the same ADC, things look differently.

While the latter comes as little surprise, the former would be very interesting. E.g. if one really wants a timed spot measurement, one would have to switch to another channel before. And the other way round, one could reduce the sampling frequency if one is interested more in a summarised sample, if the ADC measures a single channel exclusively. But in order to rely on this, it must be documented what the window for the S/H actually is.

The next question is, how are things in the RTC world. The ADC command selects the source and waits for the result. If the source is the same as for the last sample, will the same effect be seen as in the "digital" domain?

Finally, what would be the minimal instructions (setting registers) to control the S/H explicitly,

• e.g. in the "digital" domain after a spot measurement of channel m to return to a longer-lasting measurement of channel n, without having to measure,
• e.g. in the RTC domain to have a spot measurement without having to busy wait for a dummy measurement of another channel?

Thank you!

[projectgus]

Hi @HubbyGitter ,

Thanks for being patient while someone got back to you.

The reason for this is to avoid spending additional time setting up and tearing down sampling when taking consecutive samples. For most input sources there shouldn't be a major difference.

If you have an additional use case regarding this behaviour that you think is not served by the current driver API or hardware behaviour, please open a new issue as a feature request and we'll see if it's possible to implement.