Page 110 - The Art of Designing Embedded Systems

Firmware Musings 97

address space. Figure on making a few patches to the supplied remapping
code to accommodate your unique hardware design.
In C or assembly, using an RTOS or not, be sure to put all of your in-
terrupt service routines and associated vectors in a common area. Put the
banking code there as well, along with all frequently used functions (when
you’re using a compiler, put the entire runtime package in unmapped
memory).
As always, when designing the hardware carefully document the ap-
proach you’ve selected. Include this information in the banking routine so
some poor soul several years in the future has a fighting chance to figure
out what you’ve done.
And, if you are using a banking scheme, be sure that the tools provide
intelligent support. Quite a few 8-bit emulators, for example, do have extra
address bits expressly for working in banked hardware. This means you
can download code and even set breakpoints in banked areas that may not
be currently mapped into the logical address space.
But be sure the emulator works properly with the compiler or assem-
bler to give real source-level support in banked regions. If the compiler and
emulator don’t work together to share the physical and logical addresses of
every line of code and every globaktatic variable, the “source” debugger
will show nothing more useful than disassembled instructions. That’s a
terrible price to pay: in most cases you’ll be well advised to find a more
debuggable CPU.

Predicting ROM Requirements
It‘s rather astonishing how often we run into the same problem. yet
take no action to deal with the issue once and for all. One common prob-
lem that drives managers wild is the old “running out of ROM space” rou-
tine-generally the week before shipping.
For two reasons it’s very difficult to predict ROM requirements in the
project’s infancy. First, too many of us write code before we’ve done a
complete and thoughtful analysis of the project’s size. If you’re not esti-
mating code size (in lines of code or numbers of function points or a sim-
ilar metric), then you’re simply not a professional software engineer.
Second. we’re generally not sure how to correlate a line of C to a
number of bytes of machine code. Historical data is most useful if you‘ve
worked with the specific CPU and compiler in the past.
Regardless, when you start coding, maintain a spreadsheet that pre-
dicts the project’s size. As a professional you’ve done the best possible job
estimating the functions’ sizes (in LOC, lines of code). List this data.