So, for example, there might be a part of the embedded software usually within the startup code that copies the initial values of the initialized variables from ROM to the data section i
Trang 1_DataEnd = ;
} >rom
bss : /* Uninitialized data */
{
_BssStart = ;
*(.bss)
_BssEnd = ;
}
_BottomOfHeap = ; /* The heap starts here */
_TopOfStack = 0x80000; /* The stack ends here */
text rom : /* The actual instructions */
{
*(.text)
}
}
This script informs the GNU linker's built-in locator about the memory on the
target board and instructs it to locate the data and bss sections in RAM (starting
at address 0x00000) and the text section in ROM (starting at 0x80000)
However, the initial values of the variables in the data segment will be made a part of the ROM image by the addition of >rom at the end of that section's
definition
All of the names that begin with underscores (_TopOfStack, for example) are variables that can be referenced from within your source code The linker will use these symbols to resolve references in the input object files So, for example, there might be a part of the embedded software (usually within the startup code) that copies the initial values of the initialized variables from ROM to the data section
in RAM The start and stop addresses for this operation can be established
symbolically, by referring to the integer variables _DataStart and _DataEnd
The result of this final step of the build process is an absolutely located binary image that can be downloaded to the embedded system or programmed into a read-only memory device In the previous example, this memory image would be
exactly 1 MB in size However, because the initial values for the initialized data section are stored in ROM, the lower 512 kilobytes of this image will contain only zeros, so only the upper half of this image is significant You'll see how to
download and execute such memory images in the next chapter
3.5 Building das Blinkenlights
Trang 2Unfortunately, because we're using the Arcom board as our reference platform, we won't be able to use the GNU tools to build the examples Instead we'll be using Borland's C++ Compiler and Turbo Assembler These tools can be run on any DOS or Windows-based PC.[3] If you have an Arcom board to experiment with, this would be a good time to set it up and install the Borland development tools on your host computer (See Appendix A for ordering information) I used version 3.1
of the compiler, running on a Windows 95-based PC However, any version of the Borland tools that can produce code for the 80186 processor will do
As I have implemented it, the Blinking LED example consists of three source
modules: led.c, blink.c, and startup.asm The first step in the build process is to compile these two files The command-line options we'll need are -c for "compile, but don't link," -v for "include symbolic debugging information in the output," -ml for "use the large memory model," and -1 for "the target is an 80186 processor."
Here are the actual commands:
bcc -c -v -ml -1 led.c
bcc -c -v -ml -1 blink.c
Of course, these commands will work only if the bcc.exe program is in your PATH
and the two source files are in the current directory In other words, you should be
in the Chapter2 subdirectory The result of each of these commands is the creation
of an object file that has the same prefix as the c file and the extension obj So if all goes well, there will now be two additional files—led.obj and blink.obj —in the
working directory
Although it would appear that there are only these two object files to be linked together in our example, there are actually three That's because we must also
include some startup code for the C program (See Startup Code earlier in this chapter.) Example startup code for the Arcom board is provided in the file
startup.asm, which is included in the Chapter3 subdirectory To assemble this code
into an object file, change to that directory and issue the following command:
tasm /mx startup.asm
The result should be the file startup.obj in that directory The command that's
actually used to link the three object files together is shown here Beware that the order of the object files on the command line does matter in this case: the startup code must be placed first for proper linkage
tlink /m /v /s \Chapter3\startup.obj led.obj blink.obj,
Trang 3blink.exe, blink.map
As a result of the tlink command, Borland's Turbo Linker will produce two new files: blink.exe and blink.map in the working directory The first file contains the
relocatable program and the second contains a human-readable program map If you have never seen such a map file before, be sure to take a look at this one
before reading on It provides information similar to the contents of the linker script described earlier However, these are results and, therefore, include the lengths of the sections and the names and locations of the public symbols found in the relocatable program
One more tool must be used to make the Blinking LED program executable: a locator The locating tool we'll be using is provided by Arcom, as part of the
SourceVIEW development and debugging package included with the board
Because this tool is designed for this one particular embedded platform, it does not have as many options as a more general locator.[4]
In fact, there are just three parameters: the name of the relocatable binary image, the starting address of the ROM (in hexadecimal) and the total size of the
destination RAM (in kilobytes):
tcrom blink.exe C000 128
SourceVIEW Borland C ROM Relocator v1.06
Copyright (c) Arcom Control Systems Ltd 1994
Relocating code to ROM segment C000H, data to RAM segment 100H
Changing target RAM size to 128 Kbytes
Opening 'blink.exe'
Startup stack at 0102:0402
PSP Program size 550H bytes (2K)
Target RAM size 20000H bytes (128K)
Target data size 20H bytes (1K)
Creating 'blink.rom'
ROM image size 550H bytes (2K)
The tcrom locator massages the contents of the relocatable input file—assigning base addresses to each section—and outputs the file blink.rom This file contains
an absolutely located binary image that is ready to be loaded directly into ROM But rather than load it into the ROM with a device programmer, we'll create a special ASCII version of the binary image that can be downloaded to the ROM
Trang 4over a serial port For this we will use a utility provided by Arcom, called bin2hex
Here is the syntax of the command:
bin2hex blink.rom /A=1000
This extra step creates a new file, called blink.hex, that contains exactly the same information as blink.rom, but in an ASCII representation called Intel Hex Format
[1] Used this way, the term "target platform" is best understood to include not only the hardware but also the operating system that forms the basic runtime
environment for your software If no operating system is present—as is sometimes the case in an embedded system—the target platform is simply the processor on which your program will be run
[2] Beware that I am only talking about static linking here In non-embedded environments, dynamic linking of libraries is very common In that case, the code and data associated with the library routine are not inserted into the program
directly
[3] It is interesting to note that Borland's C++ compiler was not specifically
designed for use by embedded software developers It was instead designed to produce DOS and Windows-based programs for PCs that had 80x86 processors However, the inclusion of certain command-line options allows us to specify a particular 80x86 processor—the 80186, for example—and, thus, use this tool as a cross-compiler for embedded systems like the Arcom board
[4] However, being free, it is also a lot cheaper than a more general locator
Chapter 4 Downloading and Debugging
4.1 When in ROM
4.2 Remote Debuggers
4.3 Emulators
4.4 Simulators and Other Tools
I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs
—Maurice Wilkes, Head of the Computer Laboratory of the University of
Cambridge, 1949
Trang 5Once you have an executable binary image stored as a file on the host computer, you will need a way to download that image to the embedded system and execute
it The executable binary image is usually loaded into a memory device on the target board and executed from there And if you have the right tools at your
disposal, it will be possible to set breakpoints in the program or to observe its execution in less intrusive ways This chapter describes various techniques for downloading, executing, and debugging embedded software
4.1 When in ROM
One of the most obvious ways to download your embedded software is to load the binary image into a read-only memory device and insert that chip into a socket on the target board Obviously, the contents of a truly read-only memory device could not be overwritten However, as you'll see in Chapter 6, embedded systems
commonly employ special read-only memory devices that can be programmed (or reprogrammed) with the help of a special piece of equipment called a device
programmer A device programmer is a computer system that has several memory sockets on the top—of varying shapes and sizes—and is capable of programming memory devices of all sorts
In an ideal development scenario, the device programmer would be connected to the same network as the host computer That way, files that contain executable binary images could be easily transferred to it for ROM programming After the binary image has been transferred to the device programmer, the memory chip is placed into the appropriately sized and shaped socket and the device type is
selected from an on-screen menu The actual device programming process can take anywhere from a few seconds to several minutes, depending on the size of the binary image and the type of memory device you are using
After you program the ROM, it is ready to be inserted into its socket on the board
Of course, this shouldn't be done while the embedded system is still powered on The power should be turned off and then reapplied only after the chip has been carefully inserted
As soon as power is applied to it, the processor will begin to fetch and execute the code that is stored inside the ROM However, beware that each type of processor has its own rules about the location of its first instruction For example, when the Intel 80188EB processor is reset, it begins by fetching and executing whatever is stored at physical address FFFF0h This is called the reset address, and the
instructions located there are collectively known as the reset code