Embedded System

Design Concepts
Module-2
Contents
Characteristics and Quality Attributes of Embedded Systems

Operational and non-operational quality attributes

Embedded Systems-Application and Domain specific

Hardware Software Co-Design and Program Modelling

(excluding UML)

Embedded firmware design and development (excluding C

language)
Characteristics and Quality
Attributes of Embedded
Systems
CHARACTERISTICS OF AN EMBEDDED
SYSTEM
Some of the important characteristics of an embedded system
are as
follows:

(1) Application and domain specific

(2) Reactive and Real Time
(3) Operates in harsh environments
(4) Distributed
(5) Small size and weight
(6) Power concerns
 (1) Application and domain specific
Each embedded system is designed to perform set of defined
functions and they are developed in such a manner to do the
intended functions only.
They cannot be used for any other purpose.
It is the major criterion which distinguishes an embedded
system from a general purpose computing system.
For example, you cannot replace the embedded control unit of
your microwave oven with your air conditioner’s embedded
control unit, because the embedded control units of
microwave oven and air conditioner are specifically designed
(2) Reactive and Real Time
As mentioned earlier, embedded systems are in constant
interaction with the Real world through sensors and user-
defined input devices which are connected to the input port of
the system.
Any changes happening in the Real world are captured by the
sensors or input devices in Real Time and the control algorithm
running inside the unit reacts in a designed manner to bring
the controlled output variables to the desired level.
Real Time System operation means the timing behaviour of the
system should be deterministic; meaning the system should
respond to requests or tasks in a known amount of time.
(3) Operates in harsh environments
The environment in which the embedded system is deployed
may be a dusty one or a high temperature zone or an area
subject to vibrations and shock.
Systems placed in such areas should be capable to withstand
all these adverse operating conditions.
The design should take care of the operating conditions of the
area where the system is going to implement.
For example, if the system needs to be deployed in a high
temperature zone, then all the components used in the system
should be of high temperature grade.
(4) Distributed
The term distributed means that embedded systems may be a part
of larger systems.
Many numbers of such distributed embedded systems form a single
large embedded control unit.
An Automatic Teller Machine (ATM) is a typical example for this.
An ATM contains a card reader embedded unit, responsible for
reading and validating the user’s ATM card, transaction unit for
performing transactions, a currency counter for dispatching/
vending currency to the authorised person and a printer unit for
printing the transaction details. We can visualise these as
independent embedded systems. But they work together to
(5) Small size and weight
Product aesthetics is an important factor in choosing a product.
For example, when you plan to buy a new mobile phone, you
may make a comparative study on the pros and cons of the
products available in the market.
Definitely the product aesthetics (size, weight, shape, style,
etc.) will be one of the deciding factors to choose a product.
People believe in the phrase “Small is beautiful”.
In embedded domain also compactness is a significant
deciding factor.
(6) Power concerns
Embedded systems should be designed in such a way as to
minimise the heat dissipation by the system.
The production of high amount of heat demands cooling
requirements like cooling fans which in turn occupies
additional space and make the system bulky.
Nowadays ultra low power components are available in the
market.
Select the design according to the low power components like
low dropout regulators, and controllers/processors with power
saving modes.
Operational and non-
operational quality attributes
Quality Attributes of Embedded Systems
Quality attributes are the non-functional requirements that
need to be documented properly in any system design.
If the quality attributes are more concrete and measurable it
will give a positive impact on the system development process
and the end product.
The various quality attributes that needs to be addressed in
any Embedded System development are broadly classified into
two, namely ‘Operational Quality Attributes’ and ‘Non-
Operational Quality Attributes’.
Operational Quality Attributes
The operational quality attributes represent the relevant
quality attributes related to the Embedded System when it is in
the operational mode or ‘online’ mode.
The important quality attributes coming under this category
are listed below:
(1) Response
(2) Throughput
(3) Reliability
(4) Maintainability
(5) Security
(6) Safety
(1) Response
Response is a measure of quickness of the system. It gives you an
idea about how fast your system is tracking the changes in input
variables.
Most of the embedded systems demand fast response which should
be almost Real Time.
For example, an embedded system deployed in flight control
application should respond in a Real Time manner.
Any response delay in the system will create potential impact to the
safety of the flight as well as the passengers.
It is not necessary that all embedded systems should be Real Time
in response. For example, the response time requirement for an
(2) Throughput
Throughput deals with the efficiency of a system.
In general it can be defined as the rate of production or
operation of a defined process over a stated period of time.
The rates can be expressed in terms of units of products,
batches produced, or any other meaningful measurements.
In the case of a Card Reader, throughput means how many
transactions the Reader can perform in a minute or in an hour
or in a day.
Throughput is generally measured in terms of ‘Benchmark’.
(3) Reliability
Reliability is a measure of how much % you can rely upon the
proper functioning of the system or what is the % susceptibility
of the system to failures.
Mean Time Between Failures ( MTBF) and Mean Time To Repair
( MTTR) are the terms used in defining system reliability.
MTBF gives the frequency of failures in hours/weeks/months.
MTTR specifies how long the system is allowed to be out of
order following a failure.
For an embedded system with critical application need, it
should be of the order of minutes.
(4) Maintainability
Maintainability deals with support and maintenance to the end user or
client in case of technical issues and product failures or on the basis of a
routine system check-up.
Reliability and maintainability are considered as two complementary
disciplines.
Maintainability can be broadly classified into two categories, namely,
‘Scheduled or Periodic Maintenance (preventive maintenance)’ and
‘Maintenance to unexpected failures (corrective maintenance)’.
The period may be based on the total hours of the system usage or the
total output the system delivered.
A printer is a typical example for illustrating the two types of
maintainability.
An inkjet printer uses ink cartridges, which are consumable components
(5) Security
‘Confidentiality’, ‘ Integrity’, and ‘ Availability’ are the three
major measures of information security.
Confidentiality deals with the protection of data and
application from unauthorised disclosure.
Integrity deals with the protection of data and application from
unauthorised modification.
Availability deals with protection of data and application from
unauthorised users.
(6) Safety
Safety deals with the possible damages that can happen to
the operators, public and the environment due to the
breakdown of an embedded system or due to the emission of
radioactive or hazardous materials from the embedded
products.
The breakdown of an embedded system may occur due to a
hardware failure or a firmware failure.
Safety analysis is a must in product engineering to evaluate
the anticipated damages and determine the best course of
action to bring down the consequences of the damages to an
acceptable level.
Non-Operational Quality Attributes
The quality attributes that needs to be addressed for the
product ‘not’ on the basis of operational aspects are grouped
under this category. The important quality attributes coming
under this category are listed below.
(1) Testability & Debug-ability
(2) Evolvability
(3) Portability
(4) Time to prototype and market
(5) Per unit and total cost
(1) Testability & Debug-ability
Testability deals with how easily one can test the design,
application and by which means he/she can test it.
For an embedded product, testability is applicable to both the
embedded hardware and firmware.
Embedded hardware testing ensures that the peripherals and the
total hardware functions in the desired manner, whereas firmware
testing ensures that the firmware is functioning in the expected
way.
Debug-ability is a means of debugging the product as such for
figuring out the probable sources that create unexpected behaviour
in the total system.
(2) Evolvability
Evolvability is a term which is closely related to Biology.
Evolvability is referred as the non-heritable variation.
For an embedded system, the quality attribute ‘Evolvability’
refers to the ease with which the embedded product
(including firmware and hardware) can be modified to take
advantage of new firmware or hardware technologies.
The evolution of the mobile phones from 1G to 5G and the
associated hardware and firmware is the perfect example for
Evolvability.
(3) Portability
Portability is a measure of ‘system independence’.
An embedded product is said to be portable if the product is
capable of functioning ‘as such’ in various environments, target
processors/ controllers and embedded operating systems.
The ease with which an embedded product can be ported on to a
new platform is a direct measure of the re-work required. A
standard embedded product should always be flexible and portable.
In embedded products, the term ‘porting’ represents the migration
of the embedded firmware written for one target processor (e.g.
Intel x86) to a different target processor (say an ARM Cortex M3
processor from Freescale).
(4) Time to prototype and market
Time-to-market is the time elapsed between the conceptualisation
of a product and the time at which the product is ready for selling
(for commercial product) or use (for non-commercial products).
The commercial embedded product market is highly competitive
and time to market the product is a critical factor in the success of a
commercial embedded product.
There may be multiple players in the embedded industry who
develop products of the same category (like mobile phone, portable
media players, etc.).
If you come up with a new design and if it takes long time to
develop and market it, the competitor product may take advantage
(5) Per unit and total cost
Cost is a factor which is closely monitored by both end user
(those who buy the product) and product manufacturer (those
who build the product).
Cost is a highly sensitive factor for commercial products. Any
failure to position the cost of a commercial product at a
nominal rate, may lead to the failure of the product in the
market.
Proper market study and cost benefit analysis should be
carried out before taking a decision on the per-unit cost of the
embedded product.
Embedded Systems-
Application and Domain
specific
WASHING MACHINE— APPLICATION-
SPECIFIC EMBEDDED SYSTEM
W ashing machine is a typical example of an
embedded system providing extensive support
in home automation applications.
As mentioned earlier, an embedded system
contains sensors, actuators, control unit and
application-specific user interfaces like
keyboards, display units, etc.
The actuator part of the washing machine
consists of a motorised agitator, tumble tub,
water drawing pump and inlet valve to control
the flow of water into the unit.
WASHING MACHINE— APPLICATION-
SPECIFIC EMBEDDED SYSTEM
The sensor part consists of the water temperature sensor, level
sensor, etc.
The control part contains a microprocessor/controller based board
with interfaces to the sensors and actuators.
The sensor data is fed back to the control unit and the control unit
generates the necessary actuator outputs.
The control unit also provides connectivity to user interfaces like
keypad for setting the washing time, selecting the type of material
to be washed like light, medium, heavy duty, etc.
User feedback is reflected through the display unit and LEDs
connected to the control board.
WASHING MACHINE— APPLICATION-
SPECIFIC EMBEDDED SYSTEM
W ashing machine comes in different designs, like top loading and
front loading machines.
In top loading models the agitator of the machine twists back and
forth and pulls the cloth down to the bottom of the tub.
On reaching the bottom of the tub the clothes work their way back
up to the top of the tub where the agitator grabs them again and
repeats the mechanism.
In the front loading machines, the clothes are tumbled and plunged
into the water over and over again. This is the first phase of
washing.
In the second phase of washing, water is pumped out from the tub
and the inner tub uses centrifugal force to wring out more water
AUTOMOTIVE–DOMAIN SPECIFIC
EXAMPLES OF EMBEDDED SYSTEM
Inner Workings of Automotive
Embedded Systems
Automotive embedded systems are the one where electronics take
control over the mechanical and electrical systems.
The presence of automotive embedded system in a vehicle varies
from simple mirror and wiper controls to complex air bag controller
and Anti-lock Brake Systems (ABS).
Automotive embedded systems are normally built around
microcontrollers or DSPs or a hybrid of the two and are generally
known as Electronic Control Units (ECUs).
The various types of electronic control units (ECUs) used in the
automotive embedded industry can be broadly classified into two–
High-speed embedded control units and Low-speed embedded
Automotive Communication Buses
Automotive applications make use of serial buses for
communication, which greatly reduces the amount of wiring
required inside a vehicle.
Controller Area Network (CAN): It supports medium speed (ISO11519-
class B with data rates up to 125 Kbps) and high speed (ISO11898
class C with data rates up to 1Mbps) data transfer.
Local Interconnect Network (LIN):LIN bus is a single master multiple
slave (up to 16 independent slave nodes) communication interface.
LIN is a low speed, single wire communication interface with
support for data rates up to 20 Kbps and is used for sensor/actuator
interfacing.
Media Oriented System Transport (MOST) Bus: The Media Oriented
Hardware Software Co-
Design and Program
Modelling (excluding UML)
FUNDAMENTAL ISSUES IN HARDWARE
SOFTWARE CO-DESIGN
Selecting the model

