Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at ed.nisleyieee.org with "Dr Dobbs" in the subject to avoid spam filters.
Once upon a time, not quite two decades ago, I designed a little microcontroller-based embedded system that performed a useful function. Exactly what it did and how I implemented it aren't relevant here, except that the design seemed a fairly obvious way to accomplish the project's goals. It was fun and interesting and we even wrote it up in a now-long-dead magazine. I got paid and life moved on.
Recently, an e-mail arrived from an engineer who desperately needed to know exactly when I'd done that design. It seems that I have the dubious distinction of being The Prior Artist in a patent shootout over a device that some consumers actually use.
In retrospect, if I'd had any sense, I would have patented the notion, carefully licensed my IP, and made a bundle. More exactly, the folks who hired me would have made the bundle, as they'd surely have retained control of the revenue stream. Maybe I'd have gotten royalties in lieu of real money, maybe I'd have just gotten paid anyway. It's hard to tell about these things.
On a larger scale, the best outcome of the SCO-versus-Everybody legal wrangling has been the heightened awareness of Other People's Stuff in all our works. Be it concepts, code, or circuitry, keeping track of what you have and where it came from has suddenly become a much more important part of the whole design process.
Let's put this in perspective by taking a look at the invisible end of embedded systems, the projects that don't use much in the way of Other People's Anything. In fact, embedded programming on small microcontrollers is the last bastion of personal programming: Yes, one person can understand and write an entire program!
Lost in the Roundoff
Some web rummaging produced the precis of a spendy 1999 report on the market share of various microcontrollers (http://www.mindbranch.com/listing/ product/R97-498.html). You'd think they'd discount a four-year-old report on a field defined by Moore's Law, but noooo. We're just now emerging from a tech sector implosion, so the values aren't all that far off.
Back in 1999, the overall semiconductor market was $149 billion (that's 149×109) with 4.5 billion microcontrollers accounting for $9.9 billion of that. Quick division shows that the average microcontroller costs just over two bucks, although the report notes that there's a 4-to-1 spread in the prices for similar units from different manufacturers.
About 1 billion 4-bit microcontrollers left the loading docks, 16- and 32-bit chips accounted for 580 million units, and the remaining 3 billion units were trusty 8-bit microcontrollers. The report observes that market share for 4-bit units was falling, 8-bitters were holding their own, and the bigger units were growing. The most likely trend was 4-bit applications migrating to 8-bit microcontrollers, with new growth in the wider units.
Although it's possible to run UNIX-oid operating systems on 16-bit microcontrollers (remember Xenix?), for all practical purposes UNIX requires a 32-bit datapath. Let's suppose, for the sake of argument, that 32-bit microcontrollers constitute half of the "16- and 32-bit" category, with a total volume of 250 million units. That's surely an overestimate, as the automotive industry runs its engines on 16-bit engine controllers with savagely hard-real-time constraints.
In round numbers, then, UNIX-capable microcontroller systems amount to at most 5 percent of the total market. Given the other operating systems, I suspect that Linux runs in, at most, 2 percent of all embedded microcontrollers.
That figure doesn't get a lot of airtime, now, does it?
Small and Smaller
The Microchip PIC12C508A is typical of the low end of the 8-bit microcontroller domain. It's an 8-pin integrated circuit with six pins available for input and output functions; unavoidably, the remaining two pins power the chip. Your program must have no more than 512 12-bit instructions, use no more than 25 bytes of RAM, and have no more than two nested CALLs.
That's not a misprint: It really has only 512 words of instruction storage, 25 bytes of RAM, and a two-level stack. There's not much room for your own program, let alone Other People's Code.
In round numbers, the PIC12C508A costs $1 in several-thousand-part lots and less if you buy more. That's half the price of the average microcontroller, so these things fit in places that simply can't afford anything more expensive.
The PIC12C508A is not the smallest and least capable microcontroller you'll meet, as 4-bit devices run appliances that don't require "data processing" in the traditional sense. However, these tend to be very application specific, very high volume, and often hide under epoxy blobs on circuit boards inside simple electronic doodads.
Oddly, development tools for 4-bit microcontrollers can cost more than your car. One web page touts an in-circuit development system that requires a PC-AT compatible ISA-bus slot; one wonders how friendly the user interface might be. Spreading their relatively high prices over a huge production volume renders them attractive to their main audience, while pricing them right out of smaller markets.
PICs and other 8-bitters are eating into the 4-bit market, perhaps because their development tools tend to be free-as-in-beer on the manufacturers' web sites. Remember, if you're selling chips by the pallet-load to tens of thousands of customers, software has an essentially zero per-unit cost; why that doesn't apply to the 4-bitters is a mystery. Although you may pay more for a C compiler, if you don't like the free assembler, high-level languages aren't absolutely necessary for work at the very low end of the biz.
The development hardware for the newer chips is relatively inexpensive, as software does most of the heavy lifting. The chips can be programmed through a serial port while on the board, at least if you apply some foresight during the board design, and simulators can be perfectly adequate for most projects.
Low-cost development tools allow small-scale users to try the chips on for size, while Flash-ROM program memory eliminates the need for huge volumes of mask-ROM parts. For small production runs, up to several thousand units, the economics seem to favor the 8-bitters.
The computers we're familiar with have what's called a "von Neumann" architecture, although credit should go to Ekert and Mauchley for the basic notion of storing both programs and data in a common memory. Treating programs as data has some benefits in a system that's used for both development and runtime execution, with the notable disadvantage of allowing stack-smashing attacks to create executable data.
Microcontrollers, in contrast, generally have a Harvard architecture with separate program and data address spaces and, as with the PIC12C508A, the memories need not have the same width. Because embedded systems generally run one program forever, the program is stored in read-only (or, perhaps, write-rarely) memory when the chip is installed. The CPU can extract some values as data from program memory, but it cannot (in general) change the instructions during execution.
Microchip's lowest end PIC12 microcontrollers pair an 8-bit ALU with 12-bit instructions, while the PIC16 series has 14-bit instructions. The fact that instructions are fractional bytes in length is completely irrelevant to the program, as whole instructions never cross the datapath. The high-end PIC18 series has 16-bit instructions and a slightly less weird architecture.
Speaking of weird, Motorola once produced the MC14500, a 1-bit microcontroller core in a 16-pin DIP package. This was in the days when transistors were a countably finite resource, so pairing a 1-bit datapath with a 4-bit instruction word made perfect sense. In fact, you had to provide external program and data memory, as well as a program counter, so the MC14500 wasn't a single-chip microcontroller. The CPU could execute JMP and RET instructions, but it was up to you to provide amenities like an external call-return stack.
In any case, low-end microcontroller hardware is not a good match for high-level languages, even if you define C as high-level. An architecture lacking a hardware data stack, multibyte arithmetic, and capacious memory simply doesn't make for efficient code. That's okay as long as the code fits in the available memory and runs fast enough to get the job done, but it's a killer when you must justify an additional 50 cents for the next-larger chip.
More complex microcontrollers, notably the Atmel AVR series, play better with C, but it's still a snug fit. You'll be a better designer in this genre when you can work your way through the hardware details in assembly language, at least for the fiddly parts of the project.
Code Space
The prime directive of contemporary software development is to recycle old code, a directive frequently observed in the breach. You should have more time to get newer, project-specific code working when you reuse older, presumably debugged, code. Ideally, the old code won't present any new problems at all.
Reuse doesn't always work, as ESA discovered a few seconds after the first Ariane 5 launch when assumptions made in the old code didn't match up with its new environment. The Ariane 5 guidance system, hoisted intact from the Ariane 4, encountered a numeric overflow while converting a 64-bit floating-point sensor value to a 16-bit fixed-point number: The new airframe had a much higher down-range velocity. The old code worked fine, but not with the new, larger data values.
Oops.
While I can't speak for the industry at large, I suspect that most small microcontroller projects start out as cut-and-paste snippets from the latest version of an older project that did something similar. This is not to say that there's no design process, but once you've figured out how to sample pushbutton switches or fake a 16-bit subtraction on a CPU lacking a subtract-with-borrow instruction, you don't ever want to think about that stuff again.
Unfortunately, the familiar techniques of hierarchical and functional decomposition don't go very far with a two-level call-return stack and no stack-overflow trap. Your main loop can call a subroutine, which can call another subroutine, and that's it! You quickly value the JMP instruction above all others.
You might turn to macros, those old assembly-language friends, instead of subroutines. Macros, alas, require considerable restraint in a computer where a single 16-bit subtraction occupies 1 percent of your code space.
In truth, I'm unfairly slagging the smallest of the 8-bit microcontrollers. Microcontroller programming, particularly on the small end, tends to be very simple and straightforward. The chips are typically used for logic replacement, not data processing: monitor and debounce a few switches, produce a few carefully timed pulses, and repeat forever. The programs include simple bit tests, trivial logic, counted iteration, and very little else.
Those tiny code and data spaces turn out to be entirely adequate for the simple jobs that might otherwise be done by a 4-bit micro. Larger microcontrollers have more of everything, at the cost of more space and money, presenting a clear tradeoff of unit cost versus software development effort. Guess who comes out on top in those wrestling matches?
Patents and Copyright
I may never know how that patent slugfest will end, although it's hard to imagine it can produce any net benefit to the world at large. What I do know is that it's getting harder to produce code without stumbling around in a legal minefield.
Very small microcontrollers, the ones used for logic replacement, can run afoul of patents covering hardware devices, even if you've written all the code from first principles. Patent law grants the patent holder a limited monopoly over all devices embodying the patent claims; separate invention is no defense.
Copyright law requires direct copying from the original source, so if you didn't see it, you didn't copy it. Unfortunately, the litigation establishing that fact may soak up more than you can afford, so be very sure you know where your code came from!
There's more to say on this topic as soon as I figure it out. Being an engineer, rather than a lawyer, presents some disadvantages when attempting to figure out how the law actually works.
Shibboleth Redux
That restroom doggerel in the April column turns out to be the sports "fight chant" for both Carnegie Institute of Technology and CalTech. The earliest reports put it in the late '60s, well before I saw it at Lehigh. The last line scans better: "Watercooled slipstick, C-I-T!" More cheers at http://www.andrew.cmu.edu/~kiltie/who/cheer.html. Art Werschulz, Lorne Schachter, and Scott Meyers hadn't thought about that for years.
Bob Rabinoff reports that Bronx High School for Science had a similar cheer in the early '60s, with little effect on their team's athletic prowess: "log exponent square root pi / Let's go Science High!"
Peter Chase has a special place in his heart for Pr1me Computer, noting that 1 is not a prime number. He always associated Pr1me with dogfood. Robert Masta points out another corporate naming hazard: getting blindsided by popular culture. Guess what the web site for the training company formerly known as ViaGrafix might be? Go ahead, type in the obvious URL and try to find them on the Web. Hint: They're now known as Learn2.com.
The April issue of IEEE Spectrum mentioned that Synopsys Inc. purchased Avant! Corporation in 2002, which may explain why I couldn't find any trace of it two years later. Having a techno-glyph name that's ignored by Internet search engines didn't help, either.
Larry Carasco discovered that none other than George Bernard Shaw first promulgated the word "ghoti." If that doesn't make it the official spelling for "fish," I don't know what would.
Scott Meyers reminded me that Intel used Roman numerals that resembled exclamation marks for the Pentium III series. Figure 1 shows the sticker on the front of my oldest box. We should be grateful they didn't use little bitty "i" glyphs, I guess.
Reentry Checklist
I just saw a note that the 2003 semiconductor market was $177.5 billion, so scale the numbers accordingly. The results will be roughly the same: Microcontrollers are a small slice of a big pie, 8-bitters rule, and Linux-capable systems form just a crumb.
Microchip is at http://www.microchip.com/, with more than you ever imagined about PIC hardware and software at http://www.piclist.com/techref/piclist/index.htm. Atmel is at http://www.atmel.com/. Motorola and Hitachi microcontrollers now come from Renesas at http://www.renesas .com/eng/.
You can get your very own MC14500 single-bit CPU datasheet from http://www.radanpro.com/el/datasheets_mc.htm after registering blindly in what looks like Polish. Anybody up for writing an emulator? You could probably run it in a PIC12C508 with room for the MC14500's program. If not, surely a slightly bigger PIC could preserve much of the external interface, such as it is.
A rather cynical view of embedded systems development lives at http://weblog.sinteur.com/archives/000884.html. You've probably seen it in other guises; if not, remember that Dilbert is a documentary.
Wikipedia has many historical tidbits, including the history of Xenix at http://en.wikipedia.org/wiki/Xenix. I've mentioned the Ariane 5 before but found a different analysis of the problem at http://www.rvs.uni-bielefeld.de/publications/ Incidents/DOCS/Research/Rvs/Misc/ Additional/Reports/ariane.html.
DDJ
