Selecting an embedded processor involves both simple and nontechnical criteria

Scott Rosenthal
June, 1997

One thing all embedded systems have in common is that they include some type of processor. They range anywhere from a serial-program input device, to an OTP microcomputer, to a full-fledged PC on a chip or board. At some point, an engineer decided on the type of processor to use. How did he pick it? Are there any rational reasons for picking one over another? Or are all processor selections based on personal bias?

The choice of a processor, just like the choice of anything else in a design, should be based on product and marketplace needs. So how do you pick one? There's no magic box into which you place the system requirements that spits out which processor to use. Instead, the designer must make compromises during the selection process.

Few of us start a new design that doesn't build off of an older one. Sometimes we’re forced to use a processor because "that's the one we always use." But if you could select any processor at all for a product, which would you choose? How would you make that selection? The following checklist might help in evaluating your needs:

	How much program and data space (including a stack and heap) will you need?
	How many interrupts must the system handle (and are you sure)?
	How much I/O will the design need, and does it make sense to find a processor with onboard I/O?
	What's the most time-critical operation the processor must perform?
	What development tools, both software and hardware, are available for the processor?
	What's the true cost of using the processor, including any support components, power supply and testability?
	What's the device's availability presently and in the future?
	How will the software work with the hardware, and vice versa?
	What design tools, such as assemblers, compilers and emulators, are available?
	What can you afford?

Nothing's clear cut in this decision, and no salesperson has the answer, either. As the above questions hopefully show, the solution comes from many places including the software and hardware developers as well as manufacturing and testing staff; marketing people might even have a reason to get involved. If you don't get everyone's consensus, tradeoffs in the product will probably deteriorate into fingerpointing when hiccups develop.

The following discussion focuses on smaller processors (microcontrollers and microprocessors) typically found in embedded instruments. Readers designing in Pentiums and Power PCs have a different set of issues to worry about.

Memory size

How much memory is among the first and probably one of the toughest questions you face in selecting an embedded processor. An old axiom says that a program always expands to fill available space, and with most embedded processors memory space is limited.

Also keep in mind that embedded systems typically include two main types of memory. The first, program memory, can be flash, ROM, UVEPROM or EEPROM. The second, data RAM, can be static, dynamic or even (with stretching the concept of program RAM a little) EEPROM. Your job is to come up with a good estimate of memory needs for the two types while not over or underestimating.

I gauge how much program memory to use in a number of ways. The first is to rely on past experience. To do so, I track the number of lines of program code (LOC) versus the number of bytes of program memory used versus processor type. With this information I can make some elementary estimates on a new project by asking several questions:

	What completed project is this new one similar to?
	Are the processors similar?
	Do both projects use similar math (floating point vs. integer)?

First, though, you should be aware of my definition for LOC. I consider comment lines and even blank lines for formatting all parts of LOC calculation. Even though comments don't generate program code, they’re essential to the software. In addition, their effect in overinflating the LOC with a large enough program becomes a constant from program to program. For example, at my company we average 27% blank lines (white space) in program code. This number varies just a percent or two from engineer to engineer.

As some rules of thumb, I've found that an 8051 project written in C and with floating-point math averages roughly two bytes of program memory for each LOC. Likewise, an embedded X86 processor averages approximately four bytes per LOC. Obviously, your numbers might be different based on coding style (do you use pointers and structures?). These numbers include all the libraries the linker loads. Now I have a yardstick with which to gauge how much program memory a new project should require. Either I can go through a list of previous projects and find the most similar one, or I can estimate the needed LOC for each section of a project, total them and multiply by my bytes/LOC. Then, if possible, I try to add a cushion of a factor of two. This technique is crude, but it does at least get you in the ballpark. And isn't that better than sticking a finger in the air, checking the wind direction and then declaring "we need 8k of ROM"?

Estimating data memory is a bit different because that memory is so project dependent. For example, one application might need to log data from a sensor every millisecond for an hour, whereas another project just needs to keep a running average of the same data. Obviously the requirements are vastly different.

Data memory also includes the stack and, if applicable, the heap (assuming the selected processor supports stack in RAM). For gauging data-memory needs you must know something about the application. I try to identify all major data structures and their memory requirements, any heap or temporary memory requirements and then add a cushion, typically a factor of two.

As I said before, programs always grow in size. I've never met anyone smart enough to spell out 100% of a project's requirements on Day 1 and encounter zero changes throughout the product lifetime. In the real world, populated with fallible human beings, changes will arise. Before product launch, if you’re "shoehorning" those last program bytes into a product, the problem will remain until you kill off the product. Remember, "measure twice, cut once."

The true cost of embedding

Should you pick a processor just because of its price? One vendor advertises a processor as costing less than a dollar. Another one might cost five dollars. Which one should you choose?

The answer, of course, depends on several factors. One of the biggest is the project's complexity versus availability, cost and ease of use of the development tools. In my experience, processor costs make or break few projects. Remember, the processor is just one component—it isn't the product. True cost includes the chip, required support devices (both active and passive) and software development. In that last item I include the cost of coding and testing, software maintenance (for defects and enhancements) and the expense of finding and keeping qualified people.

Software development is expensive, and the more you try to cram capability into a limited processor (limited by either development tools or the actual processor) the longer development takes. Again, in my experience, the cost savings of scrimping on a processor probably won't pay back extra development costs or delays in getting a product to market. But then again, in some companies money isn't money, and development dollars are separate from production dollars. I wish it was true in the real world.

Career advancement

You might not believe it, but I've even known some people who select a processor based on what furthers their careers! Typically, these people work for an engineering manager who has little idea about the selection process and instead trust the engineer to select the "appropriate" device. Too bad the engineer's definition of appropriate doesn't match the manager's. Sure, it's cool to work with the hottest chip around as long as you can justify it. Let the product dictate processor choices and not your resume. PE&IN

Adapted from an article that appeared in Personal Engineering & Instrumentation News.

Return to the article index.