Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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?
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.)
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. :)
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. :)
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.
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.
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.
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.