Repository navigation
esp32: ADC driver update to the new esp_adc. - #16630
Merged
Merged
Conversation
dpgeorge
reviewed
Jan 25, 2025
purewack
force-pushed
the
esp32/esp_adc
branch
from
January 25, 2025 17:11
4456772 to
9c6ff73
Compare
projectgus
reviewed
Mar 4, 2025
projectgus
left a comment
projectgus
left a comment
Contributor
There was a problem hiding this comment.
I have one small note but this looks really nice, thanks for submitting it @purewack!
projectgus
approved these changes
May 15, 2025
dpgeorge
reviewed
May 16, 2025
purewack
force-pushed
the
esp32/esp_adc
branch
2 times, most recently
from
May 28, 2025 08:30
53c0c52 to
d13d11f
Compare
dpgeorge
reviewed
May 29, 2025
purewack
force-pushed
the
esp32/esp_adc
branch
2 times, most recently
from
May 29, 2025 13:18
75c404f to
c52f5d6
Compare
This commit updates the ADC to use the new driver `esp_adc/adc_oneshot.h`. There are several errata notes about not being able to change the bit-width of the ADCs certain chips. The only chip that can switch resolution to a lower one is the normal ESP32. ESP32 C2 and S3 are stuck at 12 bits, while S2 is at 13 bits. On the S2, you can change the resolution, but it has no effect on the resolution, rather, it prevents attenuation from working at all! The resolution is set to the maximum possible for each SoC, with the ESP32 being the only one not throwing errors when trying to set the bit-width to 9, 10, 11 or 12 bits using `ADC.width(bits)`. Signed-off-by: Damian Nowacki (purewack) [email protected]
dpgeorge
approved these changes
Jun 5, 2025
dpgeorge
left a comment
dpgeorge
left a comment
Member
There was a problem hiding this comment.
This looks good now, a nice improvement, thank you!
Tested with ESP32_GENERIC firmware. Deinit'ing and then doing a read now raises EPERM.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is a complementary PR to #16521, focusing only on ADC, updating it to fix an issue with the RISCV adc function causing a conflict of drivers mentioned in #16469
There are several errata notes about not being able to change the bit-width of the ADCs certain chips.
The only chip that can switch resolution to a lower one is the normal esp32.
esp32 C2 & S3 are stuck at 12 bits, while S2 is at 13 bits.
On the S2, you can change the resolution, but it has no effect on the resolution, rather, it prevents attenuation from working at all!
I have set the resolution to the be maximum possible for each SoC, with the esp32 being the only one not throwing errors when trying to set the bit-width to 9,10,11 or 12 bits using ADC.width(bits)
Testing
I have built and flashed the following variants: Generic, S2, S3, C3
The ADC behaves correctly as expected, with readings following the position of a 10K potentiometer.
Attenuation works too where values above the maximum range get clipped and readings stay at the maximum attenuated level: