know any cheap (single dollar range) 4+ channel ADC with I2C?

[JPortici]

Last night i couldn't sleep so i went on thinking about a forecoming project.
There is a big mcu (144 pin) which can't really be changed due to peripherals unless i move to something like NXP MPC56xx, which i'd like to avoid for now - would have to rewrite and test a lot of code.

Anyway, in both cases almost all fast 12bit analog channels are being used for sensors but i'll also want to monitor the status of the board (external and internal voltage rails, current consumption per rail, temperature in various parts of the board, for logging purposes and to detect faults and tampering)
for this i will necessarely need at least one external ADC with 3 or 4 channels, though they are crazy expensive compared to for example a PIC16F15313... especially because no high sample rate or accuracy is really needed.

I was checking out a TI part which has 3 differential channels to monitor the three current rails, attaching the inputs directly to the shunts (common mode range should be ok), however it seems it's still cheaper to use three INA opamps and a PIC once i look at the prices for 100-200 board runs... Board space? That may be an issue but it's a bit early to know.

I would generally avoid putting more than one programmable element in a board, however i do have some GPIOs free (which can only be GPIOs, no alternate functions) and bit-banging a PIC16 programmer is very simple... I can use the main MCU to program the daughter MCU, in case i have to update its firmware.
(PIC16 parts get with LVP mode enabled straight from the factory, the only way to enable/disable it is through HVP)

What is the usual approach in this case? why aren't there cheap-ass ADCs with like 4/8 10 bit channels at 100/200kSps, just like those in cheap MCUs? Or why can't i find them?
I2C is of course a plus, during pin planning i reserved an spi port with at least two CS pins for future expansions, but I2C would be better.

[Ice-Tea]

Why don't you use an analog MUX and one of the internal ADC channels?

[tszaboo]

ADC084S021 - 4 Channel, 50 ksps to 200 Ksps, 8-Bit A/D Converter - 1USD @1K
ADS7041 Ultra-Low Power and Ultra-Small Size SAR ADC | 10 Bit | 1MSPS | Single Ended 0.6USD @ 1K
SN74LV4052A - Dual 4-Channel Analog Multiplexer/Demultiplexer 0.1 USD @ 1K

FYI, you never get 100KSPS through I2C. And the usual solution depends on your market. If it is consumer, you dont monitor voltages. If stuff breaks, the device simply doesn't operate as supposed to.
If you are designing something like home automation, or white goods, where you are supposed to relatively reliably work for some years, maybe add voltage comparators for the voltage rails. There are plenty for these, any reset IC or voltage monitor can do it. Usually you just parallel the open collector/drain outputs and let the MCU know, that stuff is broken.
If you are designing to industrial environment (or similar, automotive, etc), where broken stuff costs serious money, that is the only time you worry about this. Yes, you can ADC it, and use opamps to amplify shunt values and stuff, but why would you? There are I2C current shunt monitors, multipurpose devices, dedicated subsystems to do this for you. Like LTC2937 , LTC2975, INA233 . Sure they are expensive. But if you are designing an industrial system and dont have money for this, then you are in the wrong business.
Or you want the system to be "software upgradeable" for some unknown reason. If you specify that the 12V rail has to be between 11.5 and 12.5, there is really no need to ADC it, just route it to to comparators through 4 resistors.

[JPortici]

Why don't you use an analog MUX and one of the internal ADC channels?

Actually not a bad idea, ADC is scanning + DMA through channels. In theory i can get an interrupt at every scan cycle end, i have to test it. In that case, at every scan cycle put the data where it belongs and change the channel.

FYI, you never get 100KSPS through I2C.

yes, i know. The signals however are inherently slow (voltages and currents are supposedly constant, or in average a lot slower than sensors, same for temperature)

If you are designing to industrial environment (or similar, automotive, etc)

correct (also hinted by the MPC56xx) but i can't always throw expensive parts at the problem.
however, thanks for the heads up on digital shunt monitors.. the few AFE for power monitoring i looked at, it seemed they were designed for high current and/or working with mains