Selecting the Architecture

Selecting the language

Partitioning System Requirements into hardware and software

Selecting the model
In hardware software co-design, models are used for capturing and
describing the system characteristics.
A model is a formal system consisting of objects and composition
rules.
It is hard to make a decision on which model should be followed in a
particular system design.
Most often designers switch between a variety of models from the
requirements specification to the implementation aspect of the
system design.
The reason being, the objective varies with each phase; for example
at the specification stage, only the functionality of the system is in
Selecting the Architecture
A model only captures the system characteristics and does not
provide information on ‘how the system can be
manufactured?’.
The architecture specifies how a system is going to implement
in terms of the number and types of different components and
the interconnection among them.
Controller Architecture, Datapath Architecture, Complex
Instruction Set Computing (CISC), Reduced Instruction Set
Computing (RISC), Very Long Instruction Word Computing
(VLIW ), Single Instruction Multiple Data (SIMD), Multiple
Instruction Multiple Data (MIMD), etc. are the commonly used
Selecting the language
A programming language captures a ‘Computational Model’
and maps it into architecture.
There is no hard and fast rule to specify this language should
be used for capturing this model.
A model can be captured using multiple programming
languages like C, C++, C#, Java, etc. for software
implementations and languages like VHDL, System C, Verilog,
etc. for hardware implementations.
The only pre-requisite in selecting a programming language for
capturing a model is that the language should capture the
Partitioning System Requirements into
hardware and software
So far we discussed about the models for capturing the system
requirements and the architecture for implementing the system.

