EE3376 Glossary of Terms
.abs (Absolute) Files- This is the final output of the linking stage and always has a .abs extension. The .abs file contains the essential executable information (machine code, data, memory locations, etc.) as well as some debugging information. The file is called 'absolute' because the memory locations of the data and code have been set by the linking process and are not relocatable. The .abs files can be run directly in the simulator, or converted to a final format such as an S-record that can be loaded into the HCS12.
> Note that the related term "absolute assembly" refers to creating an assembly source code program that uses absolute rather than relocatable addresses. Here, the address of the code and data is specified in the .asm source code file, and linker does not need to locate the machine code.
Access Paths - These are the directory paths used by the IDE to locate or access the various files of a project. They can be listed as relative paths, such as {Project} which is relative to the current project, or as absolute paths (the latter should be avoided if portability is an issue). Paths are searched in order, and the first occurence of a file is used. A recursive search on a path searches all the subdirectories of the path (easy to do, but search order not specified and name collisions are thus possible). For each file in a project, you can use the Project Inspector to see the path used for that file.
.asm (Assembly) files - .asm files are assembly source code files, which are text files that consist of assembly language instructions, labels, comments, directives, etc.
Assembler - The assembler is a software program that takes human-readable source code and through various algorithms converts it into an object file (usually ELF format). The object file is an intermediate file which contains machine code, headers, etc. and must be further processed by the linker, loader, etc. until the final executable is created. The assembler is built into Code Warrior.
Bad Code - Any code written by someone else.
.bbl (Batch Burner Language) Files - "batch burner language" files are command files used by the burner to create binary files, such as S-records, from .abs files. The .bbl files can also be used to create Intel hex and other binary file formats that are used by various loaders.
Build Target - In Code Warrior, the build target is the collection of files and settings used to generate (or build) an output or executable file. In this course, we usually have two build targets - one for the simulator and one that actually runs on the HCS12 chip. For each build target, we usually generate a single file, such as a .abs file that we run on the Simulator or an S-record (.s1) file that we load into the HCS12. A build target is analogous to a makefile (see below), and is used by the "Make" command to automate the build process.
Burner - This is the name of the software component of Code Warrior which converts a .abs file into a format, such as an S-record, that can be handled by an EPROM burner or DBug12 loader. The burner uses a command file with extension .bbl (batch burner language) for details of how to generate the file. In addition to the S-record format, the burner can also create files in Intel hex format, etc.
Code Warrior - Code Warrior is a software program from Metrowerks that forms a complete development environment for the HCS12. The Code Warrior IDE (Integrated Development Environment) runs on a PC, and is used to develop programs that can be run on the HCS12 chip or in the simulator. The IDE is an "all in one" windowed environment that allows you to easily create and manage your projects. It has a built-in text editor, assembler, C compiler, linker, burner, debugger, simulator and other useful tools. With the IDE, you can go through all of the steps needed to create a final program that is ready to download to the HCS12 or the simulator.
Code Warrior Executables - The various parts of Code Warrior are often referred to using generic terms such as the "linker" or the "assembler". The actual programs that implement the various functionalities are as follows. Assembler = ahc12.exe; Burner = burner.exe; C Compiler = chc12.exe; Decoder = decoder.exe; Make utility = maker.exe; Smart Linker (linker) = linker.exe; Simulator = hiwave.exe. Most of these are located in the "prog/" folder of the base Code Warrior folder. The actual program that launches Code Warrior itself is called "IDE.exe" and is located in the "bin/" folder of the base Code Warrior folder. This information may be useful for setting up various paths, etc.
Cross-development - This is the term used to describe an environment where program development is done on a host PC and the executable program is run on a separate target system such as an HCS12 chip.
D-Bug12 - D-Bug12 is a software program that is burned into the Flash memory of the HCS12 chip and by default runs when the chip is first powered on. It is an example of a type of program called a "monitor" program that runs on-chip for use in debugging. Using a serial communication program such as Hyperterminal on the host PC, you can interact with the target HCS12 chip using commands built into D-Bug12. For instance, you can use D-Bug12 to run programs, view register contents, view memory, etc. D-Bug12 also includes a loader routine which can be used to transfer an S-record executable image from the host PC to the target HCS12.
Debugger - A debugger is a software program that aids in finding errors or problems in a program.
Decoder - The Decoder is the Code Warrior version of a disassembler, and converts object or absolute files into an assembly source code listing file. If the original code was in C, then it shows the original C code as well as the assembly instruction equivalent of the C code (which can be a great way to dissect a C program). See also the "Disassembler" entry below.
Development Cycle - The development cycle to create an executable program in Code Warrior is based on three essential steps: Edit > Build > Debug. In the Edit stage, we create the source code, header files and linker files. In the Build stage we assemble and link the program, and often burn or load the program as well if the target is hardware. In the critical debug stage, we load the program into a Simulator or into a hardware target (the hardware target is often configured to communicate with the Debugger program). We then test the program under a variety of real-world circumstances to make sure it works OK, and correct any errors we find. The corrections require that we go back to the edit and build stages. After many iterations, a stable, properly functioning program is realized. The final debugged program is often called the release version.
Disassembler - A disassembler is basically the opposite of an assembler: it converts an object or absolute file into a listing file which gives the assembler instructions corresponding to the machine code. See also the "Decoder" entry above.
DWARF - DWARF is also a standard file format for the information generated by compilers, assemblers and linkers that are necessary for symbolic source-level debugging. We usually save everything in an ELF/DWARF 2.0 format for this class.
EEPROM - See ROM.
ELF - Is an acronym that stands for Extensible Linking and Format. This is a standard file format for object files. In addition to machine code, an ELF object file contains headers and other information used by the linker to create the final .abs program. There are other types of object file formats such as COFF (Common Object File Format), but ELF is very common for embedded systems. We usually save everything in an ELF/DWARF 2.0 format for this class.
Embedded Systems - This refers to a microprocessor or microcontroller that is an essential part of an item but is hidden away or embedded, in the item or product. Microcontrollers therefore are part of a larger class of systems called embedded systems.
Executable - The 'executable' is the final program that resides in the target system memory and runs on the target system (the HCS12 for us). The executable program is essentially a linear array of bytes in memory, each byte containing binary machine code instructions or data. The program runs by sequentially stepping through the machine code instructions, with occasional jumps or branches to various locations.
> Note that the term "executable" is often used in slightly different ways. Strictly speaking, the executable is the actual program sitting in the memory of the HCS12. But the .abs file mentioned above is often considered a type of executable since it does contain the machine code in finalized form and can run directly in the Simulator (it also contains overhead data such as debug info). The S-records created from a .abs file also contain the finalized machine code along with some overhead data. Since absolute files and S-records contain all the executable information but actually sit in the host PC, they are often referred to as an image of the executable, or simply as an "executable image".
FLASH - FLASH is a type of ROM memory. It is more specifically a special type of EEPROM, but can only be erased in large blocks instead of one byte at a time. FLASH is cheaper than conventional EEPROM, and forms the bulk of memory on the HCS12. It is often used to hold executable code since such code does not change during regular program execution. As an example, D-Bug12 resides in the FLASH memory of the HCS12.
Host - The host is the desktop computer or workstation that we use to develop programs which are then transferred or downloaded to the target system.
Linker - The linker merges the various object files of an application into one file, called an absolute file (or .abs file for short) in Code Warrior. The linker also resolves addresses of the object files. The absolute file produced by the linker contains essential executable information such as machine code and data, and the fixed addresses where they will reside in the memory of the target system. The absolute file also has some debugging information. The linker in Code Warrior is referred to as the 'Smart Linker' because it can determine which parts of a project actually need to be linked together to create the final .abs file.
Loader - The loader is a program which transfers the machine code and data from an executable image to the correct locations in the target system memory. Loading is the last step in the overall process of generating an executable program. A common loader is the "load" utility used in D-Bug12 to transfer an S-record from a PC to an HCS12 via the serial port. After the loader runs, the executable program now resides as machine code in the memory of the HCS12, and the program can be run on the HCS12 as desired.
Machine Code - This is the actual binary code that sits in the memory of the HCS12 and controls the digital circuitry of the HCS12. The machine code usually consists of an opcode followed by an operand. For instance, the instruction 'LDAA $12' generates machine code $8612, where $86 is the opcode, and $12 is the operand. The machine code is generated directly from the assembly instructions.
Make (and makefile) - "Make" is a utility program that automates the various steps needed to create an executable program. It takes information from the various aspects of a build target (assembler options, linker options, etc.) and integrates them into a single process. Though designed for large projects, "Make" is used for small projects as well.
> Note that while the configuration information for "Make" is called the "Build Target" in Code Warrior, in many other systems the configuration file is a text file called a "makefile". The "makefile" contains essential information such as file names, paths, assembler and link options, etc. that are needed for "Make" to automate the build process.
Microcontroller - A special purpose VLSI chip that includes a microprocessor with built memory (RAM, ROM and/or FLASH) and I/O peripherals such as timers, analog-digital converters, serial ports, etc. A microcontroller is meant to be a standalone system that interfaces the outside world to an intelligent microprocessor, and requires minimal external hardware to function properly.
Number Format - Motorola uses unique number format identifiers for assembly instructions. Hexadecimal numbers are prefixed with a "$", binary with "%" and no format identifier is used for decimal format. So, in Motorola notation, 0x42 (hex) is designated as $42, 01101110 (binary) is %01101110, and 62 (decimal) is simply written as 62.
.o (Object) Files - Object files are intermediate files created by an assembler or compiler. The assembler or compiler takes the human-readable source code and through various algorithms converts it into binary code that will loaded into the target system and executed. The object file contains machine code, relative address assignments, headers, etc. The linker will read and link together object files to create an absolute .abs file (see above). Object files usually have a ".o" extension.
.prm (Parameter) Files - The .prm file is a parameter or command file used by the linker during the link stage of the build process. The .prm file specifies where in memory the various sections will be located. For instance the code sections of source file (the part containing the actual assembly language instructions) might be assigned to be located in ROM at address $0400 - $0FFF, and the variable data might be in RAM located at $1000 - $3FFF. The .prm file also contains the entry location of the file, where the program should start executing.
Project - This is a term associated with Code Warrior. A project is a "superfile" which contains all the source, linker and debugger files associated with an executable program you are going to create. A project has a .mcp extension. Note that within a project, you can have several types of build targets which share the source files and all. The labs you do as part of this course will typically be stored as project files, eg, lab3.mcp.
RAM - Is an acronym that stands for "Random Access Memory". RAM is volatile memory whose contents disappear when power is removed. There are different types of RAM, and that type on the HCS12 chip is static RAM, which is very fast and does not require continuous refreshing as does the (S)DRAM (Synchronous Dynamic Random Access Memory) chips often found in PCs or workstations. RAM is typically used for storage of dynamic variables whose value changes when a program is run.
Relocatable Assembly - This refers to writing an assembly program where the linker takes care of setting the addresses of the code and data. Basically, sections are defined in the source code, and these sections are then assigned memory addresses (called "segments") in the linker parameter (.prm) file. Relocatable assembly is more portable than absolute assembly - you write the source code for any HC(S)12 system, and then by simply changing the linker file you can control the memory location the code will be loaded into.
ROM - Is an acronym that stands for 'Read Only Memory'. ROM is non-volatile and the memory contents will remain even after power has been removed. ROM is typically used to hold the executable code that runs on the HCS12 when it is powered on, or to hold calibration constants, serial numbers, etc. and other constant data that are rarely if ever changed. ROM is easily read by the microprocessor, but it requires special circuitry to rewrite the memory contents of ROM. There are several types of ROM, but the type we use on the HCS12 is conventional EEPROM (Electrically Erasable Read Only Memory) which uses electrical pulses from an on-board charge pump to erase memory contents. EEPROM is similar to FLASH memory, but whereas EEPROM can be erased one byte at a time, FLASH must be erased in large blocks.
.s1 and .sx (S-record) Files - These are file extensions for files in S-record formats. See "S-records" below. .
Section - A logical section is a named group of objects declared in the source file. In the linker’s parameter file, each section is associated with a segment so the linker knows where to allocate the objects belonging to a section (see below for segment).
Segment - A segment is physical memory range that holds specific sections of the program, and is specified in the linker parameter file. For instance, programs often have a ROM segment for code and constant data and a RAM segment for variable data.
Simulator - The Simulator is a software program included in Code Warrior that runs on your PC and simulates what the HCS12 does. You can run and debug a program in the simulator environment without ever connecting to an HCS12 system.
Source Code/File - The source file is the text file that the programmer initially writes to create a program, and the source code is the code contained within this file (the assembly instructions, data definitions, etc.). A source file could be an assembly file with a .asm or .s suffix, or it could be a C file with a .c suffix.
S-records - S-records are a standard file format used by Motorola for the transfer of executable images from a host PC to a target system. In addition to the actual machine, the S-records contain overhead data such as destination address of the machine code and checksums to verify error-free transmission. In this class, we load the S-records from the host PC to the target HCS12 using a loader such as that in DBug12. There are several types of S-records, but the type we use have .s1 or .sx extensions. If a file has a .s1 extension, then it means we explicitly set the S-record to be type S1. If it has a .sx extension (default), then the burner will automatically choose the S-record type based on the highest address set in the .bbl file. S-records in systems other than Code Warrior often have a .s19 extension.
Stationery - This is a Code Warrior term for a project template that can be used as the basis for creating other projects for a specific platform. Projects listed in the "Stationery" folder of the Code Warrior home folder can be used as Stationery.
Target - The target is the target system we are going to run the final program on. In this class, the target is usually the HCS12 microcontroller on the Dragon12 board, though sometimes the target is the Code Warrior Simulator.
Touch - To "touch" a file means to mark it for re-assembly or re-compilation. When a source file is changed, it is automatically "touched" and will be assembles or compiled during the next "make" call. Unchanged/untouched files are not re-assembled since they already have object files. Touched files are marked with a green check mark in the Project window.
