Lies, Damn Lies and Analog Inputs (Comparing ADCs on ESP32, Pico and Arduino)

Having said all that, I have heard the analogue inputs aren't that great on the ESP32.

It would also be useful to have a function generator hooked up and simultaneously digitizing the signal, that's usually how I do my comparisons but does require some more expensive tooling.

Except, you'd need a phononic representation of the signal pre/post ADC and/or better voltage quantization.

Is this level of component variance the reason we can't do quantum computers with electron charge?

Qubit > Physical implementations does list Electron spin and also Electron charge, which ADCs quantize: https://en.wikipedia.org/wiki/Qubit#Physical_implementations

Compared to a $3 ESP32 and a $6 Pico without a RTC Real Time Clock,

HiFiBerry DAC ADC Pro has a "Dedicated 192kHz/24bit high-quality Burr-Brown ADC" https://www.hifiberry.com/docs/data-sheets/datasheet-dac-adc...

ADC: Analog-to-digital converter: https://en.wikipedia.org/wiki/Analog-to-digital_converter :

> In electronics, an analog-to-digital converter (ADC, A/D, or A-to-D) is a system that converts an analog signal, such as a sound picked up by a microphone or light entering a digital camera, into a digital signal. An ADC may also provide an isolated measurement such as an electronic device that converts an analog input voltage or current to a digital number representing the magnitude of the voltage or current. Typically the digital output is a two's complement binary number that is proportional to the input, but there are other possibilities.

Integral linearity: https://en.wikipedia.org/wiki/Integral_linearity

When I'm making something that requires precision, though, I never use them and go with a dedicated ADC instead.

Or maybe they aren't licensing the (expensive) analogue silicon design tooling.

For example, they have no 5Ghz model. The ADC performs really poorly. The RF capabilities don't seem to have changed for a decade. Etc.

Wrangled out some decent results at an impressive 80kHz sample rate in continuous mode, using DMA for near-zero CPU involvement. Here's a plot captured at the time (along with an analog probe for comparison): https://imgur.com/a/5zfy9LZ

I'm not sure if [m]any other people have done this, and one day I'd love to get around to posting sample code along with a little writeup.

It was a real uphill battle to get there. Discovered and reported dozen[s] of errata in documentation to EspressIf (most of which was acknowledged and queued for correction in their next Technical Reference Manual update, although I admit after a couple months I stopped checking to see if surfaced). Lots of undocumented bits had to be deciphered (including basic ones in SYSTEM_PERIP_RST_EN0_REG and SYSTEM_PERIP_CLK_EN0_REG to reset the ADC peripheral and enable it's clock, and power control bits in SENS_SAR_POWER_XPD_SAR_REG).

ADC2 is write-off for anything high-speed, as the entire digi controller was 'dropped' from support due to bad silicon (there's some interesting history and trends if you read up on ADC errata across earlier ESP32 models - it's clear EspressIf really struggled with analog, but they're inching forward with progress as the lineup evolves). Unfortunately when they yanked the documentation for it, they went a little overboard and removed some whole sections that relate to the still-working ADC1 (e.g. all mention of APB_SARADC1_DATA_STATUS_REG, which stores the most recently sampled ADC1 result, was lost in collateral damage).

Other minor documentation pains included mistakes in DMA descriptors, subtly incorrect command sequencing in the ADC Pattern Table (that one cost a couple evenings of debugging to track down), incorrect and sometimes senseless information referring to the use of a flag in GDMA_OUT_AUTO_WRBACK_CHn for a receive channel, ADC_ATTEN_DB_11 constant being used all over the place even though it's actually 12dB (granted that's a nitpick), unintuitive and undocumented behavior that seems in some circumstances to cause GDMA to not move onto the next descriptor until DMA_IN_SUC_EOF is generated, certain actions like pausing and resuming DMA (e.g. for diagnostic instrumentation code to retrieve a consistent snapshot of all the involved registers) seems to corrupt the descriptor pointer (that one might turn out to be by design), and other little mistakes like copy/paste errors or other ambiguities. That all said, it's still not the worst documentation I've seen.

Hardware ADC calibration can significantly improve results, but it's unfortunately buried under undocumented ROM functions required to initialize and enable the feature (via an undocumented I2C configuration bus); without this my readings were off by ~50%. (There's something called an "Internal Calibration Bus" which sadly isn't mentioned once in the docs).

All in all a fun project, though in retrospect it would have taken a lot less time to get up and running with a dedicated ADC chip in my BOM.

Where did this number come from?

AFAIK all pins should operate at 3.3v, and I see no mention of a 1v maximum for that board, or the esp-chip either.

Sigh. No they don't. RP2040 ADC has output resolution of 12 bits with ENOB of about 8.7. MicroPython probably scales those up.

Also, 65535.

This is surprisingly low quality blog post for HN standards.