Page 33 - Embedded Microprocessor Systems Real World Design

and slow but could often be upgraded (at a huge cost) with hardware that would
permit software development for more than one manufacturer’s parts. If you can
find one of those old development systems today, it probably will be in use as a
doorstop or boat anchor.
It is unarguable that the standardization of the business world around the IBM
PC and its derivatives has been a real advantage to the embedded systems devel-
oper. Most manufacturers of microprocessor ICs now provide development software
instead of systems for their parts. These cross-compilers run on a PC to compile or
assemble code for the manufacturer’s microprocessor. (Technically, a cross-
assembler is a special case of a crosscompiler, and in this book the term cross-
compilerwill refer to both types of software.) Some manufacturers even give away
some sort of development tools (usually an assembler) to potential customers on
the premise that they are in the IC business, not the software business. It is un-
known how many microprocessor selections have been made based on the avail-
ability of these free tools, but the number must be large.
Many IC manufacturers still provide complete development systems for their
parts. These are usually PCs with the manufacturer’s software included, and they
constitute a complete development environment. But buy carefully-these PCs can
be a bad deal from a cost perspective.
Some will argue that the PROM programmer no longer is an essential develop
ment tool, and they are right. If the project is to be developed in RAM or on an
embedded PC or on a flash-based, downloadable processor, a PROM programmer
is not needed. As more and more microcontrollers move to a flash-based architec-
ture, the need for PROM programmers in the engineering lab will decline further.
However, some projects still are developed in an environment in which parts have
to be erased and programmed every time the code changes; for those developers,
a PROM programmer is needed.
When the development system consists of a crosscompiler and a PROM pro-
grammer and little else, debugging is simple, although often tedious. The code is
run, the operation of the system is observed, and the code is examined to see why
things do not work. This process is repeated until all bugs are found. For some
systems, especially at small companies, this stare-at-thecode method is still used and
works well. This method becomes less and less attractive as system complexity grows
and development schedules shrink.
The next level of debug is a monitorpog-am, sometimes called a debuggm. This
simple program resides in the embedded system and provides commands to
examine and alter memory, download code, and insert breakpoints into the code.
A breakpoint is an unconditional branch instruction that takes the code back to
the monitor program, where the registers and memory may be examined. Monitor
programs require some kind of terminal, and the monitor program itself takes
up considerable memory, so they typically are not used with very simple
microprocessors.

18 Embedded Microprocessor Systems