-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async (non-blocking) ADC API (IDFGH-64) #792
Comments
Isn't adc1_get_voltage still using RTC SAR ADC controllers? DIG SAR ADC controllers with DMA are the performance ones but I don't know if there is sufficient documentation to use them. It seem like you have to use together with i2s. |
@negativekelvin Interesting point. I didn't think so. Also, according to Tech Spec, section 21.3.2 "Features" says DMA is available only on one controller, while Figure 73 "SAR ADC Depiction" shows DMA for both SAR ADCs. |
I think that is because the one controller can scan both ADCs. Even though in other places they are referred to as separate controllers. |
This ticket has been opened for a long time, but for the benefit of anyone still wondering about this: The I2S driver now supports a way to read one or two ADC channels directly via DMA at a fixed sample rate, with no CPU overhead at all. This is supported via driver/i2s.h. This is the way to read ADC channel(s) quickly at a fixed frequency. There is still probably a good use case for an asynchronous ADC API though, so it's possible to make one function call to start a conversion, and then another function call later to read the result. Keeping this feature request open for this. |
My wish, if I may say that, would be that a few essential ADC properties be specified / documented and that either the register usage is clarified officially or the ADC API is extended for additional flexibility, namely such that busy waiting for the ADC result can be avoided.
And here now comes the motivation.
Elsewhere,
well-known @nkolban described that wantig fast ADC was a symptom of underlying masochismESP_puff wrote:Being utterly masochistic,Although I now believe that sampling every 100 µs may be sufficient in my case (still well above 6 kHz), I had read in the Tech Spec that two of the SAR ADC controllers "support high-performance multiple-channel scanning" (emphasis mine) and was really expecting that the ADCs would need around 8 µs and that I should aim at having one sample per 50 µs at least, maybe even 33 µs.(Suboptimal, but feasible) test recipe:
vTaskNotifyGiveFromISR()
adc1_get_voltage()
, calculates moving average, filters and takes sample sequences and callsxQueueSend()
(if it fails, it fails)Turns out that this works down to ~ 50 µs so that made me curious. It looks like:
adc1_get_voltage()
runs in a little less than 25 µs,adc1_get_voltage()
code does) is finished within 10 µs (mostly busy waiting)..I would like to reclaim most of the 25 µs,
(Yes the sampled values will be outdated by a few microseconds.)
Because even at one sample per 100 µs, the not strictly necessary 25 µs of
adc1_get_voltage()
have a pretty big share, and that's not going to get better should this function be changed to correct for the slightly non-linear results as announced by @Spritetm (which I don't want and don't need to deal with at the time of the measurement).Specific questions are,
Thank you!
P.S. @nkolban ...sorry, couldn't resist...
The text was updated successfully, but these errors were encountered: