Editor's Note: This three-part article is abstracted from Chapter 7 of the book Embedded Hardware Know It All with the kind permission of the publisher.

See also Part 2.

The book features a "360 degree" view from best-selling authors Jack Ganssle, Tammy Noergaard, Fred Eady, Lewin Edwards, David J. Katz, Rick Gentile, Ken Arnold, Kamal Hyder, Bob Perrin, and Creed Huddleston.

The Newnes "Know It All" series takes the best of what their authors have written over the past few years and creates a one-stop reference for engineers involved in markets from communications to embedded systems and everywhere in-between.

Embedded Hardware Know It All provides: "The ultimate hard-working desk reference with all the essential information, techniques, and tricks of the trade in one volume."

---

Introduction
The start of a complex embedded project, particularly in a small organization without engineers who can be dedicated full-time to component procurement, can be extremely stressful. Until a first-round prototype is built and tested (and often even after this stage), it is usual for hardware requirements to be at least slightly vague, particularly vis-à-vis the exact breakdown of which functions are expected to be integrated into the microcontroller and which will be off-chip. As the design engineer, some of your goals are obviously ease of firmware and hardware development, low bill-of-materials cost, and reliability of sourcing. You will probably start with a list of hardware requirements and match those up against selection matrices from different vendors to find a part that has as many of your features as possible on-chip.

At this point, what you really want is a vendor-neutral parametric search engine for which you can select the performance and peripherals you want and obtain a list of suggestions collated from everybody's catalogs. Unfortunately, most of the search facilities available online leave much to be desired. Many manufacturers don't have full parametric search engines available, and those that do obviously only list their own parts. Third-party search engines do exist, but they are usually premium services for which you will have to pay – and again, they only list products from manufacturers with whom they have a relationship. Also, the total startup cost of development – evaluation boards, tools, etc. – is an important factor to us (for some readers, perhaps even more important than the unit cost of the microcontroller), and this cost will not be listed by parametric search engines. Finally, as with any other search facility, it can be difficult to match your needs with the list of keywords provided in the search engine.

This is one occasion when there is no substitute for peer support. Even if you think you've found a perfect match already, it's well worth searching Usenet archives (groups.google.com) for discussions on similar applications to your own. A carefully phrased question may lead to even more useful suggestions. Even if you are intimately familiar with every IC vendor that impinges on your industry, you might miss a new product announcement and thereby not know to check manufacturer X's catalog. Sometimes the only clue you need to lead you to the right part is the information that manufacturer X makes 32-bit microcontrollers! Furthermore, other engineers who have worked with the part may be able to point you to low-cost, third-party evaluation platforms or off-the-shelf appliances that can be used as demo boards, and they will be better positioned than anyone else to give you relatively unbiased opinions on real-world difficulties of using a specific device.

In the early days, it is also doubly hard to make an optimal price/performance choice, because the selection sheets generally won't show pricing. For any part that can't be bought anonymously off the shelf (and unfortunately the majority of 32-bit microcontrollers fall into this category), most chip vendors expect you to establish a relationship with their distributors. This can waste a lot of time in profitless face-to-face meetings. My own experiences with local reps and distributors in the United States have been very patchy, and I have often found that their knowledge of the 32-bit parts on their line card is limited to whatever bullet points the manufacturer printed on the sales literature. The distributors want accurate annual usage forecasts before they will give you sensible pricing, and they obviously have little or no incentive to deal with small-volume purchasers like students or hobbyists. Political difficulties related to sales commissions also arise when you are designing the product in one country but intend to manufacture it in another. Furthermore, the distributors and reps will be most likely to quiz you on your other requirements and try vigorously to sell you other parts from their line card. Although this possibly has some marginal convenience benefits if you intend to source and manufacture locally, it certainly isn't the ideal way of minimizing the bill-of-materials cost of your product.

