2
BUILDING PROCESS FOR EMBEDDED SYSTEMS
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILDING PROCESS FOR EMBEDDED SYSTEMS
Edit-Test-Debug Cycle implementation phase of the
development process
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILDING PROCESS FOR EMBEDDED SYSTEMS
Embedded systems programming is not substantially different
from the programming you've done before.
The only thing that has really changed is that you need to have
an understanding of the target hardware platform. Furthermore,
each target hardware platform is unique.
Unfortunately, this uniqueness among hardware platforms leads
to a lot of additional software complexity, and it's also the
reason you'll need to be more aware of the software build
process than ever before.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILDING PROCESS FOR EMBEDDED SYSTEMS
When build tools run on the same system as the program they
produce, they can make a lot of assumptions about the system.
This is typically not the case in embedded software development,
where the build tools run on a host computer that differs from the
target hardware platform.
Embedded software development tools, can rarely make
assumptions about the target platform.
Instead, the user must provide some knowledge of the system to the
tools by giving them more explicit instructions.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILDING PROCESS FOR EMBEDDED SYSTEMS
Software Development is performed on a Host computer
Compiler, Assembler, Linker, Locator, Debugger
Produces executable binary image that will run on Target Embedded
System
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILDING PROCESS FOR EMBEDDED SYSTEMS
Software Tools
1. Software Development Kit (SDK)
2. Source-code Engineering Software
3. RTOS
4. Integrated Development Environment (IDE)
5. Emulator
6. Editor
7. Interpreter
8. Compiler
9. Assembler
10. Cross Assembler
11. Locator
12. Testing and debugging tools
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
PROCESS FOR DEVELOPING EMBEDDED SOFTWARE
To develop software for a General Purpose Computer
Create source file
Type in C code
Build: compile and link
Execute: load and run
To develop software for an embedded system
Create source file (on Host)
Type in C code (on Host)
Compile/Assemble: translate into machine code (on Host)
Link: combine all object files and libraries, resolve all symbols (on Host)
Locate: assign memory addresses to code and data (on Host)
Download: copy executable image into Target processor memory
Execute: reset Target processor
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
PROCESS FOR DEVELOPING EMBEDDED SOFTWARE
The Embedded Software Development Process
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
PROCESS FOR DEVELOPING EMBEDDED SOFTWARE
SOURCE CODE INTO EXECUTABLE BINARY IMAGE
Each of the source files must be compiled or assembled into an object file
All of the object files that result from the first step must be linked together
to produce a single object file, called the re-locatable program.
Physical memory addresses must be assigned to the relative offsets within
the re-locatable program in a process called relocation.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
PREPROCESSING
Pre-processing is not a part of the compiler, but is a separate step
in the compilation process
Pre-processing is a process of running a set of instructions provided
by the programmer explicitly as code before the program
compiles.
The pre-processor provides the ability for the inclusion of header
files, macro expansions, conditional compilation, and line control.
Pre-processor instructions are called pre-processor directives, and
they all start with a hash symbol (#). Few examples: "#include",
"#define", "#line", and many more.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
COMPILING
Compiler translate programs written in some human-readable
language into an equivalent set of op-codes (or machine
language) for a particular processor.
Compiler performs conversion of Source Code --> Object file
Object file is binary file that contains set of machine-language
instructions (opcodes) and data resulting from language translation
Process
Each processor has its own unique machine language, so you
need to choose a compiler that produces programs for your
specific target processor.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
CROSS COMPILING
In the embedded systems case, compiler almost always runs
on the host computer.
A Native-compiler runs on a computer platform and produces
code for that same computer platform
A Cross-compiler runs on one computer platform and
produces code for another computer/target platform
The use of a cross-compiler is one of the defining features of
embedded software development.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
COMPILER - EXAMPLE
The GNU C compiler (gcc) and assembler (as) can be
configured as either native compilers or cross-compilers.
These tools support an impressive set of host-target
combinations.
The gcc compiler will run on all common PC and Mac
operating systems.
The target processor support is extensive, including AVR, Intel
x86, MIPS, PowerPC, ARM, and SPARC.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
COMPILER – OBJECT FILE FORMAT
Regardless of the input language (C, C++, assembly, or any
other), the output of the cross-compiler will be an object file.
Although parts of this file contain executable code, the object
file cannot be executed directly.
The contents of an object file can be thought of as a very
large, flexible data structure.
The structure of the file is often defined by a standard format
such as the Common Object File Format (COFF) or Executable
and Linkable Format (ELF).
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
COMPILER – OBJECT FILE
Most object files begin with a header that describes the sections
that follow.
Each of these sections contains one or more blocks of code or
data that originated within the source file you created.
However, the compiler has regrouped these blocks into related
sections.
For example, in gcc
text - all of the code blocks are collected into this section,
data - initialized global variables (and their initial values) into this section
bss - uninitialized global variables into this section.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
COMPILER – SYMBOL TABLE
There is also usually a symbol table somewhere in the object file
that contains the names and locations of all the variables and
functions referenced within the source file.
Parts of this table may be incomplete, however, because not all of
the variables and functions are always defined in the same file.
These are the symbols that refer to variables and functions defined
in other source files.
And it is up to the linker to resolve such unresolved references.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LINKER
All of the object files resulting from the compilation in step one must
be combined.
The object files themselves are individually incomplete, some of
the internal variable and function references not yet been resolved.
The job of the linker is to combine these object files and, in the
process, to resolve all of the unresolved symbols
By merging the text, data, and bss sections of the input object files,
the linker creates a new object file that contains all of the code
and data from the input object files.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LINKER
When the linker is finished executing, all of the machine language
code from all input object files will be in text section of the new file.
And all of the initialized and uninitialized variables will reside in the
new data and bss sections, respectively.
After merging all of the code and data sections and resolving all of
the symbol references, the linker produces an object file that is a
special “relocatable” copy of the program.
In other words, the program is complete except for one thing: no
memory addresses have yet been assigned to the code and data
sections within.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOCATOR
The tool that performs the conversion from relocatable program to
executable binary image is called a locator.
You have to do most of the work in this step yourself, by providing
information about the memory on the target board as input to the
locator.
The locator uses this information to assign physical memory
addresses to each of the code and data sections within the
relocatable program.
It then produces an output file that contains a binary memory
image that can be loaded into the target.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOCATOR
The output of this final step of the build process is a binary image
containing physical addresses for the specific embedded system.
This executable binary image can be downloaded to the
embedded system or programmed into a memory chip.
There is a separate development tool, called a locator, to assign
addresses. However, in the of GNU tools, this feature is built into the
linker (ld).
The memory information required by the GNU linker can be passed
to it in the form of a linker script.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOCATOR - EXAMPLE
example of a linker script
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOCATOR - EXAMPLE
The first executable instruction is ENTRY command, which appears
on the first line and the entry point is the function main.
This script informs the GNU linker’s built-in locator about the
memory on the target board, which contains 64 MB of RAM and 16
MB of flash ROM.
The linker script file instructs the GNU linker to locate the data, bss,
and text sections in RAM starting at address 0x00400000.
Names in the linker command file that begin with an underscore
(e.g., _DataStart) can be referenced similarly to ordinary variables
from source code.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOCATOR - EXAMPLE
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 addresses as _DataStart and
_DataEnd.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
In this section, we show an example build procedure for the Arcom
VIPER-Lite development board.
If another hardware platform is used, a similar process should be
followed using the tools and conventions that accompany that
hardware.
Once the tools are installed, the commands covered in the
following sections are entered into a command shell.
For Windows users, the command shell is a Cygwin bash shell
(Cygwin is a Unix environment for Windows); for Linux users, it is a
regular command shell.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
COMPILE
First we look at the individual commands in order to manually
perform the three separate tasks (compiling, linking, and locating)
Later, we will learn how to automate the build procedure with
makefiles.
The Blinking LED example consists of two source modules: led.c
and blink.c.
The first step in the build process is to compile these two files.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
COMPILE
The basic structure for the gcc compiler command is:
The command-line options we’ll need are:
-g To generate debugging info in default format
-c To compile and assemble but not link
-Wall To enable most warning messages
-I../include To look in the directory include for header files
Here are the actual commands for compiling:
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
COMPILE
We broke up the compilation step into two separate commands,
but you can compile the two files with one command.
To use a single command, just put both of the source files after the
options. If you wanted different options for one of the source files,
you would need to compile it separately as just shown.
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 .o.
So if all goes well, there will now be two additional files—led.o and
blink.o—in the working directory.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
LINK AND LOCATE
We now have the two object files—led.o and blink.o—that we need
in order to perform the second step in the build process.
As we discussed earlier, the GNU linker performs the linking and
locating of the object files.
For the third step, locating, there is a linker script file named
viperlite.ld that we input to ld in order to establish the location of
each section in the Arcom board’s memory.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
LINK AND LOCATE
The structure for the linker and locater ld command is:
The command-line options we’ll need for this step are:
-Map blink.map To generate a map file and use the given filename
-T viperlite.ld To read the linker script
-N To set the text and data sections to be readable and writable
-o blink.exe To set the output filename (if this option is not included, ld will
use the default output filename a.out)
The actual command for linking and locating is:
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
LINK AND LOCATE
The order of the object files determines their placement in memory.
Because we are not linking in any startup code, the order of the
object files is irrelevant.
If startup code were included, you would want that object file to be
located at the proper address.
The linker script file can be used to specify where you want the
startup routine (and other code) to reside in memory.
Furthermore, you can also use the linker script file to specify exact
addresses for code or data, should you find it necessary to do so.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
LINK AND LOCATE
As you can see in this command, the two
object files—led.o and blink.o—are the last
arguments on the command line for linking.
The linker script file, viperlite.ld, is also
passed in for locating the data and code in
the Arcom board’s memory.
The result of this command is the creation of
two files—blink.map and blink.exe—in the
working directory.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD
LINK AND LOCATE
The .map file gives a complete listing of all code and data
addresses for the final software image.
It provides information similar to the contents of the linker script
described earlier.
However, these are results rather than instructions and therefore
include the actual lengths of the sections and the names and
locations of the public symbols found in the relocatable program.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LINKER MAP FILES
The linker map file provides valuable information that can help you
understand and optimize memory.
The map file is a symbol table for the whole program.
The most straightforward pieces of information in the map file are the
actual memory regions, with location, size and access rights granted to
those regions
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LINKER MAP FILES
Linker script and memory map section contains a breakdown of the
memory contribution of each and every file that was linked into the final
image.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
Previously, we saw how the code or software to be executed on
the embedded system (target board) is written on a computer.
The resulting code created after subjecting it to be build process is
called the binary executable image or simply hex code.
This topic explains how the hex code is loaded on the target board
which is referred as downloading
And what are the various possible ways of debugging a code
meant to run on a embedded system.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
There are two ways of
downloading the binary image
on the embedded system:
1. Using a Device Programmer
2. In-system programming (ISP)
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
1. Using a Device Programmer:
Step 1: Once the binary image is ready on the computer, the device
programmer is connected to the computer.
Step 2: The uP/uC or memory chip, usually the ROM which is
supposed to contain the binary image is placed on the proper socket
on the device programmer.
Step 3: The device programmer contains a software interface through
which the user selects the target uP/uC for which the binary image
has to be downloaded.
Step 4: The Device programmer then transfers the binary image bit by
bit to the chip.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
1. Using a Device Programmer:
uP/uC/Memory Chip
Host Computer
Device Programmer
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
2. Using In System Programmer(ISP):
Certain Target embedded platforms uses a piece of hardware called
ISP that have a hardware interface to both the computer as well the
target board’s chip where the code is to be downloaded.
ISP is also called in-circuit serial programming (ICSP), is the ability of
programming the embedded processor/controller while it is installed
in a complete system, rather than requiring the chip to be
programmed prior to installing it into the system.
It also allows firmware updates to be delivered to the on-chip
memory of microcontrollers and related processors without requiring
specialist programming circuitry on the circuit board, and simplifies
design work
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
LOADING ON THE TARGET
2. Using In System Programmer(ISP):
The user through the ISP’s software interface sends the binary image
to the target board. This avoids the requirement of frequently
removing the microprocessor / microcontroller or ROM for
downloading the code if a device programmer had to be used.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
SIMULATOR
Simulator is a host-based program that simulates functionality and
instruction set of target processor.
The front-end has text or GUI-based windows for source code,
register contents, etc.
Simulators are valuable during early stages of development.
Disadvantage of this method is that, it only simulates the processor,
and not the peripherals.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
REMOTE DEBUGGER
Remote debuggers are one of the commonly used downloading
and testing tools during development of embedded software
It is used to monitor/control embedded SW. It is used to download,
execute and debug embedded software over a comm. link.
The program running on the host of a remote debugger has a user
interface (GUI/Command-line) that looks just like other debugger
The front-end of the GUI debuggers contain several windows to
show the active part of the source code, current register contents,
and other relevant information about the executing program.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
REMOTE DEBUGGER
Backend provides low-level control of target processor, runs on
target processor and communicates to the front-end over a
communication link.
Debugger and software being debugged are executing on two
different computer systems.
-Start/restart/kill, and stepping through program.
- Software breakpoints.
- Reading/writing registers or data at specified address.
Disadvantage: inability to debug startup Code, code must execute from
RAM, requires a target processor to run the final software package
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
Emulation refers to the ability of a computer program or electronic
device to imitate another program or device.
An emulator is a piece of hardware/software that enables one
computer system to run programs that are written for another
computer system.
An in-circuit emulator (ICE) provides a lot more functionality than a
remote debugger.
In addition to providing the features available with a remote
debugger, an ICE allows you to debug startup code and programs
running from ROM, etc.,
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
In-Circuit Emulator (ICE) takes the place of the target processor. It
contains a copy of target processor, plus RAM, ROM, and its own
embedded software.
It allows you to examine the state of the processor while the
program is running. It uses the remote debugger for human
interface.
ICE provides greater flexibility, ease for developing various
applications on a single system in place of testing that multiple
targeted systems. Disadvantage of this method is that, it is
expensive.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
