# Use Cases for an External ADC

Most Microcontrollers (uC) have an Analog to Digital Converter (ADC) as part of their peripheral set, which is phenomenal as this integrates two components into a single package. These ADCs are usually register mapped as well, which allows the data to be extracted quickly and easily.

In spite of this tight integration, you can still purchase external ADCs. I can see several cases for these:

• The ADC needs to be isolated from the uC.
• The bit depth of the ADC samples needs to be higher than the uC's ADC.
• The voltage to sense is far from the microcontroller and long analog lines are not acceptable.
• The voltage to sense is in a harsh environment not suited for the uC.
• The external ADC samples much faster than the uC's ADC.
• The reference voltage for some sample is different than for others, requiring multiple Vref pins (and thus multiple external ADCs).
• The current uC doesn't have enough ADC channels and the cost of putting a new uC is prohibitive.
• The external ADC consume less power than the uC's ADC (I would need an example to believe it).
• The ADC channels must be sampled simultaneously (rare scenario).
• The cost of programming firmware at manufacturing time outweighs the cost of the more expensive ADC part (unlikely).
• The PCB has space constraint and no uC can fit (unlikely).

This is all well and good, but what strikes me as odd is that external ADCs are usually quite a bit pricier than their uC counterparts, yet provide equivalent functionality. For instance, you can purchase a EFM32Z part with a 12bit 1Msps ADC (with internal reference) for about $1, or you could purchase an equivalent 12bit 200ksps ADC for about$3.50 (same speeds(ish), relatively same power numbers, etc) and perform the same task (extracting ADC data).

The question then becomes: are there compelling reasons an engineer would favor an external ADC over a uC's ADC when the latter can perform the same functionality?

• Simultaneous sampling is actually a pretty common scenario in some application spaces, like signal processing. – Jason R Dec 10 '14 at 16:18

If the internal ADC of your microcontroller performs the job you need it to then no, there is no need for external ADCs. But then, that's not who they're aimed at.

You have covered most of the reasons for an external ADC, but there are a few more, and in my opinion, they are some of the most important reasons:

1. You need a different sampling technology - for instance the internal ADC is SAR, but you need to do Delta Sigma.
2. The internal ADC, because it is internal, and shares the same die as the main MCU, will never be 100% free from the noise of the rest of the MCU, so an external one would be possible to make ultra low-noise
3. Your microcontroller / SoC / FPGA of choice has no ADC. The latter two are most likely - most common SoCs and FPGAs don't have any ADC at all. Yes, you can get ones that do, but many don't. So you add an external one.

For point 3, take the Raspberry Pi for example. That has no ADC available at all, you have to add an external one to do any analog work at all.

• Now that's interesting. When it comes to noise, instead of paying to get an external ADC, would the same result be achieved by getting a higher bit-depth uC ADC and ignoring the least significant bits of the sampled result (this obviously assumes that the extra conversion time from the additional bits is not an impeding factor). – TRISAbits Dec 10 '14 at 2:04
• After-the-fact signal processing can only help with noise from processes that are independent of the sample timing (and thus contribute "random" noise). Much of the noise in a processor system will be a result of variations in power-supply and ground loading that are somewhat synchronized to the sampling process; the only way to avoid them is to have the ADC use its own detached supply rails. Note that full isolation isn't necessary, since many ADCs can easily tolerate 100mV or so between analog and digital VDD/VSS. – supercat Dec 10 '14 at 4:41

Another few reasons to favor an external ADC:

1. Many external ADC parts include differential inputs, while microcontrollers' built-in converters often don't. In cases where inputs have a lot of common-mode noise, that can be very important.

2. Many external ADC parts include an amplifier stage before the converter itself, thus allowing the converter to measure a high-impedance signal directly. On many microcontrollers, the act of sampling an input signal may disturb it. Depending upon the nature of the input signal, this may vastly increase the acquisition time necessary to make accurate measurements.

3. Even if an internal ADC is twelve bits wide, that generally won't mean it takes readings accurate to one part in 4096. A typical external ADC will often have better specifications than an internal one, even when both have the same advertised bit depth.

Integrating an ADC onto a microcontroller is easy. Integrating a good ADC is much harder. Guess which is more common.