[IDEngineer]

generally avoid putting more than one programmable element in a board

So don't treat it like a second programmable part. Program it to behave like the cheap 4 channel I2C A/D you wish you could find.    You can't reprogram one-chip A/D's, and folks use them all the time, so use an inexpensive PIC with enough A/D resolution and inputs to do what you want. It becomes a black box that acts like a dedicated A/D with all the features you wanted, but no more - do all higher level stuff in the "one and only programmable part" on the board.

Just a different way of thinking about it.

[JPortici]

So don't treat it like a second programmable part.

but it does have to be programmed at some point! by the manufacturer, or during board manufacture or during testing or during an update because a bug was discovered. having to program more than one chip per board is a massive waste of time.
That's the problem.

Luckily as i said i have enough flash and spare GPIO-only pins on the main MCU so i can implement a pic programmer inside the bootloader

[AndyC_772]

In production, it can be ordered as a pre-programmed device and soldered to the board like any other. If you use a PIC, for example, Microchip Direct will program it for you for about 10p per device.

It's a mistake to think that any device with firmware on it needs to be field programmable; you'll waste a lot of time trying to implement ways to update it, when its only function is so simple that it really can be reliable.

If you're that worried, just make sure your main CPU can reset the ADC PIC, so if it gets confused for some reason there's a simple workaround.

[tszaboo]

In production, it can be ordered as a pre-programmed device and soldered to the board like any other. If you use a PIC, for example, Microchip Direct will program it for you for about 10p per device.

It's a mistake to think that any device with firmware on it needs to be field programmable; you'll waste a lot of time trying to implement ways to update it, when its only function is so simple that it really can be reliable.

If you're that worried, just make sure your main CPU can reset the ADC PIC, so if it gets confused for some reason there's a simple workaround.

And then one day you will be burned by this. Yes, it is possible to design a board with a second MCU, with code that doesnt need updating. You test it and it is very likely to work. And you make 5-10 designs with this concept, and the 11th time you need to update the second MCU, and you need a recall, or someone going on site and disassembling product. Or other inconvenient and expensive thing. That is why there are GPIO extenders on the market.
For example a MCP23008 "8-bit I/O Port Expander" is a PIC16 with some code on it. And it is extensively tested and working. And while the PIC16 is cheaper, I prefer the MCP23 every time, if it fits the task. The same way, I prefer an ASIC doing something instead of a micro.

[danadak]

Low end PSOC, onboard +/- 1% Vref, SAR, other resources available. OpAmp, DAC
PWM, Logic .......

< $ 2 at low volumes.

See attached.

Regards, Dana.

[IDEngineer]

Yes, it is possible to design a board with a second MCU, with code that doesnt need updating. You test it and it is very likely to work. And you make 5-10 designs with this concept, and the 11th time you need to update the second MCU....

That's only because you're still thinking of it as a programmable device.

If you use a given "fixed" part in 5-10 designs, but it doesn't match what you need in the 11th, do you expect the manufacturer to redesign it? Do you claim the part is now, suddenly, broken? More likely, you find a different "fixed" part that does what you need in that 11th design and not give it another thought.

Another way to think of it: Many "fixed" digital parts can be (ahem) "programmed" by tying various pins high or low. What if you need to change that configuration on the 11th design... is it now broken? Or an analog part that you "program" by your selection of passives around it... if you need it to perform differently on that 11th design, does that render the part unusable?

No. You buy the same physical component, but you configure it differently for that 11th design. It's actually better than two different components because you enjoy the economy of scale that comes from buying a larger number of fewer different devices.

Not trying to pick a fight. There's no single correct answer here. If you don't want two programmed devices on the same PCB, it's your choice. But don't blame it on the second device not being a "fixed" part. You reconfigure parts you probably think of as fixed all the time (opamps, transistors, fixed digital logic, etc.) and a single-purpose MCU can be used in exactly the same way.

[nctnico]

Yes, it is possible to design a board with a second MCU, with code that doesnt need updating. You test it and it is very likely to work. And you make 5-10 designs with this concept, and the 11th time you need to update the second MCU....

