When Steve Leibson, editor in chief of EDN, asked me to write a monthly column on embedded-system-hardware issues, I told him I wasn't sure I had enough to say to fill 2000 words a dozen times a year. Besides, this business changes so fast that all of us are constantly on the verge of becoming technological dinosaurs. Still, some basics of engineering never change, so I agreed to try and pound out a few pearls of wisdom each month.
I've been fortunate in being part of the µP revolution almost from the start. My first job as a (very) junior engineer was the design of 8008-based systems. In only a couple of decades, this industry has mushroomed from tiny em- bedded systems with 0.05-MIPS CPUs running 2k programs, to today's inexpensive 50-MIPS+ designs with mil- lions of lines of code. It's amazing and breathtaking to see how far we've come in so little time.
While the popular press loves to babble on about the information society, focusing on the widespread availability of cheap PCs that look like computers to a nonengineer, I suspect that history will show the true revolution in the late 20th century occurred with the introduction of embedded µPs into every bit of our lives. If we could hear the collective hum of all µPs presently computing, we would be overwhelmed by this new paradigm of society.
It's a tragedy that the majority of humankind has no understanding of how their lives are subtly enhanced by the embedded µP. Instead, most people fret and fume if the ATM machine takes an extra second to dispense cash (or issue that oh-so-dreaded "insufficient funds" message), yet few understand that the machine is verifying the card, communicating with mainframes at Visa Central, debiting accounts, and electronically adjusting balances at banks all over the country, just to drop some pocket money into someone's impatient hands.
This lack of understanding creates widespread misconceptions about the nature of the computer industry. Eight-bit designers get no respect. After all, it's a 32/64-bit RISC/SPARC/DSP high-end 100-MIPs world--ain't it?
Well, no, it ain't. High-end CPUs account for just a fraction of the entire computer business. The tens of millions of 386 and up processors shipped are practically an insignificant blip compared with the five billion processors sold each year--most of which are 4- or 8-bit machines, and virtually all of which are buried inside millions of embedded systems.
Even in technical publications, fast and powerful processors get the glory, just as fast cars and flashy clothes get all of the attention in the popular press. And, just as Hollywood's favorites garner the majority of attention from the press while we, the less charismatic and less beautiful people, carry on the real work of society, so do little CPUs shoulder most of the computational burden of the world.
Similarly, although we read of vast team-design efforts and the thousands of people involved in coding big weapon systems or the latest Lotus masterpiece, I believe that most embedded systems are born of solitary designers or programmers working with just a few colleagues.
Unfortunately too many solo designers feel out of the mainstream of engineering, since the press focuses almost exclusively on the huge projects. Take heart, ye clever inventors changing the world! You are not working on obsolete technology just because your processor is a Z8 or 6805. Your tiny project team is not a throwback to the days of yore. Don't be lulled into thinking you are out of the mainstream.
I talk daily to dozens of design engineers in all corners of the globe. It seems the happiest are those working on smaller projects and in small groups, where their impact is immediately felt. Based on this information, I make the following disclaimer: since 4-, 8-, and 16-bit systems are just as important, and a lot more fun, than the minuscule high end of the market, this column will focus mainly on these sorts of systems.
Clock problems
I see a lot of embedded systems in my travels and get to take an under-the-hood look at most of these systems. Many are wonderfully de- signed; some are not. One persistent problem I see is a total disregard for data sheets.
For a number of years, embedded systems lived in a wonderful era of compatibility. Just about all of the signals on any logic board were relatively slow and generally TTL compatible. This lulled designers into a feeling of security, until far too many of us started throwing digital ICs together without considering their electrical characteristics. If one is 2.4V and a zero 0.7, if we obey simple fan-out rules, and as long as speeds are under 10 MHz or so, this casual design philosophy works well. Unfortunately, today's systems are not so benign.
Few µPs, in fact, have ever exclusively used TTL levels. Surprise! Pull out a data sheet on virtually any µP and look at the electrical-specs page--you know, the section without coffee spills or solder stains. Skip over those 300 tattered pages about programming internal peripherals, bypass the pizza-smeared pinout section, and really look at those one or two pristine pages of dc specifications.
Most CPUs accept TTL-level data and control inputs. Few CPUs are happy with TTL on the clock and/or reset inputs. Each chip has different requirements, but in a quick look through the data books, I came up with the following:
In other words, connect your clock and maybe reset to a normal TTL driver, and the CPU is out of spec. The really bad news is that these chips are manufactured to behave far better than the specs, so they'll often run fine despite illegal inputs. If only they failed immediately on any violation of specifications. Then we'd find these elusive problems in the lab, long before shipping 1000 units into the field.
Fully 75% of the systems I see that use a clock oscillator (rather than a crystal) violate the clock-minimum, high-voltage requirement. It's scary to think we're building a civilization around embedded systems that may well be largely misdesigned.
If you drive your processor's clock with the output of a gate or flip-flop, be sure to use a device with true CMOS voltage levels. 74HCT is a good choice. Don't even consider using 74LS without at least a heavy-duty, pull-up resistor.
Those little, silver 14-pin cans containing a complete oscillator are a good choice--if you read the data sheet first. Many cans provide TTL levels only. I'm not trying to be an alarmist here, but look in the latest DigiKey catalog--they sell dozens of varieties of CMOS and TTL parts.
Clocks must be clean; noise will cause all sorts of grief on this most important signal. It's natural to want to use a Thevenin termination to more or less match impedance on a clock routed over a long pc-board trace or even offboard. Beware! Thevenin terminations (typically a 220 Ohm resistor to +5 and a 270 to ground) will convert your carefully crafted CMOS level to TTL. Use series damping resistors to reduce the edge rate if noise is a problem. A pull-up resistor might help with matching impedance if the power supply has a low impedance (as it should).
A better solution is to use clock-shaping logic near the processor itself. If the clock is generated a long way away, use a CMOS-hysteresis circuit (like a 74HCT14) to clean it up. The extra logic adds delay, though. If your system requires clock synchronization, then use a special low-skew clock driver made for that purpose.
In slower systems--under 20 MHz or so--I prefer to design circuits that don't depend on a synchronous clock. What happens if you change to a second-sourced processor with slightly different timing? Keep lots of margin to prevent this from happening.
Never drive a critical signal like clock offboard without buffering it. There are a very few absolutely critical signals in any system that must be noise-free. Examine your design, determine what these signals are, and take appropriate steps. Clock, of course, is the first that comes to mind. Another is ALE (Address Latch Enable), used on processors with a multiplexed address/data bus. A tiny bit of noise on ALE can cause your address register to latch in the middle of a data cycle, driving an incorrect address to the memories.
Check the timing
OK, so now your voltage levels are right. Go back to the data sheet and make sure the clock's timing is in spec. The 8088 requires a 33%-clock duty cycle. Sure, it's a little odd, but this is a fundamental rule of nature to 8088 designers. Other chips have tight duty-cycle requirements as well.
Rise and fall times, though difficult to design for, are just as important. Some chips have minimum rise/fall time requirements. It's awfully hard to predict the rise/fall time for a track routed all over the board. That's one attraction of µPs with a clock-out signal. Provide a decent clock input to the chip, connect nothing to this line other than the processor, and then drive clock out all over the board.
Motorola's 68HC16 pulls a really neat trick: You can use a 32,768-Hz standard watch crystal to clock the device. An internal PLL multiplies this to 16 MHz and drives a clock output to feed to the rest of the board. This gets around many of the clock problems and gives a "free" accurate, time-of-day clock source.
The processor's reset input is another source of trouble. Like clock, some processors have unusual input-voltage requirements for reset. Be wary. Other chips require synchronous circuits. The old Z280 had a very odd timing spec, clearly spelled out in the documentation, which everyone ignored, only to find massive troubles getting the CPU to start. I think every Z280 design suffered from this particular ill at one time or another.
Sometimes slew rate is also an issue. The old RC-startup circuit generates a long ramp that some processors cannot tolerate. You might want to feed it into a circuit with hysteresis, like a Schmitt trigger, to clean up the ramp.
The more complex CPUs require a long time to stabilize their internal logic after power-up. Reset cannot be unasserted until this interval goes by. Further complicating this is the ramp-up time of the system power supply, because the CPU will not start its power-up sequence until the supply is at some predefined level. The 386, for example, requires 219clock cycles if the self-test is initiated before it is ready to run.
Think about it. In a 386 system, four events are happening at once: The power supply is coming up, the CPU is starting its internal power-up sequence, the clock chip is still stabilizing, and the reset circuit is getting ready to unassert reset. How do you guarantee that everything happens to spec?
The solution is a long time delay on reset, using a circuit that doesn't start timing out until the power supply is stable. Motorola, Dallas Semiconductor, and others sell wonderful reset devices that clamp until the supply hits 4.5V or so. Use these in conjunction with a long time constant so the processor, power supply, and clocks are all stable before reset is released.
When Intel released the 188XL, it subtly changed the timing requirements of reset from that of the 188. Many embedded systems didn't function with this "compatible" part simply because they weren't compliant with the new chip's reset spec. The easy solution is a 3-pin reset clamp.
The moral
Always read the data sheets and don't skip over the electrical specifi-cations with a mighty yawn. These details make the difference be-tween a reliable production product and a life of chasing myster-ious failures.
If you've read many annual re- ports from publicly held companies, you know that the real description of each company's situation is contained in the notes. This is just as true in a chip's data sheet. It seems no one specifies sink and source current for a µP's output, but the specifiction of the device's VOLand VOHwill always reference a note that gives the test condition. This is generally a safe maximum rating.
Despite our apparently digital world, the harsh reality is that every component we use pushes electrons around. Electrical specifications are every bit as important to us as they are to an analog designer. Ignore those that would have you believe that designing an embedded system is nothing more than slapping logic blocks together.
