# Have microcontrollers replaced simpler ICs?

Is it still worthwhile to learn, for example, how to tune a 555 timer with resistors and capacitors, when you can write a timer program for a microcontroller in a human-readable programming language?

Or, to put it another way, are there problems that ICs are good for that microcontrollers are not?

• @jes5199 - I'm not quite sure how this question deserves a meta tag; can you comment on your rationale? – J. Polfer Jul 13 '10 at 11:57
• my notion was that I wasn't asking a question about a specific problem, but about the entire field. That seemed a little meta to me. – user955 Jul 14 '10 at 5:34
• A circuit board with discrete components and a chip labeled as a 555 timer is much more human readable than the program stored on a chip. – Kaz Jun 11 '14 at 22:11

Mostly, microcontrollers have replaced discrete ICs. I find that even if I could design a circuit with a 555, it's likely that the same circuit will need to be tweaked in a few weeks to do something else, and a micro preserves that flexibility.

But there are a few exceptions.

Discrete logic is still faster than most microcontrollers. The propagation delay and switching times for discrete logic are in the 1-10 ns range. To match that with a microcontroller, you have to be able to implement whatever logic you need in 1 instruction, and have a clock in the 100 MHz to 1 GHz range. You can do that, but maybe not on a breadboard in your garage.

A good example of this is the HCTL2020 quadrature decoder. It takes in two series of pulses and tells you which way your motor is spinning. It's implemented as a nonprogrammable chip for the sake of speed.

Another interesting area where both digital logic and and microcontrollers fail is in signal filtering. If you have an analog signal that you want to filter digitally, you have to sample it at some rate. No matter how fast you sample it, noise in the signal that appears at frequencies more than half your sampling frequency will get aliased down to lower frequencies, where it may interfere with your signal. You can solve this problem with a low-pass filter, made of a cap and a resistor, before your sampling occurs. After the sampling, you're screwed. (Of course, it's frequently the case that the noise won't overlap your signal in frequency, and then a digital filter will work great.)

• > Discrete logic is still faster than most microcontrollers. Unless you're using a Cypress PSoC3. – Rocketmagnet Jul 31 '10 at 22:16
• @Rocketmagnet - The PSoC, like an FPGA, is still raw logic. It's not discrete, sure, but it's just as fast. – Kevin Vermeer Mar 23 '11 at 0:58

Strangely enough, I just had one of our Chinese factories trying to add a micro to a project where it was totally overkill, and I told them to use a 555 instead. A 555 costs maybe 6 cents, vs a cheap microcontroller for 60 cents. When you're making products in large quantities, that cost difference is important, and you'll definitely want to know how to use the cheaper IC. So yeah, they're better at costing less. :)

• You may as well add reliability to that. Every software has one remaining bug after the last one was removed. – stevenvh Nov 27 '10 at 16:00

One area there discrete logic still beats out micros is long term part stability.

Is this micro going to be available in 10 years? 20? Will the IDE and toolchain still support it in that time?

You can pretty much guarantee that discrete logic will still be discrete logic in the future. Micros, not so much. If you're designing a product that you expect to have a long production life, generic logic, and as much as possible, generic parts will reduce the need to redesign the device when parts availability shifts.

Also, you're not SOL if your chip manufacturer is backordered. Many people make compatible generic logic, while there is basically no generic micro.

