At what point do you use an MCU over discrete parts? - Page 1
Forum section: electronics / general

author: Phaedrus
author_rank: Frequent Contributor
timestamp: July 21, 2014, 03:00:20 pm
content: So I've been working on a project which has a sub-section that raised an interesting question in my mind. At what point does the complexity of a circuit reach the point that you choose to use an MCU over an analog or discrete logic solution?In my case it's a sanity check for ATX power supplies. This device simply detects the PSU output voltages, and checks if they're within the mandatory +/-5% specification. If it passes, shine a green LED. If it fails, flash a red LED. Have a pair of LEDs for each of the four main voltages (ignoring -12V because no one cares).In my case I chose to use a pair of LM339 quad comparators, a TL431 voltage reference, a 555 timer to flash the LEDs, and a 74HC02 quad NOR gate for glue logic. In my estimation, this project is borderline to where it would be equally reasonable to use some Atmega or PIC chip instead and get the same functionality. I chose to use discrete parts because there's some sensitive analog stuff elsewhere on the board and I don't want to have to isolate the noise of an MCU. The discrete parts have some noise too, but the worst of it is the 555, and I have that right next to the 470uF input filter cap and a couple of bypass caps, so it should be ok.Basically, I guess I'm asking at what level of complexity do you switch from discrete to microcontroller solutions?

author: chibiace
author_rank: Regular Contributor
timestamp: July 21, 2014, 03:06:09 pm
content: probably comes down to cost and the cost being circuit size (pcb area), price of ICs with the features you need and the support chips like voltage regulators and then you have flexibility with being able to reprogram some of the functionality

author: AndyC_772
author_rank: Super Contributor
timestamp: July 21, 2014, 03:16:36 pm
content: I'd use a PIC12 series device for that. You'll find some of the smallest PICs actually have quite an accurate voltage reference built in, much more so than the larger ones whose voltage references have such wide tolerance as to be all but useless.I have no idea what noise you're referring to from an MCU, though - especially compared to the noise you'll get from an ATX power supply. Lay the board out and decouple it properly, and I'll be quite surprised if you can tell that the MCU is switched on at all.

author: XOIIO
author_rank: Super Contributor
timestamp: July 21, 2014, 03:18:59 pm
content: Not having read the post or replies really, I would say it comes down to cost effectiveness, and the amount of real estate you have available.

author: pickle9000
author_rank: Super Contributor
timestamp: July 21, 2014, 03:48:02 pm
content: Cost and remember that's not just the component cost, pcb footprint, size, future needs / changes. Development time counts as well but is minor in a volume production run.

