Module – 4

Embedded System Design Concepts

(18CS44)
Characteristics of an Embedded System
Unlike general purpose computing systems, embedded
systems possess certain specific characteristics
• These characteristics are unique to each embedded system.
Some of the important characteristics of an embedded
system are:
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

Department of ISE BMS Institute of Technology and Mgmt

Characteristics : Application and Domain Specific
• An embedded system is designed for a specific (application)
purpose only.
– It will not do any other task.
– Ex. Air conditioner’s embedded control unit, it cannot
replace microwave oven…
– Because the embedded control units of microwave oven
and air conditioner are specifically designed to perform
certain specific tasks.
• Certain embedded systems are specific to a domain:
– Ex. A hearing aid is an application
• belongs to the domain of signal processing
– Ex. Telecom with another control unit
• designed to serve another domain like consumer electronics.
Department of ISE BMS Institute of Technology and Mgmt
Characteristics :Reactive and Real Time
• Certain embedded systems are
– Designed to react to the events that occur in the near by environment.
– These events also occur real-time.
• Example of Real time systems
– Flight control systems, Antilock Brake Systems (ABS), etc.
• Example of Reactive System.
– An air conditioner adjusts its mechanical parts as soon as it gets a
signal from its sensors to increase or decrease the temperature when
the user operates it using a remote control.
• An embedded system uses Sensors to take inputs and has
actuators to bring out the required functionality.

Department of ISE
Characteristics :Operates in harsh environments
• Certain embedded systems are designed to operate in harsh
environments like:
– A dusty one or a high temperature zone /
– An area subject to vibrations and shock /
– Very high temperature of the deserts /
– Very low temperature of the mountains or extreme rains.
• These embedded systems have to be capable of
– Sustaining the environmental conditions it is designed to
operate in.
Characteristics :Distributed

Department of ISE BMS Institute of Technology and Mgmt

 Characteristics :Small Size and Weight
An embedded system that is :
• Compact in size and has light weight will be desirable or more
popular than one that is bulky and heavy.
Ex. Currently available cell phones. The cell phones that have the
maximum features are popular
• But also their size and weight is an important characteristic.

Department of ISE
 Characteristics :Power concerns
It is desirable that the power utilization and heat dissipation of
any embedded system should be low.
• If more heat is dissipated then additional units like
– Heat sinks or cooling fans need to be added to the circuit.
• Additional units →In turn occupies additional space and make
the system bulky.
• Nowadays ultra low power components are available in the
market.
Also power management is a critical constraint in battery
operated application.
• The more the power consumption the less is the battery life.

Department of ISE BMS Institute of Technology and Mgmt

Quality Attributes of an Embedded System
• 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 quality attributes are broadly classified into two,
namely
i. Operational Quality Attributes
ii. Non-Operational Quality Attributes
Operational Quality Attributes

Department of ISE BMS Institute of Technology and Mgmt

 Operational Quality Attributes
1. Response: Is a measure of quickness of the system.
• It gives you an idea about how fast your system is tracking the
input variables.
• Most of the embedded system demand fast response which
should be real-time.
• Ex. An embedded system deployed in flight control application
: Any response delay → creates potential damages 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.
• Ex. The response time requirement for an electronic toy is not
at all time-critical.

Department
Departmentof
ofISE
ISE
 Operational Quality Attributes
2. Throughput: Throughput deals with the efficiency of system.
– It can be defined as rate of production or process 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 case of card reader like the ones used in buses, throughput
means:→ how much transactions the Reader can perform in a
minute or hour or day.
• Throughput is generally measured in terms of ‘Benchmark’ → A
‘Benchmark’ is a reference point by which something can be
measured.
• Benchmark can be a set of performance criteria that a product is
expected to meet or a standard product that can be used for
comparing other products of the same product line.
Operational Quality Attributes

Department of ISE
 Operational Quality Attributes
4. 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 checkup.
• Reliability and maintainability are considered as two complementary
disciplines.
– A more reliable system means a system with less corrective
maintainability requirements and vice versa
• Maintainability can be classified into two types:
1. Scheduled or Periodic Maintenance (Preventive Maintenance):→ An
inkjet printer uses ink cartridges → as per the printer manufacturer the
end use should replace the cartridge after each ‘n’ number of printouts to
get quality prints.
2. Maintenance to Unexpected Failures (Corrective Maintenance) →If
the paper feeding part of the printer fails the printer fails to print and it
requires immediate repairs to rectify this problem.
 Operational Quality Attributes