That's only because you're still thinking of it as a programmable device.

You have to because it isn't thouroughly tested until is has over a million (yes: over a million!) hours in the field. I've been down this road and at some point a secundairy microcontroller will need a firmware update.

IMHO the best solution for the OP is to use an external ADC or use a mux. If that external ADC has some signal processing like amplifiers, filtering, etc it could actually help to safe a few parts.

[JPortici]

I've been down this road and at some point a secundairy microcontroller will need a firmware update.

Yup. If it's programmable a bug will be found at some point.
Of course the only reason i was considering this and the reason i was considering only a PIC16 is because it's so easy to implement a programmer in the main MCU

Needless to say dedicated parts are better in almost all senses..
- tried and tested (or at least we hope so)
- they usually have additional hardware dedicated for the task (opamps or PGA surely with better specs than those integrated in general purpose mcus)
albeit costing a lot more..

[IDEngineer]

Yup. If it's programmable a bug will be found at some point.

True of "fixed" parts too. It's why they publish errata sheets. Indeed, I was just reviewing some silicon bugs in a couple of Analog Devices parts so this is a very timely discussion for me.

Nothing is perfect. Not even "fixed" parts. There's nothing inherently more accurate about a design being done in hardware vs. a design being done in firmware. Both are subject to human error. My point is that, by presuming firmware is somehow inherently less reliable than silicon, you are possibly making your solution more expensive, more difficult, or otherwise less optimal than if you allowed yourself to consider the entire spectrum of choices. That said, it's your design and your decision... no one is faulting you for your preferences as long as you're choosing them with your eyes open!

[AndyC_772]

A timely example which has just cropped up...

I'm designing a board which may have an external module connected. The available modules have an accessible pin which is connected to either a resistor to GND, or a resistor to +3.3V, depending on the type of module. I need to measure the approximate resistor value, determine whether it's pulling high or low, and make that information available to the main CPU using the single spare channel I have on a digital isolator.

(The module being identified sits on the opposite side of an isolation barrier from the main CPU, so connections between the two are not free).

This can be easily done with a tiny PIC, running an endless loop along the following lines:

- drive the pin high via 10k and measure the voltage
- drive the pin low via 10k and measure the voltage
- generate and send a UART data stream containing the two raw ADC readings
- wait, say, 1 second, then go back and do it again, forever.

The "wisdom" being presented here implies that, because this device is a microcontroller, it "will" at some point need reprogramming. This means a boot loader, a more expensive PIC that's actually capable of incorporating one, at least one isolated channel in the reverse direction, and a significant amount of NRE.

The complexity of doing this far, far exceeds the complexity of the main function of the device.

I'm genuinely interested to hear of specific reasons why this device might be perceived as needing field updates.

[tszaboo]

You get bit errors in every 200th board, every 1000 transmission. The bit error means you blow up stuff. Should have used a CRC.

[Siwastaja]

When you use an IC, and encounter silicon bug in the field after 1 000 000 hours, you just recall your products (or replace under warranty when necessary), then behind the scenes, work tediously with the IC manufacturer, and, most likely, end up redesigning the damn board to use a different IC. Completely normal design incidence, not fun, but does happen.

When the same happens with a simple "fixed" MCU, you do the same warranty / recall thing, but instead of banging your head on the wall for weeks, you just fix your bug. Unless, of course, you can't find it, or it ends up being a reliability issue in the MCU itself, in which case we are back to banging head . Does happen as well.

So not much difference.

People automatically and directly judging MCUs more error prone than "ready ICs" only show they lack real design experience.

Of course, if you cannot do it, the options are that you either learn to do it, or don't do it that way. Both are sensible choices.

Sometimes ICs even from major manufacturers can be utter catastrophes, easily replaced with an MCU with a few lines of almost untested, but simple enough code being more reliable. Battery management ICs are a good example. Even if not buggy, they often implement totally wrong or dangerous algorithms. Although, I guess, to be more relevant to the OP's case, standalone ADCs will be better, and reliable too, if they just happen to suit the need. But if you cannot find a suitable one, then it's best to keep the MCU route open and evaluate it by case-by-case technical metrics instead of clearly wrong and obsolete "rules of thumb".

