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.
|