simply an
indication of the availability of the product for use.
ideal value for

Department of ISE
 Operational Quality Attributes
5. Security : Three major measures of information security:

1. ‘Confidentially’→ Deals with the protection of data and

application from unauthorized disclosure
2. ‘Integrity’→ Deals with the protection of data and application
from unauthorized modification
3. ‘Availability’→ Deals with protection of data and application
from unauthorized users
Certain embedded systems have to make sure they conform to the
security measures.
Ex. An electronic safety Deposit Locker can be used only with a pin
number like a password.

Department of ISE BMS Institute of Technology and Mgmt

 Operational Quality Attributes
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
– Determine the best course of action to bring down the consequences of
the damages to an acceptable level.
.

Department of ISE BMS Institute of Technology and Mgmt

Non-Operational Quality Attributes
• The quality attributes that needs to be addressed for
– The product ‘not’ on the basic 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
Department of ISE BMS Institute of Technology and Mgmt
Non-Operational Quality Attributes
1. Testability & Debug-ability:
• Testability deals with many ways:
– How easily one can test his/her design, application ?
– Which means he/she can test it?
• For an embedded product, testability is applicable to
both the embedded hardware and firmware.
• Debug-ability is a means of debugging the product as
such for figuring out the probable sources that create
unexpected behavior in the total system.

Department
Departmentof
ofISE
ISE
Non-Operational Quality Attributes
1. Testability & Debug-ability:
• Debug-ability has two aspects in the embedded
system development context, namely:
– Hardware level debugging
• Hardware debugging is used for figuring out the issues
created by hardware problems
– Firmware level debugging
• Firmware debugging is employed to figure out the
probable errors that appear as a result of flaws in the
firmware.

Department of ISE BMS Institute of Technology and Mgmt

 Non-Operational Quality Attributes
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.

Department of ISE BMS Institute of Technology and Mgmt

Non-Operational Quality Attributes
3. Portability:
• Portability is a measure of ‘system independence’.
• An embedded product can be called portable if it is:
– Capable of functioning in various environments,
target processors/controllers and embedded
operating systems.
• A standard embedded product should always be
flexible and portable.

Department of ISE BMS Institute of Technology and Mgmt

Non-Operational Quality Attributes

Department of ISE BMS Institute of Technology and Mgmt

Non-Operational Quality Attributes
5. Per unit and total cost
• Cost is a factor which is closely monitored by both:
– End user (those who buy the product)
– Product manufacturer (those who build the product).
• Cost is a highly sensitive factor for commercial
products.
• Proper market study and cost benefit analysis should
be carried out before taking decision on the per unit
cost of the embedded product.

Department
Departmentof
ofISE
ISE
Non-Operational Quality Attributes
5. Per unit and total cost
• When the product is introduced in the market, for
the initial period the sales and revenue will be low.
• There won’t be much competition when the product
sales and revenue increase.
• During the maturing phase, the growth will be steady
and revenue reaches highest point and at retirement
time there will be a drop in sales volume.

Department of ISE BMS Institute of Technology and Mgmt

 Washing Machine
Application Specific Embedded System

Department of ISE
 Washing Machine
Application Specific Embedded System

• Washing Machine is a typical example of an

embedded system providing extensive support in
home automation applications.
• An embedded system contains sensors, actuators,
control unit and application-specific user interfaces
like keyboards, display units, etc. You can see all
these components in a washing machine if you have
a closer look at it. Some of them are visible and some
of them may be invisible to you.

Department of ISE
 Washing Machine
Application Specific Embedded System

Department
Departmentof
ofISE
ISE BMS
BMSInstitute
Institute of
of Technology
Technologyand
andMgmt
Mgmt
 Washing Machine
Application Specific Embedded System
• Actuator part :→ motorized agitator, tumble tub,
water drawing pump and inlet valve to control the
flow of water into the unit.
• Sensor part:→ water temperature sensor, level
sensor, etc.
• Control part:→ microprocessor/controller based
board with interfaces to the sensors and actuators.
• Sensor data:→ Is fed back to the control unit and the
control unit generates the necessary actuator
outputs.

Department of ISE BMS Institute of Technology and Mgmt

 Washing Machine
Application Specific Embedded System

• Control unit:→ 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.
• Integrated control panel:→microprocessor/controller
based board with I/O interfaces and a control
algorithm running in it.

BMS Institute of Technology and Mgmt

 Washing Machine
