Sssh! Listen to the hum. That's the sound of the incessant information processing that subtly surrounds us, which keeps us warm, washes our clothes, cycles water to the lawn, and generally makes life a little more tolerable. It's so quiet and keeps such a low profile that even embedded designers forget how much data processing dominates our lives. Sure, we rail at the banks' mainframes for messing up a credit report while the fridge kicks into auto-defrost and the microwave spits out another meal.

The average house has some 40 to 50 µPs embedded into appliances. There's neither central control nor networking: Each quietly goes about its business, ably taking care of just one little function-distributed processing at its best.

Billions and billions of 4- to 16-bit µPs find their way into our lives every year, yet we hear primarily about the 10s of millions that reside on our desktops. The market for RISC and high-end CISC is a 0% market by comparison, yet this 0% market gets all the glory.

Now, I'll never give up that 1-zillion-MIPS little beauty I'm hunched over at the moment. We all crave more horsepower to handle Microsoft's latest cycle-consuming application. I'm just getting tired of 32-bit hype for embedded applications. Perhaps that 747 display controller or laser printer needs the power. Surely, though, most applications do not.

Derivatives of some of the earliest embedded CPUs still dominate the market. Motorola's 6805 is a scaled-up 6800 that competed with the 8080 back in the embedded Dark Ages. The 8051 and its variants are based on the almost-20-year-old 8048. The 8051s, in particular, have been the glue of this industry, corresponding to the analog world's old 741 op amp or the 555 timer. You find them everywhere. Their price, availability, and onboard EPROM make them the natural choice for applications ranging from those requiring just a hint of computing power to fairly substantial controllers with limited user interfaces.

I'm fascinated with Microchip's PIC16/17 processors, which seem to be squeezing into a lot of low-end applications. These are cool parts. The smaller members of the family offer minimal computational capability, which is ideal for simple, cost-sensitive systems. Higher end versions are well-suited for more complicated control applications.

Designers view these CPUs as something other than computers. "Oh yeah, we tossed in a couple of PIC16s to handle the microswitches," the engineer relates, as if the part were nothing more than a PAL. This is a bit different from the look you get from the haggard designer trying to ship a 68030-based controller. The microcontroller is easy to use simply because it is stuffed into easy applications.

LA Gear sells sneakers that blink an LED when you walk. A PIC16C5x powers these for months or years without the need to replace the battery. Scientists tag animals in the wild with expendable subcutaneous tracking devices powered by these parts. Household appliances also depend on PIC variants.

A friend developing instruments based on a 32-bit CPU discovered that his PLDs don't always properly recover from brownout conditions. He stuffed a $2 Microchip controller onto the board to sequence the PLD's reset signals properly, ensuring recovery from low-voltage spikes. The part costs virtually nothing, requires no more than a handful of lines of code, and occupies the board space of a small DIP. Though it may seem weird to use a full computer for this trivial function, it's cheaper than a PAL.

It's not that there's anything wrong with PALs: Nothing is faster or better at handling complex combinatorial logic. Modern super-fast versions are cheap ($12 in singles for a 7-nsec 22V10), easy-to-use, and reprogrammable-a great savior of designs that aren't quite right. PALs, though, are terrible at handling anything other than simple sequential logic. They have a limited number of registers and clocking options, meaning you can't use them for complicated decision making. PLDs are better, but when speed is not critical, a computer chip might be the simplest way to go.

As the industry matures, many parts we depend on become obsolete. One acquaintance found the UART on which his company depended was no longer available. He built a replacement in a PIC16C74, which was pin-compatible with the original UART, saving the company expensive re-designs.

Part of Microchip's success comes from the aggressive use of one-time-programmable (OTP) memory in all of the company's processors. Motorola and others make good use of OTP as well. Now, a number of programmable PLDs are also available in OTP versions. It's a sure bet that this technology will become ever more important in the future.

OTP memory is simply good, old-fashioned EPROM but without an erasure window. That small quartz opening typical of EPROMs and many PLDs is expensive to manufacture. You can program the memory on any conventional device programmer, but, because OTP lacks a window, you can never erase the memory. When it's time to change the code, you toss the part out.

Many years ago, Intel sold OTP versions of EPROMs, but they never caught on. A system that uses discrete-memory devices, such as RAM and ROM, has intrinsically higher costs than those based on a microcontroller. In a system with $100 worth of parts, using erasable EPROMs, which are very forgiving of mistakes, will cost only $1 or $2 extra.

The dynamics are a bit different with a minimal system. If a $2 part contains an entire computer, adding a $1 window is a huge cost hit. OTP starts to make sense, assuming your code is stable.can be cast in concrete in small applications because the entire program might require only 10s to 100s of statements. I plead guilty to causing one or two disasters seeming to have more bugs than lines of code. However, once you debug and thoroughly test a 10- to 100-statement program, it holds little chance of containing an obscure bug. In this case, going with OTP invokes little risk.

You can't pick up a magazine without reading about time to market. Managers want to shrink development times to zero. One obvious solution is to replace masked ROMs with their OTP equivalents because producing a processor with the code permanently engraved in a metalization layer takes months and suffers from the same risk factors as does OTP. The masked part might be a bit cheaper in high volumes, but this price advantage doesn't help much if you can't ship while waiting for parts to arrive.

Part of the art of managing a business is to preserve your options as long as possible. Stuff happens. You can't predict everything. Given options, you have the flexibility to adapt to problems and changing markets, even at the last minute. For example, some companies ship multiple versions of a product, differing only in the code. An OTP part lets them make a last-minute decision on the production floor, about how many of a particular widget to build. If you have $500,000 tied up in inventory of masked parts, your options are awfully limited.

Part of the 8051's success came from the wide variety of parts available. You could get EPROM or masked versions of the same part. Low-volume applications always took advantage of the EPROM version. OTP significantly reduces the costs of the parts, even when you are building only a handful.

Are tools necessary?

Microcontrollers pose special challenges for designers. Because nothing more than I/O pins bind a typical part, it's hard to see what's going on inside. Nohau, Metalink, and others make it their business to produce tools to peer inside these devices, giving the user a "window" into a usually closed system.

Now, though, as the price of controllers slides toward zero and, hence, only truly minimal applications use the devices, more people get by without any sort of tools. Although it's hard to condone shortchanging efficiency to save a few dollars, it's equally hard to argue that a 50-line program needs much help. You can probably eyeball it to perfection on the first or second iteration. Again, "appropriate technology" is the watchword. A 5000-line assembly-language program on a 6805 will force you to buy decent debuggers and, I hope, a C compiler.

You can often bring up a microcontroller-based design without a logic analyzer, because there's no bus to watch. Some people even replace the scope with nothing more than a logic probe.

An army of tool vendors supplies low-cost tools to handle the problems that microcontrollers pose. Using any controller gives you far more options than would embedding a SPARC processor into your system. Some companies cater especially to the low end. Most do a great job, despite the low cost. I recently looked at Byte Craft's array of compilers for microcontrollers from Microchip, Motorola, and National. Despite the limited address spaces of some of these parts, a decent C compiler can produce efficient code for them.

Working in a shop that mostly uses midrange processors, I'm amazed at the amount of fancy equipment on which we rely and am sometimes a bit wistful for those days of operating out of a garage with not much more than a soldering iron, a logic probe, and a thinking cap. Clearly, the vibrant action in the controller market means that even small, undercapitalized-or uncapitalized-businesses still can introduce competitive products.