Embedded Systems Module IV: Programming concepts of Embedded programming

MODULE IV

PROGRAMMING CONCEPTS OF EMBEDDED PROGRAMMING

Reference:

1. Shibu K.V., Introduction to Embedded Systems, McGraw Hill Education

2. Rajkamal, Embedded Systems Architecture, Programming and Design, TMH,2003

SOFTWARE IMPLEMENTATION

For embedded firmware development you can use either

1. Target processor/controller specific language (Assembly language) or
2. Target processor/ controller independent language (High level languages) or
3. Combination of Assembly and high level Language Assembly language based
development
Assembly Language Based Development
Assembly language programming is the task of writing processor specific machine
code in mnemonics form, converting the mnemonics into actual processor
instructions (machine language) and associated data using an assembler.

SOURCE FILE TO OBJECT FILE TRANSLATION

Conversion of assembly language into machine language is carried out by a sequence of
operations.
Translation of assembly code to machine code is performed by assembler.
 Each source module is written in assembly and is stored in .src or .asm file
 Each file can be assembled separately to examine the syntax errors and incorrect
assembly instructions
 On assembling of each .src/.asm file a corresponding object file is created with
extension .obj
 The object file does not contain the absolute address of where the generated code
needs to be placed on the program memory and hence it is called relocatable segment

1
Embedded Systems Module IV: Programming concepts of Embedded programming

Library file creation and usage

 Libraries are specially formatted, ordered program collection of object modules that
may be used by the linker later.
 When a linker processes a library, only those object modules in the library that are
necessary to create the program are used. Library files are generated with the
extension ‘.lib’
 Library file is source code hiding technique. If you don’t want to reveal the source
code behind the various functions you have written in your program and at the same
time you want them to be distributed to application developers for making use of
them in their applications, you can supply them as library files and give them the
details of the public functions available from the library.
 For using a library file in a project, add library to the project.

2
Embedded Systems Module IV: Programming concepts of Embedded programming

 If you are using a commercial version of assembler suit for your development, the
vendor of utility may provide you pre-written library files for performing
multiplication, floating point arithmetic, etc. as an add-on utility.

Linker and Locator

 Linker and locator are another software utility responsible for” linking the various
object modules in a multi module project and assigning absolute address to each
module”
 Linker generate an absolute object module by extracting the object module from the
library, if any and those obj files created by the assembler, which is generated by
assembling the individual modules of a project.
 It is the responsibility of the linker to link any external dependent variables or
functions declared on various modules and resolve the external dependencies among
the modules.
 An absolute object file or modules does not contain any re-locatable code or data.
 All code and data reside at fixed memory locations.
 The absolute object file is used for creating hex files for dumping into the code
memory of the processor/controller.
Object to Hex File Converter
 This is the final stage in the conversion of Assembly language to machine
understandable language
 Hex file is the representation of the machine code and the hex file is dumped into the
code memory of the processor
 Hex file representation varies depending on the target processor make
 For intel processor the target hex file format will be ‘Intel HEX’ and for Motorola, hex
file should be in ‘Motorola HEX’ format
 HEX files are ASCII files that contain a hexadecimal representation of target
application
 Hex file is created from the final ‘Absolute Object File’ using the Object to Hex file
Converter utility

3
Embedded Systems Module IV: Programming concepts of Embedded programming

 Advantage of Assembly Language Based Development

 Assembly language based development is the most common technique adopted from
the beginning of the embedded technology development

High Level Language Based Development

 Any High-level language with a supported cross compiler for the target processor can
be used for embedded firmware development
 Cross Compilers are used for converting the application development in high level
language into target processor specific assembly code
 Most commonly used language is C
 C is well defined easy to use high level language with extensive cross platform
development tool support

 The program written in any of the high level language is saved with the corresponding
language extension
 Any text editor provided by IDE tool supporting the high level language in use can be
used for writing the program