Application Specific Embedded System

• Input interface:→ Includes the keyboard which

consists of wash type selector namely Wash, Spin
and Rinse, cloth type selector namely Light, Medium,
Heavy duty and washing time setting, etc.
• Output interface:→LED/LCD displays, status
indication LEDs, etc. connected to the I/O bus of the
controller.
• It is to be noted that this interface may vary from
manufacturer to manufacturer and model to model.

Department of ISE BMS Institute of Technology and Mgmt

Automotive (Examples)
Domain Specific Embedded System

Department of ISE BMS Institute of Technology and Mgmt

 Automotive
Domain Specific Embedded System

The major application domains of embedded systems

are:
• Consumer
• Industrial
• Automotive
• Telecom, etc.

Department of ISE BMS Institute of Technology and Mgmt

 Automotive
Domain Specific Embedded System

Department
Departmentof
ofISE
ISE BMS
BMSInstitute
Institute of
of Technology
Technologyand
andMgmt
Mgmt
Inner Workings of Automotive Embedded
Systems
• Automotive embedded systems are the one where
electronics take control over the mechanical systems.
• The presence of automotive embedded system in a
vehicle varies from simple mirror and wiper controls
to complex air bag controller and antilock 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).

Department of ISE BMS Institute of Technology and Mgmt

Inner Workings of Automotive Embedded
Systems
• The various types of electronic control units (ECUs)
are:
1. High speed Electronic Control Units (HECUs) :
– They are deployed in critical control units requiring fast
response, like fuel injection systems, antilock brake
systems, etc.
2. Low speed Electronic Control Units (LECUs) :
– They are deployed in applications where response time is
not so critical. They are generally built around low cost
microprocessors/microcontrollers and digital signal
processors. Audio controllers, passenger and driver door
locks, door glass controls, etc., are examples for LECUs.
Department
Departmentof
ofISE
ISE BMS Institute of Technology and Mgmt
 Automotive Communication Buses

Automotive applications use: serial buses for

communication.
Few important automotive communication buses are:
• Controller Area Network (CAN):
– Event driven serial protocol interface with support for error handling
in data transmission.
– It is generally employed in safety system like airbag control,
powertrain systems like engine control and Antilock Brake Systems
• Local Interconnect Network (LIN):
– It 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.
Department of ISE BMS Institute of Technology and Mgmt
 Automotive Communication Buses

Few important automotive communication buses are:

• Media Oriented System Transport (MOST)
– MOST bus is targeted for automotive audio video
equipment interfacing.
– MOST bus is a multimedia fiber-optic point-to-point
network implemented in a star, ring or daisy chained
topology over optical fibers cables.

Department of ISE BMS Institute of Technology and Mgmt

 Key Players of Automotive Embedded
Market
Key players can be visualized in 3 verticals:
1. Silicon Providers : → Providers of necessary chips
– Analog Devices, Xilinx, NXP Semiconductor, Texas Instruments,
Microchip etc.
2. Tools and Platform Providers:→ Suppliers of Tools and OS
required for Embedded system
– The MathWorks, Keil Software, Microsoft etc.
3. Solution Providers:→Providers of complete solution for
automotive applications
– Bosch Automotive, Infosys Technologies, DENSO Automotive etc.

Department of ISE BMS Institute of Technology and Mgmt

Hardware Software Co-Design and
Program Modelling(Ch-7→7.1,7.2)

Department of ISE
 Hardware Software Co-Design
Before going to the Hardware Software Co-Design we have
know:
Traditional Embedded System Development Approach:
• The hardware software partitioning is done at an early stage
• Engineers from the software group take care of the software
architecture development and implementation
• Engineers from the hardware group are responsible for
building the hardware required for the product
• There is less interaction between the two teams and the
development happens either serially or in parallel and once
the hardware and software are ready, the integration is
performed
Department of ISE BMS Institute of Technology and Mgmt
 Hardware Software Co-Design
Hardware Software Co-design Approach for Embedded System
Development
• The product requirements captured from the customer are
converted into system level needs or processing requirements
rather than partitioning them to either h/w or s/w
• The system level processing requirements are then transferred into
functions which can be simulated and verified against performance
and functionality
• The Architecture design follows the system design. The partition of
system level processing requirements into hardware and software
takes place during the this phase
• Each system level processing requirement is mapped as either
hardware and/or software requirement
• The partitioning is performed based on the hardware-software
trade-offs Department of ISE BMS Institute of Technology and Mgmt
Fundamental Issues in Hardware Software
Co-Design