author: IanJ
author_rank: Unknown
timestamp: July 21, 2014, 04:16:14 pm
content: Hi,In my past, decisions over whether to go to an MCU also came down to what existing MCU design did we have that was already close to what we want now.....and thats the software as well as the hardware, i.e. development time.Also, what flexibility in the design do we want, i.e. depending on the design it's likely easier to adapt a design in software later on if tweaks are necessary.Ian.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 21, 2014, 04:55:51 pm
content: You're forgetting reliability: ALL software is buggy, 100% of the time. Only the most trivial cases (such as the present example, perhaps?) arepotentiallyprovably correct. And programmers have an odd habit of making simple cases difficult to prove.It's not a matter of if it fails, but when.You can try doing extensive software reviews, but human eyes constantly miss things, you're never going to find them all.Watchdog timers offer the guarantee of operation, at some point, but suffer the problem of constant resets -- the nice thing about software is, as long as it's deterministic, it's guaranteed to produce the same result (crashing, say) from the same set of inputs, so on that occasion when the ambient temperature is juuuust right... the LEDs blink themselves because the processor is constantly in reset! And if you're doing a real time process, you must somehow guarantee that the WDT resets don't upset more circuitry (e.g., turning on all channels at once in a motor driver), which incurs even more protection hardware, just to protect the system from that damn MCU.I would much rather have all of that under strict hardware control, so it is the least likely to fail, then control the process inputs (like motor RPM) from an MCU. That way, all the hardware protections are still in place (e.g., overspin, torque limit, etc.), and if the MCU goes off into la-la land, the most likely problem is, the variable just hangs, so it just keeps on spinning, at a speed that the user presumably was already okay with (if not necessarily for so long). And maybe we can detect the WDT signal and disable things anyway, so it all shuts down safely until we get a bug report off to the software guys.Now, in the present case, since you're just blinking LEDs, I mean, what are the chances that a human is even looking at them most of the time? And if they're indicating wrong, the user might have some indication (inconsistent LEDs?), and still be able to operate the equipment safely (e.g., get out a DMM and manually verify if the rails are correct).And don't forget the edge cases: the biggest steaming trap that software faces! What happens on the 4.99% case, does it just twitter on and off or is there hysteresis? And the time dependency: comparators are fast, under a microsecond, whereas an MCU has to sample (>10us), process (1-100us++ depending on arithmetic and language level?), signal (0.1us-1ms?!), and repeat (latency varies from 1us to ...ms?!).Indicator lights may be just fine -- but what if, somewhere down the road, you'd like to take that handy LED signal, and use it on a circuit that's rather power sensitive, so it can shut down if things get too nasty? You're almost guaranteed to blow it first time if it's behind a microcontroller! You may have some hope if it's analog, but an even tighter protection loop (like a crowbar and fuse) is the most secure way to prevent that kind of thing.This is a rather trite example, but the fact remains, hardware tends to be more reliable than software, probably because the state space is generally continuous: if there are regions of failure in that system, chances are, normal operating tests would have explored points near enough to those boundaries to have discovered them (the most common examples being thermal, due to elevated ambient or unexpected loading conditions, resulting in overheated transistors or capacitors).The state space of software, however, is potentially vast, and extremely nonlinear, so that failures might be sparse and random within the memory space. Even on an MCU with merely 1kB SRAM, how could you ever verify that all 2^8192 states (plus CPU and IO register contents!) will return to the normal operating condition?It is possible to write safe code. Good code is a good start.Before sitting down and pounding something out, consider carefully the algorithms and data flow you need to accomplish your goal. Start on the highest level, then begin implementing it (top-down design). Document the design structure in comments as you go.Minimize memory use. Not to be miserly, and certainly not to the point of packing bits together -- anything that adds more code and logic is only going to add more problems -- but things like storing multiple copies of variables, which can become inconsistent over time, should be avoided. If you must do it, justify it with a very good reason (e.g., atomic copies of variables for interprocess communication). Document this in comments as well.Avoid recursion, indefinite loops (except the main loop, of course), memory management (malloc), and C's fucking zero-terminated strings, if at all possible: these are some of the most offensive, error-prone anti-patterns that continue to plague software to this day! Not that they can't also be used responsibly (and not that there's a good substitute for general purposes), but they should be avoidable in embedded applications (it's not like you have much memory to allocate, anyway).Understand your language as well as you can! C is a morass of pitfalls. Unconstrained pointer redirection (and typecasting). Zero terminated strings. (Well what the hell happens if my string is supposed to contain a NUL?) Fixed buffer lengths. Buffer overruns. No array / buffer / object bounds checking. Allocating memory that's unavailable (always check the return status!); not deallocating it when it's free (memory leak); reusing stale pointers. The list goes on and on, and these are all rookie mistakes that are well documented and well represented in the mess of very visible bugs in all software. Above all, mind that C is an (occasionally convenient) preprocessor for assembly: if you want to work in assembly, you can, it's right there for you: asm()! As such, C cares not for objects, bounds, or code/data distinction. (C inherently assumes a Von Neumann architecture. You can use a function as an array, and vice versa, and that's perfectly legitimate. That there are even compilers for Harvard architectures (AVR, various DSPs, not to mention the strange thing that is PIC) is strange indeed.) C is a recursive language, meaning, each time you call a function, the return pointer, plus the function's local variables, are placed on the stack: and if you have a limited stack size, plus main fields, plus recursion, you're going to find bizarre problems in no time flat. C never checks for stack position, so you can happily fill the entire memory space with function calls, until, as each of those functions returns back, they have more and more gibberish to return to. Oops.... And all of this is just to say a little about software. It's nice to think hardware is perfect.....often it's NOT! (Microchip, anyone?) Cores can crash from otherwise normal activity. Peripherals can be poorly or incorrectly made (let alone documented -- read the errata!). There are "hi-rel" devices available, implementing aerospace grade measures: for example, two cores in lock-step with a third monitoring the outcome (and handling exceptions). Needless to say, only the most pristine codebase is going to be used on such expensive platforms, with a complete paper trail from customer specification to final implementation. Software (and hardware, especially complex digital hardware) is so typically buggy that people do go to these lengths to attempt to mitigate it!Tim

author: bwat
author_rank: Frequent Contributor
timestamp: July 21, 2014, 05:14:41 pm
content: Quote from: T3sl4co1l on July 21, 2014, 04:55:51 pmNo no no. Top-down analysis, bottom-up synthesis. It's the fundamental "algorithm for problem solving". See Kowalski's"Logic for Problem Solving".Quote from: T3sl4co1l on July 21, 2014, 04:55:51 pmI've written plenty of recursive functions with a guaranteed upper bound on stack usage (and we're not even talking about taking advantage of tail-call optimisation either). It's easy to do when you can set an upper bound (*) on your inputs and the code is easier to work with when it comes to correctness proofs. To say what you've said tells me that you maybe are more of a hardware type than software type.*) this dimensioning work is a good thing to do in any case.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 21, 2014, 05:45:49 pm
content: Quote from: bwat on July 21, 2014, 05:14:41 pm^ That's what I meant to say.Works the same in hardware design, too; lay out the overall constraints, block diagram, whatever; build up the implementation, meet in the middle.QuoteAllow me one correction:Avoid naive recursion.Or, to put more emphasis on the proving part: if you can prove it, and it fits within bounds, you're golden. If you can't perform that step, better to avoid the problem.To say what you're said tells me that you maybe are more of the smart software type than a mere script kiddie.Or... do what this guy says ^And yes, I'm certainly more of a hardware person -- I'm good at software, but I don't like doing it. So, take this also through the silicon-colored glasses* of my experience. Of the bad hardware I've seen, usually it's still functional, but prone to gross thermal or mechanical failure; of the bad software I've seen, well, sky's the limit...*They're very opaque, but great for reading at thermal IR!?Tim