4
Embedded Systems Module IV: Programming concepts of Embedded programming

 Most of the high level language support modular programming approach and hence
you can have multiple source files called modules written in corresponding high
level language
 The source file corresponding to each module is represented by a file with
corresponding language extension
 Translation of high level source code to executable object code is done by a cross
compiler
 The cross compiler for different high level language for same target processor are
different
 Without cross-compiler support a high level language cannot be used for embedded
firmware development

Advantages of High Level Language based Development

 Reduced Development Time
– Developers requires less or little knowledge on the internal hardware details and
architecture of the target processor
– Syntax of high level language and bare minimal knowledge of memory organization
and register details of target processor are the only pre- requisites for high level
language based firmware development
– With High level language, each task can be accomplished by lesser number of lines
of code compared to the target processor specific assembly language based
development
 Developer Independency
– The syntax used by most of the high level languages are universal and a program
written in high level language can be easily be understood by a second person
knowing the syntax of the language
– High level language based firmware development makes the firmware , developer
independent
– High level language always instruct certain set of rules for writing code and
commenting the piece of code

5
Embedded Systems Module IV: Programming concepts of Embedded programming

 Portability
– Target applications written in high level languages are converted to target
processor understandable format by a cross compiler
– An application written in high level language for a target processor can be easily
converted to another target processor with little effort by simply recompiling the
code modification followed by the recompiling the application for the required
processor
– This makes the high level language applications are highly portable

Limitations of High level language based development

 Some cross compilers avail for the high level languages may not be so efficient in
generating optimized target processor specific instructions
 Target images created by such compilers may be messy and no optimized in terms
of performance as well as code size

Mixing Assembly and High-level Language

 High level language and assembly languages are usually mixed in three ways
1. Mixing assembly language with high level language
2. Mixing high level language with Assembly
3. In line assembly programming

1. Mixing Assembly Language with High level Language (Assembly Language

with ‘C’)
 Assembly routines are mixed with C in situations where entire program is written in
C and the cross compiler in use do not have built in support for implementing certain
features like Interrupt Service Routine or if the programmer want to take the
advantage of speed and optimized code offered by machine code generated by hand
written assembly rather than cross compiler generated machine code.

6
Embedded Systems Module IV: Programming concepts of Embedded programming

 When accessing certain low level hardware, the timing specification may be very
critical and a cross compiler generated binary may not be able to offer the required
time specifications accurately
 Writing the hardware access routine in processor specific assembly language and
invoking it from C is the most advised method to handle such situations

2. Mixing C and Assembly is little complicated in the sense

 the programmer must be aware of how parameters are passed from the C routine
to Assembly and
 values are returned from assembly routine to C and
 how the assembly routine is invoked from the C code
 These are cross compiler dependent
 There is no universal rule for it
 You must get the information from the documentation of cross compiler you are
using
 Different cross compilers implement these features in different ways depending
upon the general purpose registers and the memory supported by the target
processor

3.In line assembly programming

7
Embedded Systems Module IV: Programming concepts of Embedded programming

TESTING OF EMBEDDED HARDWARE

Testing is an organized process to verify the behavior, performance, and reliability of a device or
system against designed specifications. It ensures a device or system to be as defect-free as
possible.

Why Test?

The general reasons for testing are:

 To find bugs in software

 To reduce risk to both users and the company
 To reduce development and maintenance costs
 To improve performance

Types of Testing

Unit Testing.

Individual developers test at the module level. The unit module is either an isolated function or a
class. This is done by the development team, typically the developer and is done usually in the
peer review mode. The developers test with some average values, some high or low values, and
some out-of-range values

Regression Testing.

It isn’t enough to pass a test once. Every time the program is modified, it should be retested to
assure that the changes didn’t unintentionally create some unrelated behavior.

Regression tests are usually automated through a test script. For example, if you design a set of
100 input/output tests, the regression test script would automatically execute the 100 tests and
compare the output against a “gold standard” output suite. Every time a change is made to any part
of the program code, the full regression suite runs on the modified code to ensure that something
else wasn’t broken in the process.

Functional Test (Black Box Tests)

Functional testing is often called black-box testing because the test cases for functional tests are
devised without reference to the actual code—that is, without looking “inside the box.”

An embedded system has inputs and outputs and implements some algorithm between them.
Black-box tests are based on what is known about which inputs should be acceptable and how they
should relate to the outputs. Black-box tests know nothing about how the algorithm in between is
implemented. Example black-box tests include:

8
Embedded Systems Module IV: Programming concepts of Embedded programming

• Stress tests: Tests that intentionally overload input channels, memory buffers, disk controllers,
memory management systems, and so on.

• Boundary value tests: Inputs that represent “boundaries” within a range and input values that
should cause the output to transition across a similar boundary in the output range.

• Exception tests: Tests that should trigger a failure mode or exception mode.

• Error guessing: Tests based on prior experience with testing software or from testing similar
programs.

• Random tests: Generally, the least productive form of testing but still widely used to evaluate
the robustness of user-interface code.

• Performance tests: Because performance expectations are part of the product requirement,
performance analysis falls within the sphere of functional testing.

Coverage Tests (White Box Tests)

The weakness of functional testing is that it rarely exercises all the code. Coverage tests attempt
to avoid this weakness by (ideally) ensuring that each code statement, decision point, or decision
path is exercised at least once.

Also known as white-box tests, coverage tests are devised with full knowledge of how the software
is implemented.” White-box tests are designed with the source code handy.Because white-box
tests depend on specific implementation decisions, they can’t be designed until after the code is
written.

From an embedded systems point of view, coverage testing is the most important type of testing
because the degree to which you can show how much of your code has been exercised is an
excellent predictor of the risk of undetected bugs you’ll be facing later. Example white-box tests
include:

• Statement coverage: Test cases selected because they execute every Statement in the program at
least once.

• Decision or branch coverage: Test cases chosen because they cause every branch (both the true
and false path) to be executed at least once.

• Condition coverage: Test cases chosen to force each condition (term) in a decision to take on all
possible logic values.

Gray-Box Testing

9
Embedded Systems Module IV: Programming concepts of Embedded programming

Because white-box tests can be intimately connected to the internals of the code, they can be more
expensive to maintain than black-box tests. Whereas black-box tests remain valid as long as the
requirements and the I/O relationships remain stable, white-box tests might need to be re-
engineered every time the code is changed. Thus, the most cost-effective white-box tests generally
are those that exploit knowledge of the implementation without being intimately tied to the coding
details.

Tests that only know a little about the internals are sometimes called gray-box tests. Gray-box
tests can be very effective when coupled with “error guessing.” If you know, or at least suspect,
where the weak points are in the code, you can design tests that stress those weak points.

These tests are gray box because they cover specific portions of the code; they are error guessing
because they are chosen based on a guess about what errors are likely.

This testing strategy is useful when you’re integrating new functionality with a stable base of
legacy code. Because the code base is already well tested, it makes sense to focus your test efforts
in the area where the new code and the old code come together.

10
Embedded Systems Module IV: Programming concepts of Embedded programming

System On Chip (SoC)

SoC acronym for system on chip is an integrated circuit which integrates all the components of a
computer into a single chip. It may contain analog, digital, mixed signal and other radio frequency
functions all lying on a single chip substrate. Today, SoCs are very common in electronics industry
due to its low power consumption. Also, embedded system applications make great use of SoCs.

Typical SoC Architecture

SoC may consists of all or some of the following:

 Control Unit: In SoCs, the major control units are microprocessors, microcontrollers, digital
signal processors etc.
 Memory Blocks: ROM, RAM. Flash memory and EEPROM are the basic memory units
inside a SoC chip.
 Timing Units: Oscillators and PLLs are the timing units of the System on chip.
 Other peripherals of the SoCs are counter timers, real-time timers and power on reset
generators.
 Analog interfaces, external interfaces, voltage regulators and power management units form
the basic interfaces of the SoCs.
 On-chip interconnection (busses, network, etc.)
 Accelerators or application specific hardware modules
 Software – OS, Application, etc.
 This Single Chip contains both hardware and software components.

11
Embedded Systems Module IV: Programming concepts of Embedded programming

Advantages of SoC

 Low power.
 Low cost.
 High reliability.
 Small form factor.
 High integration levels.
 Fast operation.
 Greater design.
 Small size.

Disadvantages of SoC

 Fabrication cost.
 Increased complexity.
 Time to market demands.
 More verification.

Example:

Raspberry Pi is a credit-card sized single-board computer designed and manufactured by the

Raspberry Pi foundation in the United Kingdom. Raspberry Pi has an ARMv6 700 MHz single-
core processor, a Video Core IV GPU and 512MB of RAM. it uses an SD card for its operating
system and data storage. The Raspberry Pi officially supports Raspbian, a lightweight Linux OS
based on Debian.

12
Embedded Systems Module IV: Programming concepts of Embedded programming

THE INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)

IDE consists of a software package which bundles a ‘Text editor’ (source code editor), ‘Cross
compiler (for cross platform development and compiler for same platform development), ‘Linker’
and a ‘Debugger’.
IDE’s can be command line based or GUI based. GUI based IDEs provide a Visual Development
Environment with user interactions through touch/mouse click interface. Such IDEs are generally
known as Visual IDEs. Eg: Microsoft Visual Studio for developing Visual C++ and Visual Basic
programs.

CROSS COMPILERS

Cross compilation is the process of converting a source code written in high level language to a
target processor understandable machine code. The conversion of code is done by software running
on a processor which is different from the target processor. The software performing this operation
is referred as the cross compiler.
Cross assembler converts assembly code to machine code.

DISASSEMBLER/DECOMPILER

Disassembler is a utility program which converts machine codes into target processor specific
Assembly codes/instructions. The process of converting machine codes into Assembly code is
known as 'Disassembling'. In operation, disassembling is complementary to assembling/cross-
assembling.

Decompiler is the utility program for translating machine codes into corresponding high-level
language instructions. Decompiler performs the reverse Operation of compiler/cross-compiler.
The disassemblers/ decompilers for different family of processors/controllers are different.
Disassemblers/Decompilers are deployed in reverse engineering.

SIMULATORS

Simulator is a software tool used for simulating the various conditions for checking the
functionality of the application firmware. The Integrated Development Environment (IDE) itself
will be providing simulator support and they help in debugging the firmware for checking its
required functionality. In certain scenarios, simulator refers to a soft model (GUI model) of the
embedded product. For example, if the product under development is a handheld device, to test
the functionalities of the various menu and user interfaces, a soft form model of the product with
all Ul as given in the end product can be developed in software. Soft phone is an example for such
a simulator.

13
Embedded Systems Module IV: Programming concepts of Embedded programming

Simulators simulate the target hardware and the firmware execution can be inspected using
simulators. The features of simulator-based debugging are listed below.

1. Purely software based.

2. Doesn't require a real target system
3. Very primitive (Lack of featured I/O support. Everything is a simulated one)
4. Lack of Real-time behaviour

EMULATORS AND DEBUGGERS

Debugging in embedded application is the process of diagnosing the firmware execution,

monitoring the target processor's registers and memory while the firmware is running and checking
the signals from various buses of the embedded hardware.
Debugging process in embedded application is broadly classified into hardware debugging and
firmware debugging.
1. Hardware debugging deals with the monitoring of various bus signals and checking the
status lines of the target hardware.
2. Firmware debugging deals with examining the firmware execution, execution flow,
changes to various CPU registers and status registers on execution of the firmware to
ensure that the firmware is running as per the design.

Incremental EEPROM Burning Technique:

This is the most primitive type of firmware debugging technique where the code is separated into
different functional code units. Instead of burning the entire code into the EEPROM chip at once,
the code is burned in incremental order, where the code corresponding to all functionalities are
separately coded, cross-compiled and burned into the chip one by one. The code will incorporate
some indication support like blinking up an LED (every embedded product contains at least one
LED). If not, you should include provision for at least one LED in the target board at the hardware
design time such that it can be used for debugging purpose) or activate a BUZZER if the code is
functioning in the expected way.
If the first functionality is found working perfectly on the target board with the corresponding code
burned into the EEPROM, go for burning the code corresponding to the next functionality and
check whether it is working. Repeat this process till all functionalities are covered. Please ensure
that before entering one level up, the previous level has delivered a correct result. If the code
corresponding to any functionality is found not giving the expected result, fix it by modifying the
code and then only go for adding the next functionality for burning into the EEPROM. After you
found all functionalities working properly, combine the entire source for all functionalities
together, re-compile and burn the code for the total system functioning.

14
Embedded Systems Module IV: Programming concepts of Embedded programming

Obviously, it is a time-consuming process. But it is a onetime process and once you test the
firmware in an incremental model you can go for mass production. In incremental firmware
burning technique we are not doing any debugging but observing the status of firmware execution
as a debug method. The very common mistake committed by firmware developers in developing
non-operating system-based embedded application is burning the entire code altogether and fed up
with debugging the code. Incremental firmware burning technique is widely adopted in small,
simple system developments and in product development where time is not a big constraint.

Inline Breakpoint Based Firmware Debugging:

Inline breakpoint-based debugging is another primitive method of firmware debugging. Within
the firmware where you want to ensure that firmware execution is reaching up to a specified point,
insert an inline debug code immediately after the point. The debug code is a prinlf() function which
prints a string given as per the firmware. You can insert debug codes (prinif()) commands at each
point where you want to ensure the firmware execution is covering that point. Cross-compile the
source code with the debug codes embedded within it. Burn the corresponding hex file into the
EEPROM. You can view the printf() generated data on the a 'Terminal Program'. Configure the
serial communication settings of the 'Terminal Program' connection to the same as that of the serial
communication settings configured in the firmware (Say Baudrate = 9600; Parity = None; Stop Bit
= 1 ; Flow Control = None); Connect the target board's serial port (COM) to the development PC's
COM Port using an RS232 Cable. Power up the target board. Depending on the execution flow of
firmware and the inline debug codes inserted in the firmware, you can view the debug information
on the 'Terminal Program'. Typical usage of inline debug codes and the debug info retrieved on
the HyperTerminal is illustrated below.

Monitor Program Based Firmware Debugging:

In this approach a monitor program which acts as a supervisor is developed. A, The monitor
program controls the downloading of user code into the code memory, inspects and modifies
register/memory locations; allows single stepping of source code, etc. The monitor implements the
debug function as a pre-defined command set from the debug application interface. The monitor
program always listens to the serial port of the target device and according to the command
received from the serial interface it performs command specific actions like firmware
downloading, memory inspection/modification, firmware single stepping and sends the debug
information back to the main debug program running on the development PC etc.

The entire code handling the command reception and corresponding action implementation is
known as monitor program. The interface used between target board and debug application is RS-
232/USB Serial interface. After the successful completion of the 'monitor program' development,
it is compiled and burned into the FLASH memory or ROM of the target board. The code memory
containing the monitor program is known as the `Monitor ROM '.

15
Embedded Systems Module IV: Programming concepts of Embedded programming

Fig. Monitor Program Based Target Firmware Debug Setup

The monitor program contains the following set of minimal features.

1. Command set interface to establish communication with the debugging application

2. Firmware download option to code memory
3. Examine and modify processor registers and working memory (RAM)
4. Single step program execution
5. Set breakpoints in firmware execution
6. Send debug information to debug application running on host machine

16