Department of ISE BMS Institute of Technology and Mgmt

Fundamental Issues in Hardware Software
Co-Design
Fundamental Issues of H/w, S/w Co-Design: Few are listed below:
1. Selecting the model:
• 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
– Has objectives vary with each phase

Department of ISE BMS Institute of Technology and Mgmt

Fundamental Issues in Hardware Software
Co-Design
Fundamental Issues of H/w, S/w Co-Design: Few are listed below:
2. Selecting the Architecture:
• A model only captures the system characteristics
– 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.

Department of ISE BMS Institute of Technology and Mgmt

Fundamental Issues in Hardware Software
Co-Design
Fundamental Issues of H/w, S/w Co-Design: Few are listed below:
2. Selecting the Architecture:
• Few of the commonly used architecture are:
– Controller architecture
• Finite State Machine Model
– Datapath Architecture
• Data Flow Graph
– Complex Instruction Set Computing (CISC)
– Reduced Instruction Set Computing (RISC)
– Very long Instruction Word (VLIW)
• Implements ALUs, Multipliers etc.
– Parallel Processing architecture
• Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data
(MIMD) etc.

Department
Departmentof
ofISE
ISE
Fundamental Issues in Hardware Software
Co-Design
Fundamental Issues of H/w, S/w Co-Design: Few are listed below:
3. Selecting the Language:
• A programming Language captures:
– ‘Computational Model’ and maps it into architecture
• A computational model can be captured:
– Multiple programming languages like C, C++, C#, Java etc. for
software implementations
– 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

Department of ISE BMS Institute of Technology and Mgmt

Fundamental Issues in Hardware Software
Co-Design
Fundamental Issues of H/w, S/w Co-Design: Few are listed below:
4. Partitioning system requirements into hardware and software:
• Deals with the implementation aspect of a System level
Requirement
• It may be possible to implement the system requirements
in either hardware or software (firmware)
• Various hardware software trade-offs like performance, re-
usability, effort etc. are used for making a decision on the
hardware-software partitioning

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
Few of the computational models used in Embedded system are
listed below:
1. Data Flow Graph / Diagram (DFG) Model

2. Control Data Flow Graph / Diagram (CDFG) Model

3. State Machine Model

4. Sequential Program Model

5. Concurrent / Communicating Process Model

6. Object-Oriented Model

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
1. Data Flow Graph / Diagram (DFG)
Model:
• Translates the data processing
requirements into a data flow
graph
• A data driven model in which the
program execution is determined
by data.
• Emphasizes on the data and
operations on the data which
transforms the input data to
output data.
Department of ISE
 Hardware Software Co-Design:→
Computational Models in ES
1. Data Flow Graph / Diagram (DFG) E.g. Model the requirement
Model :→ Consist of x = a + b; and y = x - c;
• Process:→The operation on the data,
represented using a block (circle)
• Data flow:→Is represented using
arrows.
– An inward arrow to the process
(circle) represents input data
– An outward arrow from the process
(circle) represents output data in
DFG notation
• Best suited for modeling Embedded
systems which are computational
intensive (like DSP applications)
Department of ISE BMS Institute of Technology and Mgmt
Hardware Software Co-Design:→
Computational Models in ES

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
2. Control Data Flow Graph / Diagram (CDFG)
Model :
• It is similar to DFG model but only difference
is:→ Contains both data operations and
control operations
• Model used for:→conditional program
execution
• Construction is same as DFG in addition:→it
has conditional (constructs) as decision
makers known as decision nodes.
• The control node is represented by a
‘Diamond’ block which is the decision
making element in a normal flow chart
based design Department of ISE BMS Institute of Technology and Mgmt
 Hardware Software Co-Design:→
Computational Models in ES
2. Control Data Flow Graph / Diagram E.g. Model the requirement
(CDFG) Model : If flag = 1, x = a + b;
else y = a-b;
• Translates the requirement, which is
modeled to a concurrent process
model
• The decision on which process is to be
executed is determined by the control
node
• Example(Application):Digital Camera
– Capturing of image
– Storing it in the format selected
(bmp, jpg, tiff, etc.)

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
3. State Machine Model :
• Based on ‘States’ and ‘State Transition’
• Describes the system behavior with:→
– States
• Representation of a current situation.
– Events
• Input to the state
• It acts as stimuli for state transition.
– Actions
• Action is an activity to be performed by
the state machine.
– Transitions
• Is the movement from one state to
another.
Department of ISE BMS Institute of Technology and Mgmt
 Hardware Software Co-Design:→