From an implementation perspective, it may be possible to

implement the system requirements in either hardware or software
(firmware).

It is a tough decision making task to figure out which one to opt.

Various hardware software trade-offs are used for making a

decision on the hardware-software partitioning.
 COMPUTATIONAL MODELS IN
EMBEDDED DESIGN
Data Flow Graph/Diagram (DFG) Model
The Data Flow Graph ( DFG) model translates the data
processing requirements into a data flow graph.
The Data Flow Graph (DFG) model is a data driven
model in which the program execution is determined
by data.
This model emphasises on the data and operations
on the data which transforms the input data to
output data.
Indeed Data Flow Graph (DFG) is a visual model in
which the operation on the data (process) is
represented using a block (circle) and data flow is
The computational represented using arrows.
requirement is x = a + b; and y An inward arrow to the process (circle) represents
input data and an outward arrow from the process
= x –c
Control Data Flow Graph/Diagram
(CDFG) The Control DFG ( CDFG) model is used
for modelling applications involving
conditional program execution.
CDFG models contains both data
operations and control operations.
The CDFG uses Data Flow Graph (DFG)
as element and conditional (constructs)
as decision makers.
CDFG contains both data flow nodes
and decision nodes, whereas DFG
contains only data flow nodes.
If flag = 1, x = a + b; else y = a –b;
This requirement contains a decision
State Machine
The State Machine model is used for modelling reactive or event-
driven embedded systems whose processing behaviour are
dependent on state transitions
Embedded systems used in the control and industrial applications
are typical examples for event driven systems.
The State Machine model describes the system behaviour with
‘States’, ‘Events’, ‘Actions’ and ‘Transitions’.
State is a representation of a current situation.
An event is an input to the state. The event acts as stimuli for state
transition.
Transition is the movement from one state to another.
Finite State Machine
A Finite State Machine ( FSM) model is one in which the
number of states are finite.
As an example let us consider the design of an embedded
system for driver/passenger ‘Seat Belt W arning’ in an
automotive using the FSM model.
The system requirements are captured as.
1. W hen the vehicle ignition is turned on and the seat belt is not
fastened within 10 seconds of ignition ON, the system generates an
alarm signal for 5 seconds.
2. The Alarm is turned off when the alarm time (5 seconds) expires or if
the driver/passenger fastens the belt or if the ignition switch is turned
Finite State Machine