author: bwat
author_rank: Frequent Contributor
timestamp: July 21, 2014, 06:06:46 pm
content: Quote from: T3sl4co1l on July 21, 2014, 05:45:49 pmPhew!Quote from: T3sl4co1l on July 21, 2014, 05:45:49 pmI've been very surprised at just how well the bottom up implementation works in digital design. There's a lot of programmers out there that could do with a good course on digital design to learn how to build stuff (get the blocks working and tested, then use them to build other blocks, test them, then use them to ....)Quote from: T3sl4co1l on July 21, 2014, 04:55:51 pmGood, you're not anti-recursion. I've met those types.Quote from: T3sl4co1l on July 21, 2014, 05:45:49 pmI'm supposed to be the smart software type but I have my days.Quote from: T3sl4co1l on July 21, 2014, 05:45:49 pmAnd mature enough to take my light hearted jibe in the manner it was intended.Quote from: T3sl4co1l on July 21, 2014, 05:45:49 pmI agree. In my experience as an OS developer (low-level bootstrap loaders, device drivers etc.) and up until the advent of SoC boards (usually a well built core CPU with dirt cheap/half tested IP blocks surrounding it) I used to think that one day software would be as reliable as hardware. It seems the hardware people are starting to act like software people. *head shake*

author: grumpydoc
author_rank: Super Contributor
timestamp: July 21, 2014, 09:23:23 pm
content: QuoteYou switch to using a design which explicitly stores the length and use the mem* library routines rather than the str* ones (i.e memcpy rather than strcpy etc). It's a bit more work sometimes - but can be more efficient.C as a language does not require '\0' terminated strings although the fact that you get one for free on the end of string constants does mean that an awful lot of APIs have been designed around them.