It's all too easy to become trapped in an endless circle trying to seek an optimal solution to all these problems, so you shouldn't attempt it. Recognize from the outset that this is a classic "traveling salesman" problem (perhaps even in the literal mathematical sense) and that your goal is merely to find an acceptable solution in time to finish your project and send it to the factory (or submit it to your professor, if you're a student). Your goal is not to find the best possible solution. If your team has enough personnel to dedicate a lot of person-hours to sourcing components, you will probably be able to find a better solution than the one-person "team" scouring catalogs on a time limit, but a suboptimal one-person solution can always be refined later if the project goes into production in quantities that justify it. As in any other industry, our goal is to develop a product that works properly and is ready to manufacture in a timely fashion.

With that said, I employ the following useful heuristics to filter my short list for 32-bit microcontroller selection:

• The device should be available for anonymous online or catalog ordering in singlepiece quantity from at least one major distributor. (In the U.S., the big names commonly mentioned are Digi-Key, Newark, and Avnet Marshall. Digi-Key and Newark in particular have very broad inventories and generally allow purchases in small quantity. Avnet Marshall seems to cater more to manufacturing rather than prototype runs; they typically have 25- or even 250-piece minimum orders on parts.) 
   
• Full data sheets for the device should be available without requiring a nondisclosure agreement or committing to any kind of purchase.  
   
• A low-cost development board should be available for the part – either the manufacturer- recommended board, a third-party board, or even some appliance based around the chip, as long as sufficient documentation exists to enable use of the appliance as a test bed for your own code. You should also ask the manufacturer and distributor if loaner boards are available; if you can borrow a board for a month or two, it will be enough to get at least bootstrap code up and running and establish a basic level of familiarity with the microcontroller. You can then move to your own hardware and return the evaluation board. 
   
• There should be a direct technical contact available at the chip vendor, at least for emergency issues; it should not be necessary to route all questions through distribution. (Note that I'm not advising you to abuse such a privilege – if you have a direct manufacturer contact, it's best to contact him or her only when absolutely necessary. But there are times when a complex problem will take weeks to solve when there are several layers in the communication chain, versus only a day or two if you can communicate directly with the cognoscenti at the chip manufacturer. As a small customer, the less you use this resource, the better chance you will have that your next urgent question will be answered speedily.) 
   
• The device should have been shipping to OEMs for at least three to six months. 
   
• The core should be supported by the GNU toolchain. 
   
• There should be at least one currently shipping commercial product that uses the device, and the larger the market for this device, the better. All too often, parts that are consumed only by small niche markets are discontinued in favor of parts with more general applicability.

These are not absolutely binding rules (in particular, the last one can be hard to obey for a brand-new part), but they provide a good way of thinning a short list of any undesirable parts that are going to cause logistical problems later. The first criterion above is especially important to note because it can give you some idea of the part's longevity. One little-mentioned fact of the microcontroller industry is that very few high-end parts are designed only for the marketplace in general; many of the "standard" 32-bit parts and ASSPs started life as proprietary ASICs developed under contract for some specific electronics manufacturer. These contracts typically have large guaranteed order quantities and forward-planned production schedules. However, once that manufacturer's exclusivity expires, the chip vendor is free to sell it to other people, if it conceivably has any generally applicable function.

The first step in this process is usually to offer the part quietly to other existing customers or to carefully selected others, without a highly visible product announcement or other publicity. This small group of privileged customers will, again, work on large volume pre-orders with long-term schedules. If a chip goes on from this stage into retail distribution channels (such as Digi-Key and other stores catering to small orders) it is a very good sign because it usually means one of two things:

1. The chip vendor is seeking to gain market share in the field addressed by this part and is pushing it heavily (also implying that excellent support will be available both from the manufacturer and other users), or 
    
2. The product is so wildly successful that the chip vendor is producing reasonable quantities of it in advance of any firm order, in expectation of future unscheduled orders.

In either case, the part is in wide-scale production, and it is a fairly safe bet to design it into your product. You can be reasonably certain that the part will not be discontinued in the immediate future.

Choosing the right core
Unfortunately, even with the greatest care in choosing parts that appear to be supported for the long term, there are never any guarantees. Parts are discontinued or superseded all the time for marketing reasons that are sometimes not obvious and far from predictable. For that matter, sometimes your requirements change slightly and your previous choice of microcontroller is suddenly no longer suitable. This is particularly annoying when a design change of this sort is a result of entirely external forces. I have been involved in several projects where the microcontroller has been changed just before production, or even after production starts, simply because of sudden supply shortages of other parts.

Obviously, the more careful you are in choosing a part that exactly meets your requirements, the more disruptive it is likely to be to have to substitute a different part. A large customer might be able to guarantee the chip vendor enough volume for them to continue occasional production runs or even perhaps migrate an old part to a new process and continue general production. Since we're going to be a tiny customer, we won't have this luxury.

The only truly effective preparation for this inevitability is to anticipate it and pick a microcontroller based around a popular core to minimize the workload of porting to a new processor when circumstances demand it. Generally speaking, there are six very widely used 32-bit cores on the market at the moment: Motorola 680x0, Intel x86, PowerPC, MIPS, SuperH, and ARM. Numerous less popular or proprietary architectures also exist, of course; many of these are associated with specific applications such as laser printers or DVD players.

(Note that we mention only general-purpose microprocessor cores here. DSPs are a separate world beyond the scope of this chapter.)

At the risk of antagonizing its userbase, I recommend against choosing the 680x0 series for a new design. Use of this core appears to be in decline, and it is perhaps actually close to the end of its life; the principal consumer use at this time is in PalmOS devices. These PDAs are now migrating toward ARM, and even Motorola has introduced an ARM-cored processor as its new flagship PDA part. The entry-level laser printer market, which formerly consumed a lot of MC68000 and MC68008 parts, has largely been dominated by cheap devices that lack a rasterizer (they rely on the driver software running on the attached PC), so they only require simple servo control on the printer mainboard.

Architectures based around the high-end x86 family (and code-compatible parts from AMD, National Semiconductor, Via Technologies, etc.) have some immediate advantages:

• You can use almost any PC-compatible operating system and free software development tools. 
   
• Installing operating systems is simple; in most cases there are automated installers that will probe your hardware combination and automatically install appropriate kernels, drivers, etc. Compare this to the norm with embedded systems, where you will need to look at the board, work out the hardware configuration yourself, and sysgen the kernel and driver set on external hardware, probably using a cross-compiler. 
   
• It is simple to interface literally thousands of peripheral components for almost any imaginable function. Because these components are produced for the consumer market, with its enormous volumes and bloodthirsty price competition, peripheral components are cheap and fairly easy to acquire. 
   
• Driver support exists (within the framework of most off-the-shelf operating systems) for almost any piece of hardware you could want to attach to your system. 
   
• Highly integrated mainboards are available with many possible combinations of peripherals, in a wide variety of form factors. 
   
• Migrating to a slightly different hardware platform due to shortages of support parts or evolving customer needs is relatively simple; in many cases, it simply involves recompiling and reinstalling the operating system and preparing a new master disk image for duplication.

Having extolled the obvious virtues of these parts, we must also point out some of the downsides:

• x86 parts are very expensive, in production quantities, compared to RISC alternatives of comparable performance. This may affect your ability to commercialize your device.

  Note: This first statement needs qualification. Although the x86 CPU is quite expensive, you might find that a given system configuration is cheaper when built around an x86 than a RISC processor such as PowerPC because of the significant economies of scale in producing large volumes of the x86 board. 
   

• There are relatively few x86 variants that are true "system on chip" devices, so you are likely to need quite a bit of external hardware in addition to the microprocessor itself. Often, to obtain one specific function, you will need to add a complex multifunction part because the single function you want isn't available as a discrete component. Again, this brings up your system complexity and total bill-of-materials cost. 
   
• x86 has significant power consumption, heat, and size disadvantages. (The Transmeta Crusoe x86-compatible device combats these disadvantages, but it is currently rather expensive and not very many vendors have products based around this microprocessor.) 
   
• Modern x86 parts and their support chips are very high-speed devices in dense packages. It is virtually impossible to hand-prototype your own design based around these parts; unless you want to spend many thousands of dollars on equipment, at the very least you will have to contract out some assembly work. 
   
• PC peripheral ICs often have very short production life spans; twelve to eighteen months is not uncommon, so ongoing sourcing may be an issue. 
   
• Code to cold-boot a "bare" PC platform is usually very complicated because you have to replace numerous layers – motherboard BIOS, expansion card BIOS, and various OS layers. The CPU architecture is also complex. 
   
• Although I personally don't consider this to be a serious downside, it bears pointing out that JTAG-based or other hardware debugging systems aren't usually available on commercial single-board x86 computers.

I recommend x86 as the platform of choice if you are either building just a few of your appliance or if you are prototyping something and want to pull together a lot of miscellaneous hardware features without spending a great deal of time debugging the hardware design. It's also a good choice for an initial production run that you can ship to early adopters while you are developing a cheaper second-round customized hardware design. There are other special situations where you might find x86 to be a good choice, but these are the major ones.

Of course, you aren't restricted to using Intel parts; for instance, one x86-compatible part that is fairly popular in embedded applications is the Geode series from National Semiconductor (based on intellectual property acquired from Cyrix). This part was designed for Internet appliances and can be found in several such devices on the market today. There are also numerous single-board computers built around Geode chips, with various peripheral functions according to the intended application. Geode was also used as the reference platform to develop and showcase the new Microsoft Smart Display device, so the product family is likely to be supported for quite a while.

Using x86 also doesn't mean that your device needs to have a large PC motherboard and expansion cards inside it. Unless your needs are highly specialized (and perhaps even if they are), it is probable that you will be able to find a single-board computer with most or all of your required hardware already integrated. These boards range in size from "biscuit PCs" with the same footprint as a 5.25" disk drive down to a fairly new standard (consisting of a user-designed baseboard holding an off-the-shelf module containing the CPU and some peripherals) usually referred to as ETX. Embedded computer boards like this typically have PC/104 expansion buses (a condensed, stackable version of ISA using 100 mil headers) or Mini-PCI. Some of the larger boards will have regular PCI slots, but these start to make the overall system unavoidably rather bulky, approaching the size of a normal slim-line PC.

Note that PC-compatible SBC pricing falls into two widely separated categories: industrial and commercial. Industrial SBCs are extremely expensive – at least twice the cost of commercial versions. Commercial SBCs, though substantially more expensive than consumer-grade PC hardware of the same nominal specifications, are a much better choice for the budget-constrained purchaser. Many SBC vendors specialize in industrial automation only, so if the prices you are being quoted seem unrealistically high, you should investigate other vendors before concluding that x86 is too expensive for your project.

Moving onto the RISC platforms, MIPS, SuperH and PowerPC are good candidates for many applications, and in particular the SuperH family is large and contains a wide variety of useful devices, though MIPS seems to be a more widely licensed core in third-party ASICs and ASSPs. PowerPC seems to be found mainly in applications requiring very high performance. In evaluating all these parts for various projects, I have found them to be fairly difficult to develop with on a shoestring budget; evaluation hardware is usually costly, and most variants of these parts are not readily available to buyers who are unable to demonstrate a need for large quantities. However, all these cores are likely to remain available and well supported for the foreseeable future, so they are all viable choices as long as you can obtain development systems and parts.

At least in the case of SuperH and MIPS, your cheapest path to a prototype based on these parts is generally to repurpose some existing piece of hardware such as a PDA; for PowerPC, I would suggest buying a commercial single-board industrial control computer based around the chip of interest. Be warned that this is likely to be expensive; PowerPC boards don't have the same kind of mass-market pricing as x86-compatible boards and you can expect to pay between two and three times as much for a PowerPC SBC as for a comparable x86-based board.

Bearing the above discussion in mind, unless some of the Intel arguments apply to your case, my primary recommendation for a 32-bit embedded platform is ARM. This architecture has many important advantages (some of these are also applicable to the other RISC platforms mentioned above, of course):

• It is a mature, well-understood architecture with a solid engineering history and many refinements. The large number of current licensees and now-shipping parts makes ARM a very safe bet for future availability. 
   
• The cores are small and have excellent power consumption vs. performance characteristics. 
   
• Many features – coprocessors, external bus widths, memory-management unit, cache size, etc. – are tunable by the chip designer, meaning that a core variant can be found to meet almost any performance/size/power requirement. 
   
• There are a huge number of attractively priced standard, custom, and semi-custom parts on the market with a wide variety of integrated peripherals. 
   
• Since ARM provides reference designs for many different peripherals as well as the core itself, there are often similarities in peripheral control on different ARM implementations, even from different vendors. To take a trivial example, code to send data out of a serial port can usually be ported from one ARM variant to another with little effort. 
   
• Partly due to the above factors, there is a huge amount of freely available intellectual Property – reference designs, ready-ported operating systems, etc. – already extant for this core.

The cliché is that "ARM is the 32-bit 8051," meaning that it is the universal 32-bit microcontroller core known to everybody and used everywhere. This is barely an exaggeration; ARM is to the embedded world what x86 is to the desktop PC world.

It's important to keep your priority – low overall development cost – in sight at all times during the selection process. For example, I almost always reject parts that are only available in BGA packages, because it is practically impossible to hand-build prototypes around these devices, and it's costly to hire an external contract assembly house to build your initial development boards. You'll also need to consider the price and availability of evaluation hardware for the devices you're comparing, as well as the complexity of building a working hardware platform of your own. For example, a chip that requires complex analog support circuitry and careful PCB layout will be very difficult to work with in a hand-prototype environment. For such a chip, you would quite likely be better off investing in an expensive known-good evaluation board before attempting to build your own PCB. Diving straight into the deep end by designing your own board around such a part is likely to be costly because of the need for several respins of your board to resolve layout-related and other analog issues.