Hardware Reference
In-Depth Information
Microcontroller development tools can be divided into two categories: hardware and
software.
A user needs a good
text editor
to enter his or her program. After the program is entered,
the user needs an
assembler
or a
compiler
to convert the program into machine code for execu-
tion. A complicated program may consist of multiple computer files. A
linker
will be needed to
resolve the variable cross-reference and memory allocation issue.
Before the user has the hardware to execute the program, a software
simulator
can be
used to verify whether the program is logically correct. A
simulator
allows the user to execute
microcontroller programs without having the actual hardware. It uses the computer memory to
represent microcontroller registers and memory locations. The simulator interprets each micro-
controller instruction by performing the operation required by the instruction and then saves
the execution results in the computer memory. The simulator also allows the user to set the
contents of memory locations and registers before the simulation run starts.
After the software has been assembled or compiled without syntax errors, the user may
want to transfer the resultant machine code to the target hardware for execution. This will
require a
communication
program (for example, the HyperTerminal bundled with Windows
operating system) or even a hardware programmer.
When the software becomes complicated, the
program management
issue becomes com-
plicated. The common approach is to use
project
as a unit to manage the software development
process.
The
source-level debugger
is a program that allows the user to find problems in her or his
code at the high-level-language (such as C) or assembly-language level. A debugger may have
the option to run the program on the target hardware or using a simulator. Like a simulator, a
debugger can display the contents of registers and memory (internal and external) and program
code in separate windows. With a debugger, all debugging activities are done at the source
level. The user can see the value change of a variable after a statement has been executed. The
user can also set a breakpoint at a statement in a high-level language. However, a source-level
debugger requires a lot of computation. A source-level debugger needs to communicate with
the monitor program on the demo board in order to display the contents of CPU registers and
memory locations, set or delete breakpoints, trace program execution, and so on. Since the
monitor programs on different evaluation boards may not be the same, a source-level debugger
may be used only with one type of demo board. The BDM mode of the HCS12 (and other micro-
controllers) offers an alternative for implementing the source-level debugger.
The software vendors often integrate a text editor, an assembler and/or compiler, a
linker, a simulator, a source-level debugger, and a project manager into a package so that
the user can switch from one tool to another without exiting any of these programs. This
integrated software environment is called an
integrated development environment
(IDE).
The complexity of IDEs varies significantly. For example, the freeware
MiniIDE
consists of an
assembler, a linker, a project manager, and a terminal program for the PC to communicate
with the demo board. Using the MiniIDE, the user can enter and assemble his or her assem-
bly program and download it onto a HCS12 demo board (this HCS12 demo board must have
the D-Bug12 monitor program) for execution. After downloading the machine code onto the
demo board, the user can then use commands supported by the D-Bug12 monitor to perform
debug activities.
Search WWH ::
Custom Search