author: Richard Crowley
author_rank: Super Contributor
timestamp: July 21, 2014, 09:39:42 pm
content: There is also the development cost (time/$$$). If you are doing a one-off, the bottom line may be better off with discrete analog component design vs. fooling around with a micro-controller.

author: Precipice
author_rank: Frequent Contributor
timestamp: July 21, 2014, 09:42:55 pm
content: Although it's more likely you've got an eval board with a suitable micro on it stuffed in a drawer somewhere, than an eval board with suitable analogue stuff, in my experience. (Other places may vary!)

author: ovnr
author_rank: Frequent Contributor
timestamp: July 21, 2014, 09:50:26 pm
content: Well, in my case: Whenever you start requiring anything that can't be solved with a couple logic gates or a single package (comparators, opamps, etc).In your case, you could stuff all the functionality you wanted into a single 8-pin micro, as opposed to a heap of comparators, a voltage reference, 555, etc. Since you only want to test if something fits inside a +-5% margin, you can generally get away with using the built-in reference too.As for "software is always buggy and takes time": Sure. But if you're only trying to replace something which can be done in discrete logic and analog cruft, chances are your software isn't terribly complicated either! And analog stuff takes time too.

author: free_electron
author_rank: Super Contributor
timestamp: July 21, 2014, 10:05:23 pm
content: micro's. tss. integrated circuits .. tss.. a circuit this simple should be made with vacuum tubes !

author: cosmos
author_rank: Regular Contributor
timestamp: July 21, 2014, 10:15:37 pm
content: my point was here apparently (in case you want an example):https://www.eevblog.com/forum/testgear/how-is-fan-noise-on-a-ds4000-compared-to-a-ds2000/?action=dlattach;attach=75682;image;(integrated temp sensor and fan control, for my Rigol DS4k that thought it was a 747 ready to go)https://www.eevblog.com/forum/testgear/how-is-fan-noise-on-a-ds4000-compared-to-a-ds2000/msg364738/#msg364738

author: nctnico
author_rank: Super Contributor
timestamp: July 21, 2014, 10:18:53 pm
content: Quote from: Richard Crowley on July 21, 2014, 09:39:42 pmThat depends entirely of the problem. Last year I made a temperature controlled fan. It turned out it was much easier to get the desired functionality using a small microcontroller with zero-cross detection than mucking around with an NTC, resistors and capacitors to control a triac.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 22, 2014, 08:34:03 pm
content: Not that I'm any kind of authority, but here's my threshold:When the number of components exceeds by a fair margin the BOM for a microprocessor-based solution, and/or the layout becomes problematic due to having to get from A to B to C to D with multiple signals, then it's time to look at the micro instead. Also, or particularly, if the behavior of that circuit might need to change at some point. Far easier when the inputs and outputs are fixed and the logic is all in software.This is becoming more common now that micros can be had for $1 or less in single quantities, while discrete logic ICs are easily $0.40 apiece and you'll need a few to do the job. It gets hard to justify the cost and board space even if it seems like a waste of hardware to dedicate a micro to some benign task.However... if the penalty for software problems (bugs and latency in particular) is substantial, then I'll opt for discrete components. OCP, OVP, thermal management, power sequencing, or bootstrapping circuits -- these things I'll prefer to do in hardware. At the very least, there should be a hardware fail-safe.