Computational Models in ES
3. State Machine Model :
• A Finite State Machine (FSM) Model is one in which the number of states
are finite. In other words the system is described using a finite number of
possible states.
• E.g. Automatic ‘Seat Belt Warning’ in an automotive
▪ When the vehicle ignition is
turned on:
▪ The seat belt is not fastened
within 10 seconds of ignition ON
▪ The system generates an alarm
signal for 5 seconds.
▪ The Alarm is turned off :
▪ The alarm time (5 seconds)
expires
▪ if the driver/passenger fastens
the belt or if the ignition switch is
turned off, whichever happens
first.
Department of ISE BMS Institute of Technology and Mgmt
 Hardware Software Co-Design:→
Computational Models in ES
3. State Machine Model :
• E.g. Model of Timer

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
3. Sequential Program Model:
• The functions or processing requirements are executed in
sequence
• 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 modeling.
• Flow Charts is another important tool used for modeling
sequential program
• The FSM approach represents the states, events, transitions
and actions, whereas the Flow Chart models the execution flow

Department
Departmentof
ofISE
ISE
 Sequential Program Model:
E.g. Automatic ‘Seat Belt Warning’
in an automotive

Department of ISE BMS Institute of Technology and Mgmt

 Sequential Program Model:
E.g. Automatic ‘Seat Belt Warning’
in an automotive

Department
Departmentof
ofISE
ISE BMS
BMSInstitute
Institute of
of Technology
Technologyand
andMgmt
Mgmt
 Hardware Software Co-Design:→
Computational Models in ES
4. Concurrent / Communicating Process Model:
• Certain processing requirements are easier to model in
concurrent processing model than the conventional sequential
execution.
• Sequential execution leads to a single sequential execution of
task and thereby leads to poor processor utilization, when the
task involves I/O waiting, sleeping for specified duration etc.
• If the task is split into multiple subtasks, it is possible to tackle
the CPU usage effectively, when the subtask under execution
goes to a wait or sleep mode, by switching the task execution.
• Concurrent processing model requires additional overheads in
task scheduling, task synchronization and communication

Department of ISE BMS Institute of Technology and Mgmt

 Concurrent /Communicating Process Model:
E.g. Automatic ‘Seat Belt Warning’ in an automotive

Department of ISE BMS Institute of Technology and Mgmt

 Hardware Software Co-Design:→
Computational Models in ES
5. Object-Oriented Model:
• It is object based model for system requirements.
• A Complex requirement→ into simple pieces called objects.
• This model brings:
– Reusability, Maintainability and Productivity.
• Object is represented as an entity
– Each object has a set of unique behaviour and state
• A class is an abstract description i.e. blue print of object.
• Member variables, member functions, private, public,
protected, inheritance, hiding, abstraction etc.

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Design and
development (Ch-9→9.1,9.2)

Department of ISE BMS Institute of Technology and Mgmt

 Embedded Firmware Design and
development
• The embedded firmware is responsible for:
– Controlling the various peripherals of the embedded hardware
– Generating response in accordance with the functional requirements of the
product
• The embedded firmware is usually stored in a permanent memory
(ROM) and it is non alterable by end users
• Designing Embedded firmware requires:
– Understanding of the particular embedded product hardware
– Some programming language
• The embedded firmware development process starts with:
– Conversion of the firmware requirements → A program model using
various modeling tools

Department of ISE BMS Institute of Technology and Mgmt

 Embedded Firmware Design and
development
• There exist two basic approaches for the design and
implementation of embedded firmware, namely;
– The Super loop based approach
– The Embedded Operating System based approach
• The decision on which approach needs to be adopted for firmware
development is purely :
– Dependent on the complexity and system requirements

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Design Approaches:-
The Super loop based approach

• Suitable for applications that are:

– Not time critical and where the response time is not so
important
• Similar to a conventional procedural programming →
where the code is executed task by task
– The task listed on top on the program code is executed first
– The tasks just below the top are executed after completing the
first task

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Design Approaches:-
The Super loop based approach

1. Configure the common parameters and void main ()

{
Configurations ();
Initializations ();
while (1)
{
Task 1 ();
Task 2 ();
//:
//:
Task n ();
}
}

Department of ISE
Embedded Firmware Design Approaches:-
The Super loop based approach

