Page 23 - Embedded Microprocessor Systems Real World Design

not as important as knowing the upper limit on code size. One rule of thumb is
that if the ROM is more than 80 percent full, it is too full. Unless you can guaran-
tee that the system requirements will never change, leave some margin. In many
cases, it is worthwhile to write portions of the code just to see how big they will get.
In microcontroller-based systems with internal ROM, you are limited to whatever
program memory the part contains.
Like RAM usage, code size depends somewhat on the development (program-
ming) language selected. A program written in assembler takes less space than one
written in Pascal, for example. Again, this depends on the language and even on
the specific brand of software.
It is not a good idea to let the language drive the design, at least in low-cost
systems. The languages easiest to use, debug, and maintain are often those that
require the most memory and processing speed. Choosing the wrong language
can turn a simple, inexpensive, single-chip design into something that requires
an embedded 64bit powerhouse with megabytes of RAM. However, sometimes
company policy or a customer contract specifies the use of a high-level language.
In these cases, you just have to live with the increased cost and complexity that this
implies.
A real-life example will illustrate the potential problems you can run into here.
An embedded system was to be controlled by an x86family processor. We had
settled on an off-the-shelf CPU board, based on a 386SX. Then one of the software
people noticed that the 386SX has no floating-point coprocessor (FPU) . The soft-
ware engineers were from the PC world, where everything ran in Windows 95/98,
on a 400MHz Pentium. They couldn’t conceive of not having hardware for
floating-point calculations. The only way to get a hardware floating point was to go
up to a 486DX or Pentium processor, which doubled the cost of the CPU board.
This was an embedded application, with no keyboard, display, or hard drive attached.
The CPU was reading sensors, controlling motors, and communicating with a PC
host. There was no reason to believe that floating-point calculations would ever be
needed. But, because C makes it easy to define floating-point variables, they were
expected to be available in hardware. In fact, the code wasn’t designed or written
yet, so we didn’t know whether any floating-point calculations would actually be
required.
This same design had some embedded microcontrollers for very low-level func-
tions. What if a software engineer had decided that those needed hardware float-
ing point and a deep stack for recursion? We’d have turned a requirement for a
cheap 8-bit microcontroller into Pentium-class overkill.

Number of Interrupts Required
We’ll cover this subject in more detail in Chapter 5; however, a few comments are
worth mentioning here.

8 Embedded Microprocessor System