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, blink.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.
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 over 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.
Chapter 4. Downloading and Debugging
4.1 When in ROM
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.