Here the states are ‘Alarm

Off’, ‘W aiting’ and ‘Alarm
On’ and the events are
‘Ignition Key ON’, ‘Ignition
Key OFF’, ‘Timer Expire’,
‘Alarm Time Expire’ and
‘Seat Belt ON’.
Sequential Program Model
In the sequential programming model, the functions or
processing requirements are executed in sequence.
It is same as the conventional procedural programming.
Here the program instructions are iterated and executed
conditionally and the data gets transformed through a series of
operations.
FSMs are good choice for sequential program modelling.
Another important tool used for modelling sequential program
is Flow Charts.
The FSM approach represents the states, events, transitions
Embedded firmware design and
development (excluding C
language)
Introduction
The embedded firmware is responsible for controlling the various
peripherals of the embedded hardware and generating response in
accordance with the functional requirements mentioned in the
requirements for the particular embedded product.
Firmware is considered as the master brain of the embedded
system.
Imparting intelligence to an embedded system is a one time process
and it can happen at any stage, it can be done immediately after
the fabrication of the embedded hardware or at a later stage.
Once intelligence is imparted to the embedded product, by
embedding the firmware in the hardware, the product starts
Introduction
Designing embedded firmware requires understanding of the particular
embedded product hardware, like various component interfacing, memory
map details, I/O port details, configuration and register details of various
hardware chips used and some programming language (either target
processor/controller specific low level assembly language or a high level
language like C/C++/JAVA).
Embedded firmware development process starts with the conversion of
the firmware requirements into a program model using modelling tools like
UML or flow chart based representation.
The UML diagrams or flow chart gives a diagrammatic representation of
the decision items to be taken and the tasks to be performed.
Once the program model is created, the next step is the implementation of
EMBEDDED FIRMWARE DESIGN
APPROACHES
The firmware design approaches for embedded product is
purely dependent on the complexity of the functions to be
performed, the speed of operation required, etc.
Two basic approaches are used for Embedded firmware design.
They are ‘Conventional Procedural Based Firmware Design’
and ‘ Embedded Operating System (OS) Based Design’.
The conventional procedural based design is also known as
‘Super Loop Model’.
The Super Loop Based Approach
The Super Loop based firmware development approach is adopted for applications
that are not time critical and where the response time is not so important
(embedded systems where missing deadlines are acceptable).
It is very similar to a conventional procedural programming where the code is
executed task by task.
The task listed at the top of the program code is executed first and the tasks just
below the top are executed after completing the first task.
The ‘Super loop based design’ doesn’t require an operating system, since there is
no need for scheduling which task is to be executed and assigning priority to each
task.
This type of design is deployed in low-cost embedded products and products
where response time is not time critical.
For example, reading/writing data to and from a card using a card reader requires a
sequence of operations like checking the presence of card, authenticating the
The firmware execution flow for Super
Loop based approach
1. Configure the common parameters and perform initialisation
for various hardware components memory, registers, etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
5. :
6. :
7. Execute the last defined task
8. Jump back to the first task and follow the same flow
The Super Loop based approach
From the firmware execution sequence, it
is obvious that the order in which the tasks
to be executed are fixed and they are hard
coded in the code itself.
Also the operation is an infinite loop based
approach.
We can visualise the operational sequence
listed above in terms of a ‘C’ program code
as
Since the tasks are running inside an
infinite loop, the only way to come out of
the loop is either a hardware reset or an
interrupt assertion.
The Super Loop based approach
A typical example of a ‘Super loop based’ product is an electronic
video game toy containing keypad and display unit.
The program running inside the product may be designed in such a
way that it reads the keys to detect whether the user has given any
input and if any key press is detected the graphic display is updated.
The keyboard scanning and display updating happens at a
reasonably high rate.
Even if the application misses a key press, it won’t create any critical
issues; rather it will be treated as a bug in the firmware.
It is not economical to embed an OS into low cost products and it is
not smart to do so if the response requirements are not crucial.
The Super Loop based approach
The ‘Super loop based design’ is simple and straight forward
without any OS related overheads.
The major drawback of this approach is that any failure in any part
of a single task may affect the total system.
If the program hangs up at some point while executing a task, it
may remain there forever and ultimately the product stops
functioning.
Another major drawback of the ‘Super loop’ design approach is the
lack of real timeliness.
If the number of tasks to be executed within an application
increases, the time at which each task is repeated also increases.
The Embedded Operating System (OS)
Based Approach
The Operating System (OS) based approach contains operating
systems, which can be either a General Purpose Operating System
(GPOS) or a Real Time Operating System (RTOS) to host the user
written application firmware.
The General Purpose OS (GPOS) based design is very similar to a
conventional PC based application development where the device
contains an operating system (W indows/Unix/ Linux, etc. for
Desktop PCs) and you will be creating and running user applications
on top of it.
Real Time Operating System (RTOS) based design approach is
employed in embedded products demanding Real-time response.
RTOS respond in a timely and predictable manner to events.
EMBEDDED FIRMWARE DEVELOPMENT
LANGUAGES
Following are the options for the embedded firmware
development languages:

