Creating a program for a microcontroller is a bit more involved than creating a program for a PC. When you create a program for the PC, you are developing it using the same type of computer system the program will run on. So you write your program code, compile it and then run the program on your PC or a similar PC. The point is that the host system (where development is done) is the same as the target system (where the program will run). The host in a sense "knows" everything about the target system since they are the same.

 

 

 

Steps to Generate An Executable Program

 

The final program that runs on the HCS12 target computer is called an executable program or simply an "executable". The steps to generate an executable program for the HCS12 are briefly described below. The development system we use to create the executable is a fully integrated environment called "Code Warrior" from Metrowerks (we use Code Warrior Special Edition for the HCS12, v.3). The discussion below applies specifically to Code Warrior, but other development systems operate in a similar fashion.

 

   1. You first create an assembly program using a text editor such as the Code Warrior built-in editor. The assembly program that you write is a text file that consists of assembly language statements, directives, etc. The file extension of the assembly program is ".asm" for the Code Warrior assembler, but is often ".s" for other assemblers. The assembly code is called source code and the assembly program file is usually called a source file.

 

 

      > To understand the assembly-to-machine language conversion, consider what you did in the intro lab using D-Bug12. Using the "asm" command, you entered an "LDAA #$02" instruction. The binary (hex) form of this is "8602" which you can see in the D-Bug12 session when you entered the command using "asm". The hex number "8602" is the actual binary machine code that the HCS12 uses in its digital circuitry to transfer the hex number $02 to accumulator A. The assembler also converts directives, sets certain addresses etc. These more advanced topics will be discussed in a later lecture.

      > Note that the assembler program we are using resides on the "host" computer (your PC) but creates a program for a different type of computer called a "target" (the HCS12 here), so the assembler we are using is often called a "cross-assembler".

 

   3. The .o object file created by the assembler is an intermediate file that has the essential HCS12 machine language, but it still needs to be modified somewhat. For instance, it may need to be combined or linked with other object code files, such as library routines, to create the final program that will actually run on the microcontroller. It may also need to resolve addresses which are not known until other files are linked with it.

 

      The job of the linker is to create a complete machine code file that is (almost) ready to run on the HCS12. The linker does this by filling in the unresolved addresses and by linking related programs to create the final program. The file created by the linker is a called an absolute file and has a .abs file extension. The absolute file contains the executable machine code that will be used by the HCS12, and it also has overhead information such as address assignments for the code, etc. The .abs file that we generate with the linker is sometimes called an executable image since it has all the essential machine code but doesn't yet sit on the target system. This executable image will be transferred to the HCS12 after one more transformation.

 

   4. In the next step, we convert the absolute .abs file into a form suitable for a loader to use. The loader is a program that will transfer the executable program from the PC to the HCS12. The loader requires that the executable machine code in the .abs file be formatted in a certain way. We do this by converting the executable machine code information in the .abs file into short chunks of code, called "S-records" by Motorola. Each S-record is a line of text containing a header, the address where the machine code will be loaded, the machine code itself, and some extra checksum bits to make sure that the transfer was successful. The final program that we will download to the HCS12 consists of a bunch of these S-records in one file which has a file extension ".s1" or ".sx". The Code Warrior program that converts the .abs file into the .s1/.sx file format is called the burner program. It references a command file with an extension ".bbl" (for batch-burner language) that tells the burner in detail how to generate the S-record. S-records are described in more detail here.

 

   5. Finally, we must transfer the .s1 file from the host PC to the target HCS12 microcontroller. This is done using a program called a loader. There are several types of loaders depending on the connection between the host PC and the target system, and depending on the format of the file to be transferred. The loader that we is the D_bug12 "load" program that reads the S-records of the .s1 file and transfers the machine code to the desired memory locations in the HCS12. D-Bug12 does this by transferring one line at a time from the PC to the HCS12, each line being one of the S-records of the .s1 file. For each S-record, the machine code is transferred to the desired memory location on the HCS12, and then the line-transfer is checked to make sure there were no errors. The next line is then transferred. When the loader has successfully completed the transfer, you now have an executable program residing on the HCS12 which can be run. Note that if we use the Simulator, we do not need to generate an .s1 or .sx files since it uses the .abs files directly.

 

   6. Once the executable program is in the HCS12 memory, we can then run it as desired. If we are using D-Bug12, we simply use the ">go $address" command where "$address" is the hex address where the program begins execution. The "$address" value is loaded into the Program Counter register, and corresponds to the memory address where the first line of code in the program is located. Alternatively, the program might be downloaded into ROM such that when the HCS12 is reset or powered on, it automatically jumps to the program start and begins executing code there.

 

In summary, to create an executable program that will run on an HCS12, you: (1) create a text file having the assembly source code; (2) assemble this into an object file with the assembler; (3) link the object file into an absolute file using the linker; (4) convert the absolute file into s-record format using the burner program; (5) download the s-record to the HCS12 using Hyperterminal and the D-Bug12 "load" command; (6) and finally, once the executable program is in the HCS12 memory, it can then be run as desired. Alternatively, you can simulate running and debugging the program by opening the .abs file directly with the Simulator. The steps are graphically outlined in the figure below for a single .asm source file using absolute assembly. Note that the linker is bypassed if absolute assembly is used.

 

 

 

Overview of The Assembly Process

 

 

A Final Comment

 

The programs you create in Code Warrior are done in the context of a project. A project is a "superfile" which contains all the source, linker and debugger files associated with an executable program you are going to create. So, when we say we are creating a Code Warrior program, we actually end up creating a project. A project has a .mcp extension, and the labs you do as part of this course will typically be stored as project files, eg, lab3.mcp.

 

Note that we often simplify the steps above using a "make" or "build" process. "Make" is a utility program that will, with one command, automatically assemble, link, burn and even load an executable. "Make" reads a configuration file called a "makefile" which contains details of which files to use, where they are located, options for the assembly process, options for the link process, etc. In Code Warrior, the term "build target" is analogous to a "makefile". In this class, there will usually be one build target for each project, ie, a target for the Dragon12 itself. In production environments, you might have several build targets, such as one for development board A, one for development board B, and another for the Simulator.

 

A detailed step-by-step procedure to create an executable in the context of a project is shown here using the Code Warrior development system. The overview above describes the build process conceptually as it occurs within the project.