[riot-notifications] [RIOT-OS/RIOT] drivers/adc_ng: Added common ADC API (#13247)
notifications at github.com
Mon Jan 25 00:08:03 CET 2021
Hi, I'm implementing the (old) ADC API for the QN908x and was mentioned this PR.
May I suggest two things to consider:
1. Should clocks / sample rate / sample time be part of this API? For example the `adc_ng_burst` function only says to sample N times, but it doesn't specify the sampling rate, which can be more accurately controlled if you configure the hardware to do a DMA burst read, assuming it is supported. If I get a vector of equally spaced samples, I think it would be useful to know that interval or request certain interval. If burst just means "sample N times without delay between samples" you still have some options to play with the sampling rate by changing the sampling time, which would likely give you a more stable reading (maybe more hardware filtering).
2. Should we have a more asynchronous mode? `adc_ng_burst` is starting to go into that territory, the function is blocking but the sampling happens at a certain rate, doing DMA. An implementation of this function would set up the DMA, set up the ADC to perform N reads and then block until the ADC interrupts once it is done, so it is pretty async from that point of view. One thing that's available in some CPUs is triggering of the ADC from other sources (from a clock / counter for fixed rate sampling, from an external source/GPIO and some other cases), in that case I could similarly do `adc_ng_sample_on_trigger(adc_trigger_t trigger, int32_t* dest)` and let the cpu module define some trigger functions like external GPIO input. You can of course implement this on software, but the timing delay will be more random depending on what else is executing.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications