Embedded Systems

Build process in ES
• The process which converts source code to executable code is called as the build process.
• The build process for embedded systems is different. This is because the code to be run on an embedded
system is written one platform i.e. general-purpose computer and executed on another platform i.e. the
target hardware.
• An Embedded system would also use tools such as a Compiler, Linker, Locater and Debugger to perform
the entire build process.
• A compiler which produces the executable code to be run on a different platform is called a cross-
compiler; else it is called a native compiler.
• The build process involves three steps:
1. Compiling
2. Linking
3. Locating

A. Compiling

• The compiler takes input as source code files and gives output as multiple object files.
• Compilers for embedded systems are essentially cross compilers. For example, while compiling the
programmer must select the target processor for which the code has to be generated.

B. Linking

• The linker takes input as multiple object files and gives output as a single object file which is also called
as the relocatable code.
• The output of compiler is multiple object files. These files are incomplete in the sense that they may
contain reference to variables and functions across multiple object files which need to be resolved
• The job of the linker is to combine these multiple object files and resolve the unresolved symbols.
 • The Linker does this by merging the various sections like text, data, and bss of the individual object files.
The output of the linker will be a single file which contains all of the machine language code from all of
the input object files that will be in the text section of this new file.

C. Locating

• The relocater takes input as the relocatable code produced by the linker and gives output as the final
executable code.
• This output is a binary executable file which is called hex code.
• The locator needs to be given information about the memory available on the target processor.
• The locator will use this information to assign physical memory addresses to each of the code and data
sections within the relocatable program code. Finally, it produces an output file that contains a binary
memory image that can be loaded into the target processors ROM.

Real Time Operating System (RTOS)

Operating System basics

• The Operating System acts as a bridge between the user applications/tasks and the underlying system
resources through a set of system functionalities and services.

• OS manages resources and available to the system makes them the user applications/tasks on a need
basis.

• The primary functions of an Operating system are,

1. Make the system convenient to use.
2. Organize and manage the system resources efficiently and correctly.
The Kernel

• The kernel is the core of the operating system

• It is responsible for managing the system resources and the communication among the
hardware and other system services

• Kernel acts as the abstraction layer between system resources and user applications

• Kernel contains a set of system libraries and services.

• For a general-purpose OS, the kernel contains different services like

1. Process Management
2. Primary Memory Management
3. File System management
4. I/O System (Device) Management
5. Secondary Storage Management
6. Protection
7. Time management
8. Interrupt Handling
Types of Operating systems
Depending on type of kernel and kernel services, purpose and type of computing systems where
OS is deployed and responsiveness to application, Operating systems are classified as,

1. General purpose operating system

2. Real time operating system

Real-Time Operating System General Purpose Operating System

The RTOS always uses priority-based Task scheduling in a GPOS isn't necessarily
scheduling. based on which application or process is the
most important. Threads and processes are
often dispatched using a "fairness" policy.
The time response of the RTOS is The time response of the general-purpose
deterministic. operating system is not deterministic.
A low-priority job in an RTOS would be pre- A high-priority thread in a GPOS cannot
empted by a high-priority one if required, preempt a kernel call.
even executing a kernel call.
The real-time operating system optimizes The GPOS does not optimize the memory
memory resources. resources.
The RTOS is mainly used in the embedded GPOS is mainly used in PC, servers, tablets,
system. and mobile phones.
The real-time operating system has a task The general-purpose operating system has no
deadline. task deadline.
It doesn't have large memory. It has a large memory.
GPOS code is not often modular in nature RTOS kernel code is intended to be scalable,
when it comes to development. allowing developers to selectively select
kernel objects.
RTOS is designed and developed for a single- GPOS is designed for a multi-user
user environment. environment.
Examples: FreeRTOS, Contiki source code, etc. Examples: Linux, Windows, IOS, etc.

Real time characteristics

The basic real time characteristics are,

1. Task/Process management
2. Task/Process scheduling
3. Task/Process synchronization
4. Error/exception handling
5. Memory management
6. Interrupt handling
7. Time management
1. Task/Process management
Responsible for setting up the memory space for the tasks, loading the tasks code into the
memory space, allocating system resources, setting up a Task Control Block (TCB) for the task and
task/process termination/deletion.

2. Task/Process scheduling

Responsible for sharing the CPU among various task/processes.

3. Task/Process synchronization

Responsible for synchronizing the concurrent access of a resource, which is shared across
multiple tasks and the communication between various tasks.

4. Error/exception handling

Responsible for registering and handling the errors occurred during the execution of tasks.

5. Memory management

Responsible for allocating blocks of memory during task execution.

6. Interrupt handling

Responsible for handling various types of interrupts.

7. Time management

Responsible for providing accurate time management for providing precise time reference for all
applications.

How to Choose RTOS

A lot of factors need to be analyzed carefully before deciding on the selection of an RTOS. The
factors can be functional or nonfunctional.

A. Functional requirements

Processor Support- It is essential to ensure the processor support by the RTOS.

Memory Requirement- The OS requires ROM memory for holding the OS files and it is normally
stored in a nonvolatile memory like FLASH. OS also requires working memory RAM for loading
OS services.
Real time capability- It is not mandatory that the OS for all embedded systems need to be real
time.

Kernel and Interrupt latency- Kernel of the OS may disable interrupts while executing certain
services and it may lead to interrupt latency.

Inter process communication and task synchronization- It is OS kernel dependent.

Modularization support- Developer can choose essential modules and re compile the OS.

Support for networking and Communication- The OS kernel may provide driver support for a
bunch of communication interfaces and networking.

Development language support- Some OS includes run time libraries required for running
applications.

B. Nonfunctional requirements

Custom developed or off the shelf- Depending on OS requirements, it is possible to go for the
complete development of an operating system or use an off the shelf, readily available OS, which
is either a commercial product or open source product matching the system requirements.

Cost- Cost for developing oy buying OS and maintaining it needs to be evaluated before taking
decision on selection of OS.

Development and debugging tool availability- Explore the different tools available for OS under
consideration.

Ease of use- Need to evaluate how easy to use commercial RTOS.

After Sales- For commercial embedded RTOS, after sales in the form of e-mail, on call services
etc., for bug fixes, critical patch updates and support for production issues etc. should be
analyzed.
The Integrated Development Environment (IDE)

• In embedded system development context, IDE stands for an integrated environment for
developing and debugging the target processor specific embedded firmware.
• IDE is a software package which bundles a ‘Text Editor’, ‘Cross Compiler’, ‘Linker’ and
‘Debugger’.
• Some IDE’s may provide interface to target board emulators.
• IDE’s can be either command line based, or GUI based.
• Command line based may include little or less GUI support.
• GUI based IDE’s provide a visual development environment with mouse click support for
each action.
• Keil µ Vision 3 from Keil software is example for third party IDE.

Types of files generated on Cross-compilation

Cross compilation is the process of converting a source code written in high level language to a
target processor/controller understandable machine code. The various files generated during the
cross compilation are: List File(.lst), Hex File (.hex), Pre-processor output file, Object file (.obj)
and Map file (.MAP)

List file
• This file is generated during the cross-compilation process and it contains information like
cross compiler details, formatted source text, assembly code, symbol table, errors and
warnings.
• Different sections involve in list file are page header, command line, source code,
assembly listing, symbol listing, module information, warnings and errors.

Pre-processor output file

• This file generated during cross compilation and contains the preprocessor output for
preprocessor instructions used in source file.
• This file is used for verifying the operation of macros and conditional preprocessor
directives.

Object File
• Cross-compiling converts the various embedded instructions and other directives present
in module to an object file.
• Various details stored in object file are reserved memory for global variables, public
symbol names, external symbol reference, library files and debugging information.

Map file
• This file contains information about the link/locate process and is composed of several
sections.
 • Various information held by map files are Page Header, Command Line, CPU details, Input
Modules, Inter Module Cross Reference, Memory Map, Program size, Warnings and
Errors.

HEX file
• This is the binary executable file created from source code.
• The absolute object file created by the linker is converted into processor understandable
binary code.

DISASSEMBLER/DECOMPILER

• Disassembler is a utility program which converts machine code into target processor
specific assembly codes.
• The process of converting machine codes into assembly code is known as Disassembling.
• It is complementary process of assembling/ cross-compiling.
• They are deployed in reverse Engineering to reveal the technology behind working
product.
• They are powerful tools for analyzing presence of malicious codes (virus) in an executable
image.
• They are available as either freeware tools from internet or commercial tool.

SIMULATORS

• It is a software tool used for simulating the various conditions for checking the
functionality of the application firmware.
• They simulate the target hardware and the firmware execution can be inspected using
simulators.
• The different features of simulator-based debugging are,
A. Purely software based
B. Does not require real target systems
C. Very primitive
D. Lack of real time behaviors
• Advantages of Simulator based debugging are
A. No need for original target board
B. Simulate I/O peripherals
C. Simulates abnormal conditions
• Limitations of Simulator based debugging
A. Deviation from real behavior
B. Lack of real timeliness
EMULATORS AND DEBUGGERS

• Emulator is a hardware device which emulates the functionalities of the target device and
allows real time debugging of the embedded firmware in a hardware environment.
• Debugging in embedded application is the process of diagnosing the firmware execution,
monitoring the target processors registers and memory while the firmware is running and
checking the signals from various buses of embedded hardware.
• Debugging process is classified into two types i.e. hardware debugging and firmware
debugging.
• Hardware debugging deals with the monitoring of various bus signals and checking the
status lines of the target hardware.
• Firmware debugging deals with the 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 design.
• The different firmware debugging technics are
A. Incremental EEPROM burning technique
B. Inline breakpoint-based firmware debugging
C. Monitor program-based firmware debugging
D. In circuit Emulator based firmware debugging

Embedded Product Development Life Cycle (EDLC)

• EDLC is an ‘analysis design implementation’ based standard problem-solving approach for
embedded product development.
• In any product development application, the first step is to figure out what product needs
to be developed (analysis), next you need to figure out a good approach for building
it(design) and last but not the least you need to develop it (Implementation).
• EDLC is essential to understand the scope and complexity of the work involved in any
embedded development.
• It defines interaction and activities among various groups including project management,
system design and development.
• EDLC had three primary objectives.
A. Ensure high quality products are delivered to end user.
B. Risk minimization and defect prevention
C. Maximize the productivity.
Different phases of EDLC

The number of phases involved in product development model may vary according to complexity
of product. A simple product contains five phases such as Requirement ‘analysis’, ‘Design’,
‘Development and Test’, ‘Development’ and ‘maintenance’. Classic product life cycle model
contains the phases as shown in figure below.

1. Need- Need may come from individuals, public or from a company. The need of embedded product can
be reviewed by following requirements.

• New or custom product development

• Product re-engineering
• Product maintenance

2. Conceptualization- It begins after concept proposal is approved. This defines the scope of concept,
perform cost benefit analysis and feasibility study and prepares project management and risk
management plan.
3. Analysis- Requirement analysis is performed to develop a detailed functional model of product under
consideration. The various activities involve in analysis are,

• Analysis and Documentation

• Interface definition and documentation
• Defining test plan and procedures

4. Design- Deals with the entire design of the product taking requirement into consideration. It identifies
application environment and create overall architecture of the product. It starts with preliminary design
illustrations and ends with detailed design illustration.

5. Development and Testing- This transforms design into a realizable product. The detailed specifications
are translated into hardware and firmware.

6. Deployment- The process of launching the first fully functioning model of the product in the market or
handing over the initial model to end user. It is also known as First Customer Shipping (FCS). The different
tasks performed during the deployment are.

• Notification of product deployment

• Execution of training plan
• Product installation
• Product post implementation review

7. Support- It deals with operation and maintenance of the product in production environment. In this
product is scrutinized to ensure that it meets requirement put forward by end user. Support should be
provided to end user to fix bug. Various activities involve are,

• Set up dedicated support wing

• Identify bugs and areas of improvement

8. Upgrades- It deals with development of upgrades for product which is already present in market. It is
required for fixing major bugs in design.

9. Retirement/Disposal- The disposition of product is essential because rapid technology advancement

and increasing user needs.

Trends in Embedded industry

The different trends involve are

• Processor Trend
• Embedded OS Trend
• Development Language Trends
• Open standard, framework and alliance
Processor Trend- The key processor architectures/trends in embedded development are,

• System on Chip (SOC)

• Multicore processor/ Chip level multi-processor (CMP)
• Reconfigurable processor

Embedded OS Trends- Today OS suppliers are providing off the shelf OS customized for device.
For ex. Microsoft Embedded OS. The different available OS are,

• Windows mobile OS
• Open source embedded OS
• The Ubuntu MID edition
Development language Trend- When we think of development language for embedded firmware
the first language is always ‘C’ language. We also have object-oriented language like C++. The
different languages available are,

• C
• C++
• Microsoft C#
• ASP.NET
• VB
• JAVA
Open standards, Framework and Alliance- The open alliances and standards body are aimed
towards defining and formulating the standards. Time to market is crucial factor in embedded
market segments. Open source and frameworks reduce the time to market in product
development. The different strategic alliances, open source standards and frameworks in mobile
handset industry are,

• Open Mobile Alliance (OMA)

• Open Handset Alliance (OHA)
• Android
• Openmoko

------END------