Assembly language or low level language

C, C++, JAVA or High Level Language

a combination of Assembly and High level Language.

Assembly Language based Development
‘ Assembly language’ is the human readable notation of ‘
machine language’, whereas ‘machine language’ is a processor
understandable language.
Assembly language and machine languages are processor/
controller dependent and an assembly program written for one
processor/controller family will not work with others.
Assembly language programming is the task of writing
processor specific machine code in mnemonic form,
converting the mnemonics into actual processor instructions
(machine language) and associated data using an assembler.
High Level Language Based
Development
Assembly language based programming is highly time consuming,
tedious and requires skilled programmers with sound knowledge of
the target processor architecture.
Applications developed in Assembly language are non-portable.
Here comes the role of high level languages.
Any high level language (like C, C++ or Java) with a supported cross
compiler (for converting the application developed in high level
language to target processor specific assembly code) for the target
processor can be used for embedded firmware development.
The most commonly used high level language for embedded
firmware application development is ‘C’.
Mixing Assembly and High Level
Language
Certain embedded firmware development situations may
demand the mixing of high level language with Assembly and
vice versa.
High level language and assembly languages are usually mixed
in three ways;

Mixing Assembly Language with High Level Language

Mixing High Level Language with Assembly
In-line Assembly programming
 Mixing Assembly Language with High Level Language