So yeah, if an MCU with a few simply verified lines of code happens to fit better in engineering terms (cost, availability, performance, design time, anything), it should be considered as an option, and it can be considered as a "one time programmable part", with the risk that you need to manually replace or reprogram them anyway, and it should be compared to the risk that you need rework / replacements using ICs or even discrete components as well!

Software is not the only part where you can end up with unexpected, untested state space. Unreliability by design mistakes can happen (and often does) even when designing passives, even the power PCB layout!! Even if reprogramming an MCU required a shipment from customer, and using a special connector jig to reprogram, it's still a lot easier than reworking circuitry by adding jump wires, desoldering and changing components, etc., which could be the alternative.

Calculate total cost and total risk by comparing solutions doing the same end result. Avoid complexity. Sometimes it means using a user-reflashable MCU; sometimes a "one time programmed MCU" as a component; sometimes an IC; sometimes a totally discrete design. All can fail in different ways.

[Siwastaja]

You get bit errors in every 200th board, every 1000 transmission. The bit error means you blow up stuff. Should have used a CRC.

Off-the-shelf IC (ADC, for example) does not use checksums. So now your MCU based solution with added checksums is more robust, and fixed an issue that would have existed with a dedicated IC!

Although, something is electrically catastrophically wrong if you have such high bit error rates.

Most often, on-board short communication links are considered to be perfect. Most ICs are designed on that principle, like it or not.

In reality, bit errors happen, but using MCUs is not related to that risk; in fact, it allows more robust design to be implemented than almost any off-the-shelf IC doing the same offers.

[AndyC_772]

You get bit errors in every 200th board, every 1000 transmission. The bit error means you blow up stuff. Should have used a CRC.

Those kinds of problems can happen in a digital design that has serious noise or timing issues, but what are the problems you think might occur which are specifically due to the use of a programmed device?

[tszaboo]

You get bit errors in every 200th board, every 1000 transmission. The bit error means you blow up stuff. Should have used a CRC.

Those kinds of problems can happen in a digital design that has serious noise or timing issues, but what are the problems you think might occur which are specifically due to the use of a programmed device?

Or on something, that got replaced by a supposedly compatible part. Which in reality isn't fully compatible. Like replacing an ADUM isolator with a Silicon Labs one one. They work in different principle, and they require different decoupling. But they are "just" a digital isolator, right.
I've seen exactly this happen BTW. Dont quote me on the bit error rate.

[Siwastaja]

In cases like those, an MCU can really save the day, since you can circumvent the actual problem (like by adding a checksum & retransmission); it's a hack, but keeps your product running while you investigate. In the end, you have both fixed the actual problem, and added the checksum, and have a far superior product.

Way too often, poorly designed ICs require a separate "controller MCU" just to circumvent some braindead logic or outright silicon bugs. In these cases, I'm happy that I have the programmable device there, and not just more ICs to do the job "easily".

If you look at anything before the "programmable device" era, but well into the "IC era", which is even slightly complex and not a made-in-millions mass market device, you almost always find a considerable number of PCB modifications and jump wires all around. These are fun little retro pieces of history, but they were expensive as hell, and often required orders of magnitude more maintenance than modern solutions often utilizing, for example, programmable parts.

[IDEngineer]

...modern solutions often utilizing, for example, programmable parts.

Might I gently suggest we use the term "configure", and its derivatives, in this thread. It might help some people get comfortable with the concept.

Some parts are configured in hardware, by tying certain pins high or low.

Some parts are configured in firmware, by programming.

Neither approach is universally better. Each has its place. But there is no inherent disadvantage to either one. In both cases, you are configuring a part to do what you want. Others may configure it differently.

And both approaches can be reworked... as you've noted, via cuts and jumpers in hardware, or altering the code in firmware. Either way, you're simply reconfiguring the part.