• SAR ADCs suffer a little from charge injection, because momentarily connecting the sampling capacitor array to the input disrupts what's being measured. If the input source doesn't recover quickly enough, this causes measurement error. More resolution usually requires a larger internal sampling capacitance. Delta-sigma resolution only depends on extending a digital counter. (Though good high-resolution INL/DNL specs are not trivial to achieve.) – MarkU Dec 10 '14 at 1:41
• @supercat: I had never considered an amplifier stage as part of the conversion. This opens interesting circuit sampling avenues. – TRISAbits Dec 10 '14 at 2:11
• @MarkU: I've observed the charge-injection issue in some circuits. Curiously, some converters seem to try to charge the input toward the previous sampled value (from whichever input was sampled last), some try to charge it toward zero, and at least one seemed to arbitrarily ("randomly") charge it toward a higher or lower voltage which I found rather annoying. I don't understand why a part would do the latter; even if it had to charge toward something, charging toward zero consistently would be better than charging toward some "random" value. – supercat Dec 10 '14 at 4:36

Another reason for some external ADCs to exist : they have been around quite a lot longer than micros with internal ADCs, and designed into many products. Possibly 20 or 30 years longer. (Probably not the case for the SOIC part linked, though it may be a modernised die-shrunk variation of a classic part)

Where the ADC doesn't have stellar resolution, accuracy or speed, yet commands a premium price, this may be the reason.

Even for new designs it may be preferable to re-use blocks that work well, rather than re-engineer around a newer part (even if the resulting integration reduces BOM cost). That reengineering can be expensive; the test and regulatory approvals process, even more so.

Now if you're starting from scratch, and your chosen microcontroller has enough ADC channels that fulfil your requirements, none of the above applies.

I realize this is a very old question, but it's a question we debate internally pretty frequently.

You're right, it would be unusual to choose an external ADC if the external version was exactly functionally equivalent. However, in my experience, low cost micros usually have pretty lousy ADCs with temperature drift, low bit count (10 - 12 bits) and noise from VCC (+/- 20mV in some cases)... although the inverse can be true... you can improve S/N if you over-sample and have noise present. In our product development activities, it's pretty rare to base our selection of MCU upon the quality of ADC present within. Usually it's more about toolchain, cost, extant firmware etc. The internal ADCs are usually limited to non critical tasks like reading battery voltage.

With various micros, there can also be issues with shared timers that need to be monopolizeed for fast sampling times, but interfere with other things in the MCU (software serial ports, ISRs etc) when they are monopolized for the ADC.

Also, what is VREF? If you're using VCC as a reference in firmware, even if you calibrate to the "real" VCC, that value can fluctuate pretty dramatically during operations. If you have an on board high-current device (radio, wifi, MCU etc) with large transient current usage, VCC might dip to 4.8 volts during a transmit and if your sample occurs during that window, and you naively convert the 0-1023 ADC read value to voltage with ADC_VAL / 1023 * 5.0 - you have lost a whopping 200mV of precision. Or, if you have different power modes (USB, Wall wart, battery) - VCC at the MCU can change (especially with USB). External ADCs (even with the same bit count) can provide rock solid internal vref under fluctuating VCC conditions.

Resolution is pretty important. I imagine there is some use (in the real world) for 10-12 bits of resolution, but for any kind of real-world application (gas detection, acoustic measurement, accelerometer measurement, precision temperature measurement, etc) 16-bits is usually the minimum resolution to achieve adequate signal to noise and resolution characteristics. Even a really nice 32-bit MCU like Atmel's SAMD are limited to 12-bit internal ADCs.

Clock jitter is also an issue and there is also some inherent imprecision when other 8-bit micros are required to provide a 12-bit wide reading and it needs at least 2 clock cycles to manipulate a 12-bit value, which may not be true with an external ADC (since they can have internal oscillators).

There are also times when physical proximity to your transducer and isolation from the MCU is important. Some very sensitive transducers require their own conditioned power, isolated ground planes and extremely sensitive transimpedance chopper amps with 0.01% passives.

Sometimes there are compelling reasons for using the internal ADCs though. DMA is one reason... sampling rate is another. Ease of oversampling is another. Interfacing external ADCs at high data rates can eat up a lot of valuable multiplexed I/O pins and make for a more complicated design. Also, many of the ADCs we've used are I2C based, so the sampling rate is very limited by I2C bus speed. Even at 1mbits/sec, a 16-bit read takes a painfully long time.

• This is excellent insight! As the years have gone by (and my experience grown) I would have to agree: internal MCU ADCs can be rather lousy. – TRISAbits Nov 26 '18 at 0:47