Assembly routines are mixed with ‘C’ in situations where the

entire program is written in ‘C’ and the cross compiler in use do
not have a built in support for implementing certain features
like Interrupt Service Routine functions (ISR) or if the
programmer wants to take advantage of the speed and
optimised code offered by machine code generated by hand
written assembly rather than cross compiler generated
machine code.
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
Mixing High Level Language with
Assembly (e.g. ‘C’ with Assembly
Language)
Mixing the code written in a high level language like ‘C’ and Assembly
language is useful in the following scenarios:
1. The source code is already available in Assembly language and a routine
written in a high level language like ‘C’ needs to be included to the existing
code.
2. The entire source code is planned in Assembly code for various reasons like
optimised code, optimal performance, efficient code memory utilisation and
proven expertise in handling the Assembly, etc.
But some portions of the code may be very difficult and tedious to code in
Assembly. For example 16bit multiplication and division in 8051Assembly
Language.
3. To include built in library functions written in ‘C’ language provided by the
cross compiler. For example Built in Graphics library functions and String
Inline Assembly
Inline assembly is another technique for inserting target
processor/controller specific Assembly instructions at any
location of a source code written in high level language ‘C’.
This avoids the delay in calling an assembly routine from a ‘C’
code (If the Assembly instructions to be inserted are put in a
subroutine as mentioned in the section mixing assembly with
‘C’).
Special keywords are used to indicate that the start and end of
Assembly instructions.
The keywords are cross-compiler specifi c. C51uses the
PROGRAMMING IN EMBEDDED C
Whenever the conventional ‘C’ Language and its extensions are used for
programming embedded systems, it is referred as ‘Embedded C’ programming.
Programming in ‘Embedded C’ is quite different from conventional Desktop
application development using ‘C’ language for a particular OS platform.
Desktop computers contain working memory in the range of Giga bytes and
storage memory in the range of Giga/Tera bytes.
For a desktop application developer, the resources available are surplus in quantity
and the developer is not restricted in terms of the memory usage.
This is not the case for embedded application developers.
Almost all embedded systems are limited in both storage and working memory
resources.
Embedded application developers should be aware of this fact and should develop
applications in the best possible way which optimises the code memory and
working memory usage as well as performance.
C v/s. Embedded C
C Embedded C
‘C’ is a well structured, well defined and Embedded ‘C’ can be considered as a
standardised general purpose subset of conventional ‘C’ language.
programming language with extensive Embedded ‘C’ supports all ‘C’ instructions
bit manipulation support. and incorporates a few target processor
‘C’ offers a combination of the features of specific functions/instructions.
high level language and assembly and The standard ANSI ‘C’ library
helps in hardware access programming. implementation is always tailored to the
The conventional ‘C’ language follows target processor/controller library files in
ANSI standard and it incorporates Embedded ‘C’.
various library fi les for different The implementation of target processor/
operating systems. controller specific functions/instructions
A platform (operating system) specific depends upon the processor/controller as
application, known as, compiler is used well as the supported cross-compiler for
for the conversion of programs written in the particular Embedded ‘C’ language.
‘C’ to the target processor (on which the
Compiler vs. Cross-Compiler

Compiler Cross-Compiler
Compiler is a software tool that converts a Cross-compilers are the software tools
source code written in a high level language
on top of a particular operating system running
used in cross-platform development
on a specific target processor architecture (e.g. applications.
Intel x86/Pentium).
In cross-platform development, the
Here the operating system, the compiler compiler running on a particular target
program and the application making use of the
source code run on the same target processor. processor/OS converts the source
code to machine code for a target
The source code is converted to the target
processor specific machine instructions. processor whose architecture and
The development is platform specific.
instruction set is different from the
processor on which the compiler is
Compilers aregenerally termed as ‘Native
Compilers’. A native compiler generates
running or for an operating system
machine code for the same machine which is different from the current
(processor) on which it is running. development environment OS.