monitoring Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Design Approaches:-
The Super loop based approach

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Design Approaches:-
The Embedded Operating Systems(OS)
Based Approach
• Embedded System consists of Operating System which
can be any one of the:
– A Real Time Operating System (RTOS)
– A Customized General Purpose Operating System
(GPOS)
• The Embedded OS is responsible:
– For scheduling the execution of user tasks
– The allocation of system resources among multiple tasks
• Involves lot of OS related overheads apart from
managing and executing user defined tasks
Department of ISE
Embedded Firmware Design Approaches:-
The Embedded Operating Systems(OS)
Based Approach

Department of ISE BMS Institute of Technology and Mgmt

 Embedded Firmware Development
Languages
• Embedded firmware Development Languages/Options :–
1. Assembly Language Based Development
2. High Level Language Based Development
3. Mixing Assembly and High Level Language

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-

with

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-

Language OPCODE (Action to be OPERAND

carried out) (data)
Assembly Language MOV A #30
(Mov to Accumulator)
Machine Language 01110100 00011110

Department
Departmentof
ofISE
ISE
Embedded Firmware Development Languages:-
Assembly Language Based Development
• Each line in ‘Assembly Language’ consist of four fields :-
LABEL OPCODEOPERAND COMMENTS

– LABEL is an optional field. LABEL is commonly used for representing :→

• A memory location, address of a program, sub-routine, code portion
etc.
– The maximum length of a label differs between assemblers.
– Format : Suffixed with a colon, Begin with a valid character, can
contain number from 0 to 9 and special character _
(underscore).

DELAY: MOV R0, #255 ; Load Register R0 with 255

Department of ISE
Embedded Firmware Development Languages:-
Assembly Language Based Development
• Assembly Language – Source File to Hex File Translation

Department
Departmentof
ofISE
ISE
Embedded Firmware Development Languages:-
Assembly Language Based Development
• Assembly Language – Source File to Hex File Translation
– Assembly code is saved as .asm (Assembly file) file or a .src (source) file or a format
supported by the assembler
– The software utility called ‘Assembler’ performs the translation of assembly code to
machine code
– The assemblers for different family of target machines are different.
• A51 Macro Assembler from Keil software is a popular assembler for the 8051 family micro controller
– Each source file can be assembled separately to :
• Examine the syntax errors and incorrect assembly instructions
– Assembling of each source file generates → a object file.
– The software program called linker/locater is responsible for assigning absolute
address to object files during the linking process
– The Absolute object file created from the object files corresponding to different
source code modules by including library files.
– A software utility called ‘Object to Hex file converter’ translates the absolute object
file to corresponding hex file (binary file)

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-
Assembly Language Based Development

• Advantages:
– Efficient Code Memory & Data Memory Usage (Memory Optimization)
– High Performance
– Low level Hardware Access
– Code Reverse Engineering
• Disadvantages:
– High Development time
– Developer dependency
– Non portable

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-

Department of ISE
Embedded Firmware Development Languages:-
High Level Language Based Development
• High Level Language : Like C,C++

Department
Departmentof
ofISE
ISE BMS
BMSInstitute
Institute of
of Technology
Technologyand
andMgmt
Mgmt
Embedded Firmware Development Languages:-
High Level Language Based Development

• Advantages:
– Reduced Development time
– Developer independency
– Portability
• Disadvantages:
– Some cross compiler are not efficient for generating optimized target code.
– Not optimized in terms of performance and code size.
– Few code developed in high level language is not efficient in accessing low
level hardware.
– The investment for high level language tools are high compared to assembly
level language.

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

• High Level language and Assembly level language can be mixed in three
different ways
– Mixing Assembly Language with High level language like ‘C’
– Mixing High level language like ‘C’ with Assembly Language
– Inline Assembly
• The passing of parameters and return values between the high level and
assembly level language is cross-compiler specific

Department of ISE BMS Institute of Technology and Mgmt

 Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

rule. Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

• By this we can see how a C code is converted to .asm/.src code.

Department of ISE BMS Institute of Technology and Mgmt

Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

Department
Departmentof
ofISE
ISE
Embedded Firmware Development Languages:-
Mixing Assembly and High Level Language

III. Inline Assembly

– Is another technique to insert assembly code at any location of
source code written in ‘C’.
– This avoids the delay in calling an assembly routine from a ‘C, code.

– Special keywords(#pragma asm, #pragma endasm) are used to

Department of ISE BMS Institute of Technology and Mgmt