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 to perform certain specific tasks.
(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 achieve a common goal.
(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 electronic toy
is not at all time-critical.
(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 and as per
the printer manufacturer the end user should replace the cartridge after each ‘n’
number of printouts to get quality prints.
(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.
• Debug-ability has two aspects in the embedded system development context,
namely, hardware level debugging and firmware level debugging.
(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 of it with their product.
(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.
• From a designer/product development company perspective the
ultimate aim of a product is to generate marginal profit.
Embedded Systems-
Application and Domain
specific
WASHING MACHINE—APPLICATION-
SPECIFIC EMBEDDED SYSTEM
• Washing 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
• Washing 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 from the clothes by spinning
at several hundred Rotations Per Minute (RPM). This is called a ‘Spin Phase’.
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 control units.
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 System Transport
( MOST) is targeted for high-bandwidth automotive multimedia networking (e.g.
audio/video, infotainmentsystem interfacing), used primarily in European cars.
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 focus and not
the implementation information.
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 architectures in system design.
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 model
easily.
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 represented using arrows.
• An inward arrow to the process (circle) represents input
data and an outward arrow from the process (circle)
represents output data in DFG notation.
The computational requirement is • Embedded applications which are computational intensive
x = a + b; and y = x – c and data driven are modelled using the DFG model.
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 making
process.
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.
• Action is an activity to be performed by the state machine.
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 Warning’ in an automotive using the FSM
model.
• The system requirements are captured as.
1. When 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 off, whichever
happens first.
Finite State Machine

Here the states are ‘Alarm

Off’, ‘Waiting’ 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 and
actions, whereas the Flow Chart models the execution flow.
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 functioning properly and will
continue serving the assigned task till hardware breakdown occurs or a
corruption in embedded firmware occurs.
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 the tasks
and actions by capturing the model using a language which is understandable by the
target processor/controller.
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 operation, reading/writing, etc. it
should strictly follow a specified sequence and the combination of these series of tasks constitutes
a single task-namely data read/write.
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.
• This brings the probability of missing out some events.
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 (Windows/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 assembly routine to
‘C’ and how ‘Assembly routine’ is invoked from the ‘C’ code.
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 8051 Assembly 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 operations
supported by ‘C’.
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. C51 uses the keywords
#pragma asm and #pragma endasm to indicate a block of code written in
assembly.
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 subset of
standardised general purpose programming conventional ‘C’ language.
language with extensive bit manipulation support. • Embedded ‘C’ supports all ‘C’ instructions and
• ‘C’ offers a combination of the features of high incorporates a few target processor specific
level language and assembly and helps in functions/instructions.
hardware access programming. • The standard ANSI ‘C’ library implementation is
• The conventional ‘C’ language follows ANSI always tailored to the target processor/controller
standard and it incorporates various library fi les library files in Embedded ‘C’.
for different operating systems. • The implementation of target processor/controller
• A platform (operating system) specific application, specific functions/instructions depends upon the
known as, compiler is used for the conversion of processor/controller as well as the supported
programs written in ‘C’ to the target processor (on cross-compiler for the particular Embedded ‘C’
which the OS is running) specific binary fi les. language.
Compiler vs. Cross-Compiler

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