It's often that it will turn out cheaper to use discrete circuitry to do a simple task. For example, a flashing LED. The cheapest PIC, a PIC10F200, is about US $0.35 in 5ku, and that's before programming costs and taking into account the small size (and associated problems with manufacture.) An NE555 timer, on the other hand, can be picked up for about US$0.10 from TI in 5ku, and a complete solution would probably weigh in at around US $0.20. Another thing to take into account is that microcontrollers are inherently digital devices. Sure, most have ADCs and some even have DACs, but they still work on discrete units of time and work on individual bits and bytes. An analog circuit can be tuned precisely to do what the designer needs because in theory, analog has infinite resolution**. A digital circuit is limited by its slowest component. Finally, there is the issue of supply. Going back to my first example, the NE555. That has been around for more than 20 years and will probably be around for another 50 after this. It's such a jellybean part that it will probably be manufactured forever (or at least until conventional electrons become obsolete in electronics.) Whereas, a PIC10F could be made NRND at any time. With a single supplier like Microchip, there is a significant risk this could ruin a product. **Okay, this isn't quite true. In reality, we are limited to the resolution of electrons. 1 ampere = 6.24×1018 electrons/second. So the finest current resolution you can get is the attoampere, or 10^-18 amperes, which is about 6 electrons per second. But for most practical purposes, this is okay. :) • you're confusing resolution with precision, an often made error. There's no point in having >10 digits of resolution if drift causes effective precision to be only double digits. The digital solution may have a higher precision despite having a discrete and therefore more limited resolution. – stevenvh Aug 21 '11 at 11:11 I would class learning to tune a 555 timer as "just in case" knowledge. It's the same as people saying "I've lived my whole life just fine without algebra, why are we teaching it to kids?" If you don't know how to use a tool, you will never see a problem it can be applied to. As for a specific answer: very fast digital logic is implemented in FPGAs/ASICs nowadays because it would be too slow on a microcontroller/processor (unless it was a specifically designed processor like a DSP). Don't forget programmable logic - CPLDs and FPGAs. By replacing discrete logic with a CPLD you aren't affected by parts being discontinued and can get a lot more performance, reduced size and lower cost. If you have an FPGA in the system you can implement a soft core in it, that can easily be upgraded if requirements change, and the whole thing can easily be made "future-proof". In my current project we are using a Marvell ARM9 chip running at 500Mhz with an FPGA to offer many DIO ports. Still, there are things that are handled in discrete logic. For instance, a stepper motor control is needed for 4 stepper motors controlled individually. There is one oscillator to generate a frequency with a counter that will allow a number of pulses to go through. The counter is set from the microcontroller, but then operates without any further control from the microcontroller, giving it time to work on other tasks. We could have opted for more microcontrollers. But a central controller working with traditional discrete logic can prove to be a powerful and very reliable solution. Also, if you have a problem that is clearly defined, the solution should always be as simple as possible, but no simpler (quote hidden in there ;-) ). If a 555 works, why would you not use it? Flexibility might be an argument as someone else opted, but it might not be. It all depends on your problem and your interpretation of what the simplest solution is. • I would think your I/O expander FPGA would be a great place for the "logic" portion of a stepper control. – Chris Stratton Aug 21 '11 at 16:25 High frequency communication applications come to mind. Even though we now have 'software defined radio', it would be very surprising if 100MHz+ signal processing doesn't still have at least some analog stages. Very few of my recent microcontroller designs have required any discrete logic. An exception was implementing a Ctrl-Alt-Del type of reset whereby pressing two specific keys on a custom keyboard for two seconds would do a hard reset of the micro. I used a NOR gate (used as an AND gate with 2 inverted inputs), an AND gate, and a 74HC123. Was convenient to be able to get the specific gates I needed in single gates in a SMT package, instead of the 4 gates/package in the DIP days. I have had the chance of being a software developer for years and now work as an electronics engineer. Any system with complexity comes with erros and bugs. Both the microcontrollers and ICs have their advantages and disadvantages based on their areas of usauge. For small scale projects ICs are faster, cheaper and more reliable than Microcontrollers. For Large scale projects with millions of inputs, analysis and comparisions logics, for sure microcontrollers have the edge over ICs. All software fail at some point, even bugsless code is prone to modifications bacause it is saved on a ROM, resulting in logical errors (e.g., memory leaks) which are difficult to detect but sometime end in catastrophy. To bullet-proof software based systems from failures in critical applications (such as military grade or life saving systems such as train control systems), "fail safe" concepts are implemented and developed. Fail safe systems revert to a safe state in case an exceptional error occurs. Usually two processors run the same code, compare the results of each instruction, and if they are equal, the instruction is executed. Otherwise the system uses physical electrical relays to revert to a safe state. Fail safe software based systems are used in train Interlocking and ATPs (Automatic Train Protection) systems. Designing the same complex system with Ics is a great headache for any engineer. And that is why software was designed from day 1 ! ICs can be very domain specific. I'm thinking of a DTMF decoder. I could program a microcontroller to decode the two frequencies, but it's easier, faster, and cheaper to use an off-the-shelf chip. I think is it important to have enough knowledge of all the tools to know what tool to use. • Depends of course on whether you need a microcontroller in the circuit anyhow. I recently had a project where I needed a DMTF decoder. The chips cost about dollar in quantity. The difference in price between a PIC24F or an equivalent dsPIC33F (which also has a DSP) was also about a dollar in quantity. The DTMF decoder DSP routines were free from Microchip. Plus I now have a DSP for other stuff. – tcrosley Jul 13 '10 at 20:00 • FYI, I wrote a pretty good DTMF decoder for a PIC 16C622 a few years ago, using just the comparator as the input. – supercat Mar 23 '11 at 19:27 There is one big difference between designing something using only discrete components versus using a micro controller; software has bugs. If reliability is an important aspect, it is possible to verify the design of something made out of discrete components. Not even Knuth dares to claim that that his software is without errors. Of course, your design might have errors as well and they might only show up in very rare cases, but they will be simpler to understand and fix. It is possible for software to fail in extremely obscure and non-obvious ways, that you will never find. • Since discrete components in this case probably means ICs and not transistors, what makes you think ICs are without bugs? Well written software ends up with bugs not because it is software, but because it solves complicated requirements - a hard wired version could be buggy too. Once you have found a bug, it's rally cheaper to deploy fixes to software than it is to modify PCBs, unless you've had someone burn a large inventory of OTP micros for you. You can train someone to plug in a programmer cable and obey ESD rules a lot faster than you can train them to be good at reworking SMT PCB's. – Chris Stratton Aug 21 '11 at 16:31 • ICs exists in all kinds of complexity levels, including microcontrollers. The probability of errors in an IC is proportional to the complexity of the IC. The question was about simpler ICs like the 555 timer, and I think the the cumulative probability of such an IC and additional components to have errors is much lower than the probability of the microcontroller replacing them having errors. Of course if you replace 1000 components with one microcontroller, the odds will probably change, so the picture is not completely black and white. But for any LED blinking device or similar that I ... – hlovdal Aug 22 '11 at 2:18 • ... perceive this question to be about, I still believe that discrete components have the potential of being more reliable. And for software errors, they are non-deterministic. Of course nothing is 100% guaranteed, but if you implement a traffic light controller with components, you can verify it and deploy it, knowing that it will keep on working for X years until physical wear and tear make the unit likely to fail and replace it with a new unit well before that. There is no way you can estimate that software will work reliably for any time period. – hlovdal Aug 22 '11 at 2:18 • Software of comparable complexity to a few discretes can, on the appropriate cpu, be mathematically proven. Discrete logic of comparable complexity to more common software can't really be made entirely safe against the unimagined either - though often in either case you can use additional complexity to provide some backup safeties in case the primary mechanism does fail. – Chris Stratton Aug 22 '11 at 2:49 The answer is YES! You need to look at it as a hardware designer with production cost orientation. The 555 is an old IC that is considered very basic. If you're an EE most chances you've seen it several times in digital electronics classes. Setting it up is very easy as you need to solve 2 or 3 formulas for most common applications. This takes almost no time (since you already know the part and how to use it and the math is easy). The amount of time it would take to setup development for even an 8bit MCU and validate the software could take from days to months, depending on the environment you work in. So this might keep engineering costs down by amounts you won't imagine possible and also, possibly, shorten time to market. True story - I used to work for a huge medical company. I designed testing jigs for product validation. The jigs were part hardware and part embedded software based. The product the company makes interacts with vulnerable parts of the body so the amount of inspection everything we did went through was nuts. This one time, I had to adjust the communication protocol to reflect changes in the product itself. The change was perhaps 10 lines of code in C and the crystal oscillator was also swapped as the baud rate was altered and what was originally installed was not 11.0592MHz... It took me about 2 hours to get this done including documentation. The cost for the company was probably$300 or less with the order from Digikey for the new parts. The validation of the improved testing jig took several months (!) and kept about 3 or 4 people busy at least several times a day in related matters. How much this costs the company? Probably north of $10K -$15K. This cost reflects the true cost of the minor change in design. Many times you can save it and knowing some almost ready made solutions could save a small fortune.