0% found this document useful (0 votes)
37 views163 pages

Embedded System

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views163 pages

Embedded System

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 163

EMBEDDED SYSTEM

Dr. Pramod R. Bokde


Assistant Professor
Priyadarshini Bhagwati College of Engineering, Nagpur

June 30, 2021


2

DISCLAIMER

This document does not claim any originality


and cannot be used as a substitute for prescribed
textbooks. The information presented here is merely a
collection by the teacher for his respective teaching
assignments. Various sources as mentioned at the end
of the document as well as freely available material
from internet were consulted for preparing this
document. The ownership of the information lies with
the respective authors or institutions.
Reference Books

1 Introduction to Embedded Systems – Shibu K.V, Mc Graw Hill

2 Embedded System Design-Raj Kamal, Tata McGraw Hill

3 Computers as Components –Wayne, Wolf-morgan Kaufmann publications

3
4
Contents

1 Introduction to Embedded Systems 11

1.1 What is Embedded System? . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Embedded Systems Vs General Computing Systems . . . . . . . . 12

1.3 History of Embedded Systems . . . . . . . . . . . . . . . . . . . . 13

1.4 Classification of Embedded Systems . . . . . . . . . . . . . . . . . 13

1.5 Major Application Areas of Embedded Systems . . . . . . . . . . 16

1.6 Purpose of Embedded Systems . . . . . . . . . . . . . . . . . . . . 17

1.7 Embedded System Design Process . . . . . . . . . . . . . . . . . . 20

1.8 Characteristics of Embedded systems . . . . . . . . . . . . . . . . 24

1.9 Quality Attributes of Embedded System . . . . . . . . . . . . . . . 26

1.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2 Typical Embedded System 33

2.1 Elements of Embedded System . . . . . . . . . . . . . . . . . . . . 33

2.2 The Core of the Embedded Systems . . . . . . . . . . . . . . . . . 35

2.3 General Purpose Processor (GPP) Vs Application Specific


Instruction Set Processor (ASIP) . . . . . . . . . . . . . . . . . . . . 39

2.4 RISC V/s CISC Processors/Controllers . . . . . . . . . . . . . . . 41

2.5 Harvard V/s Von-Neumann Processor/Controller Architecture . 42

5
6 CONTENTS

2.6 Big-endian V/s Little-endian processors . . . . . . . . . . . . . . . 43

2.7 Load Store Operation & Instruction Pipelining . . . . . . . . . . . 44

2.8 Application Specific Integrated Circuit (ASIC) . . . . . . . . . . . 45

2.9 Programmable Logic Devices (PLDs) . . . . . . . . . . . . . . . . . 47

2.10 Commercial off the Shelf Component (COTS) . . . . . . . . . . . . 50

2.11 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.12 Embedded system requirements . . . . . . . . . . . . . . . . . . . 60

2.13 Sensors and Actuators . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.14 The I/O Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.14.1 I/O Devices - Light Emitting Diode (LED) . . . . . . . . . 64

2.14.2 I/O Devices - 7-Segment LED Display . . . . . . . . . . . . 65

2.14.3 I/O Devices – Optocoupler . . . . . . . . . . . . . . . . . . 66

2.14.4 I/O Devices – Stepper Motor . . . . . . . . . . . . . . . . . 67

2.14.5 The I/O Subsystem – I/O Devices – Relay . . . . . . . . . 68

2.14.6 I/O Devices -Piezo Buzzer . . . . . . . . . . . . . . . . . . 69

2.14.7 I/O Devices – Push button switch . . . . . . . . . . . . . . 70

3 Communication Interface 73

3.1 Communication Interface . . . . . . . . . . . . . . . . . . . . . . . 73

3.1.1 Device/board level communication interface (Onboard


Communication Interface) . . . . . . . . . . . . . . . . . . . 74

3.1.2 Product level communication interface (External


Communication Interface) . . . . . . . . . . . . . . . . . . . 74

3.2 Device/board level or On board communication interfaces . . . . 75

3.2.1 I 2 C (Inter Integrated Circuit) Bus . . . . . . . . . . . . . . . 75

3.2.2 Serial Peripheral Interface (SPI) Bus . . . . . . . . . . . . . 79


CONTENTS 7

3.2.3 1-wire interface (protocol) . . . . . . . . . . . . . . . . . . . 83

3.2.4 Parallel Communication . . . . . . . . . . . . . . . . . . . . 84

3.3 Product level communication interface (External


Communication Interface) . . . . . . . . . . . . . . . . . . . . . . . 85

3.3.1 Wired communication interface . . . . . . . . . . . . . . . . 85

3.3.2 USB (UNIVERSAL SERIAL BUS): . . . . . . . . . . . . . . 89

3.4 Bus Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.5 Wireless communication interface . . . . . . . . . . . . . . . . . . 91

3.5.1 Infrared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.5.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.5.3 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.5.4 ZIGBEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.5.5 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4 Embedded Firmware Design and Development 99

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.2 Embedded Firmware Design and Development . . . . . . . . . . 100

4.2.1 Embedded firmware Design Approaches – The Super loop 101

4.2.2 Embedded firmware Design Approaches – Embedded OS


based Approach . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.3 Embedded firmware Development Languages/Options . . . . . . 103

4.3.1 Embedded firmware Development Languages/Options –


Assembly Language . . . . . . . . . . . . . . . . . . . . . . 104

4.3.2 Assembly Language – Source File to Hex File Translation . 106

4.3.3 Embedded firmware Development Languages/Options –


High Level Language . . . . . . . . . . . . . . . . . . . . . 109
8 CONTENTS

4.3.4 Embedded firmware Development Languages/Options –


High Level Language – Source File to Hex File Translation 110

4.3.5 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.3.6 Embedded firmware Development Languages/Options –


Mixing of Assembly Language with High Level Language 111

4.3.7 In line Assembly . . . . . . . . . . . . . . . . . . . . . . . . 113

5 RTOS Based Embedded System Design 115

5.1 Operating System Basics . . . . . . . . . . . . . . . . . . . . . . . . 115

5.2 The Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5.2.1 Kernel Space and User Space . . . . . . . . . . . . . . . . . 117

5.2.2 Monolithic Kernel . . . . . . . . . . . . . . . . . . . . . . . 117

5.2.3 Microkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.3 Types of Operating Systems . . . . . . . . . . . . . . . . . . . . . . 119

5.3.1 General Purpose Operating System (GPOS) . . . . . . . . . 120

5.3.2 Real Time Purpose Operating System (RTOS) . . . . . . . . 120

5.4 The Real Time Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.5 Hard Real-time System . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.6 Soft Real-time System . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.7 Tasks, Processes & Threads . . . . . . . . . . . . . . . . . . . . . . 129

5.8 Multiprocessing & Multitasking . . . . . . . . . . . . . . . . . . . . 136

5.9 Types of Multitasking . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.10 Task Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.10.1 Task Scheduling - Scheduler Selection . . . . . . . . . . . . 139

5.10.2 Task Scheduling - Queues . . . . . . . . . . . . . . . . . . . 140

5.11 Non-preemptive scheduling . . . . . . . . . . . . . . . . . . . . . 141


CONTENTS 9

5.11.1 First Come First Served (FCFS)/First In First Out (FIFO)


Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.11.2 Last Come First Served (LCFS)/Last In First Out (LIFO)


Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.11.3 Shortest Job First (SJF) Scheduling . . . . . . . . . . . . . . 145

5.11.4 Priority based Scheduling . . . . . . . . . . . . . . . . . . . 146

5.12 Preemptive scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.12.1 Preemptive SJF Scheduling/ Shortest Remaining Time


(SRT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.13 Round Robin (RR) Scheduling . . . . . . . . . . . . . . . . . . . . . 152

5.14 Priority based Scheduling . . . . . . . . . . . . . . . . . . . . . . . 155

5.15 How to chose RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.15.1 Functional Requirements . . . . . . . . . . . . . . . . . . . 157

5.15.2 Non-Functional Requirements . . . . . . . . . . . . . . . . 159

5.16 Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160


10 CONTENTS
Chapter 1

Introduction to Embedded Systems

1.1 What is Embedded System?

An Electronic/Electro mechanical system which is designed to


perform a specific function and is a combination of both
hardware and firmware (Software).
Examples : Electronic Toys, Mobile Handsets, Washing
Machines, Air Conditioners, Automotive Control Units, Set Top
Box, DVD Player etc.

Embedded Systems are:

1 Unique in character and behavior

2 With specialized hardware and software

11
12 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

1.2 Embedded Systems Vs General Computing


Systems

S.N. General Purpose Embedded System


Computing System
1 A system which is a A system which is a
combination of generic combination of special
hardware and General purpose hardware and
Purpose Operating System embedded OS for executing
for executing a variety of a specific set of applications
applications
2 Contain a General Purpose May or may not contain
Operating System (GPOS) an operating system for
functioning
3 Applications are alterable The firmware of the
(programmable) by user (It embedded system is pre-
is possible for the end user programmed and it is
to re-install the Operating non-alterable by end-user
System, and add or remove
user applications)
4 Performance is the key Application specific
deciding factor on the requirements (like
selection of the system. performance, power
Always ‘Faster is Better’ requirements, memory
usage etc) are the key
deciding factors
5 Less/not at all tailored Highly tailored to take
towards reduced operating advantage of the power
power requirements, options saving modes supported by
for different levels of power hardware and Operating
management. System
1.3. HISTORY OF EMBEDDED SYSTEMS 13

6 Response requirements are For certain category of


not time critical embedded systems like
mission critical systems, the
response time requirement is
highly critical.
7 Need not be deterministic in Execution behavior is
execution behavior deterministic for certain type
of embedded systems like
’Hard Real Time’ systems.

1.3 History of Embedded Systems

1 First Recognized Modern Embedded System: Apollo


Guidance Computer (AGC) developed by Charles Stark
Draper at the MIT Instrumentation Laboratory.

(a) It has two modules:


i. Command Module
ii. Lunar Excursion module (LEM)
(b) RAM size 256, 1K, 2K words.
(c) ROM size 4K, 10K, 36K words
(d) Clock frequency is 1.02 MHz
(e) 5000, 3-input RTL NOR gates are used
(f) User interface is DSKY (display/keyoard)

2 First Mass Produced Embedded System: Autonetics D-17


Guidance computer for Minuteman-I missile.

1.4 Classification of Embedded Systems

1 Based on Generation
14 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

2 Based on Complexity & Performance Requirements

3 Based on deterministic behavior

4 Based on Triggering

Embedded Systems - Classification based on Generation

1 First Generation:
The early embedded systems built around 8-bit
microprocessors like 8085 and Z80 and 4-bit
microcontrollers.
Examples : stepper motor control units, Digital Telephone
Keypads etc.

2 Second Generation:
Embedded Systems built around 16-bit microprocessors and
8 or 16-bit microcontrollers, following the first generation
embedded systems.
Examples : SCADA, Data Acquisition Systems etc.

3 Third Generation:
Embedded Systems built around high performance 16/32 bit
Microprocessors/controllers, Application Specific
Instruction set processors like Digital Signal Processors
(DSPs), and Application Specific Integrated Circuits
(ASICs).The instruction set is complex and powerful.
Examples : Robotics, industrial process control, networking
etc.

4 Fourth Generation:
Embedded Systems built around System on Chips (SoC’s),
Re- configurable processors and multicore processors. It
brings high performance, tight integration and
miniaturization into the embedded device market.
Examples : Smart phone devices, MIDs etc.
1.4. CLASSIFICATION OF EMBEDDED SYSTEMS 15

Embedded Systems - Classification based on Complexity &


Performance

1 Small Scale: The embedded systems built around low


performance and low cost 8 or 16 bit microprocessors/
microcontrollers. It is suitable for simple applications and
where performance is not time critical. It may or may not
contain OS.
2 Medium Scale: Embedded Systems built around medium
performance, low cost 16 or 32 bit microprocessors /
microcontrollers or DSPs. These are slightly complex in
hardware and firmware. It may contain GPOS/RTOS.

3 Large Scale/Complex: Embedded Systems built around high


performance 32 or 64 bit RISC processors/controllers, RSoC
or multi-core processors and PLD. It requires complex
hardware and software. These system may contain multiple
processors/controllers and co-units/hardware accelerators
for offloading the processing requirements from the main
processor. It contains RTOS for scheduling, prioritization
and management.

Embedded Systems - Classification Based on deterministic


behavior

Real Time systems. The application/task execution behavior for


an embedded system can be either deterministic or
non-deterministic.

These are classified in to two types :

1 Soft Real time Systems: Missing a deadline may not be


critical and can be tolerated to a certain degree.

2 Hard Real time systems: Missing a program/task execution


16 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

time deadline can have catastrophic consequences (financial,


human loss of life, etc.)

Embedded Systems - Classification Based on Triggering

These are classified into two types :

1 Event Triggered : Activities within the system (e.g., task run-


times) are dynamic and depend upon occurrence of different
events .

2 Time triggered: Activities within the system follow a


statically computed schedule (i.e., they are allocated time
slots during which they can take place) and thus by nature
are predictable.

1.5 Major Application Areas of Embedded Systems

1 Consumer Electronics: Camcorders, Cameras etc.

2 Household Appliances: Television, DVD players, washing


machine, Fridge, Microwave Oven etc.

3 Home Automation and Security Systems: Air conditioners,


sprinklers, Intruder detection alarms, Closed Circuit
Television Cameras, Fire alarms etc.

4 Automotive Industry: Anti-lock breaking systems (ABS),


Engine Control, Ignition Systems, Automatic Navigation
Systems etc.

5 Telecom: Cellular Telephones, Telephone switches, Handset


Multimedia Applications etc.

6 Computer Peripherals: Printers, Scanners, Fax machines etc.


1.6. PURPOSE OF EMBEDDED SYSTEMS 17

7 Computer Networking Systems: Network Routers,


Switches, Hubs, Firewalls etc.

8 Health Care: Different Kinds of Scanners, EEG, ECG


Machines etc.

9 Measurement & Instrumentation: Digital multi meters,


Digital CROs, Logic Analyzers PLC systems etc.

10 Banking & Retail: Automatic Teller Machines (ATM) and


Currency counters, Point of Sales (POS)

11 Card Readers: Barcode, Smart Card Readers, Hand held


Devices etc.

1.6 Purpose of Embedded Systems

Each Embedded Systems is designed to serve the purpose of any


one or a combination of the following tasks.

1 Data Collection/Storage/Representation

2 Data Communication

3 Data (Signal) Processing

4 Monitoring

5 Control

6 Application Specific User Interface

Data Collection/Storage/Representation

1 Performs acquisition of data from the external world.


18 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

2 The collected data can be either analog or digital.

3 Data collection is usually done for storage, analysis,


manipulation and transmission

4 The collected data may be stored directly in the system or


may be transmitted to some other systems or it may be
processed by the system or it may be deleted instantly after
giving a meaningful representation.

Data Communication

1 Embedded Data communication systems are deployed in


applications ranging from complex satellite communication
systems to simple home networking systems

2 Embedded Data communication systems are dedicated for


data communication.
3 The data communication can happen through a wired
interface (like Ethernet, RS-232C/USB/IEEE1394 etc) or
wireless interface (like Wi-Fi, GSM,/GPRS, Bluetooth,
ZigBee etc)

4 Network hubs, Routers, switches, Modems etc are typical


examples for dedicated data transmission embedded
systems.

Data (Signal) Processing

1 Embedded systems with Signal processing functionalities


are employed in applications demanding signal processing
like Speech coding, synthesis, audio video codec,
transmission applications etc

2 Computational intensive systems


1.6. PURPOSE OF EMBEDDED SYSTEMS 19

3 Employs Digital Signal Processors (DSPs)

Monitoring

1 Embedded systems coming under this category are


specifically designed for monitoring purpose.

2 They are used for determining the state of some variables


using input sensors.

3 They cannot impose control over variables.

4 Electro Cardiogram (ECG) machine for monitoring the heart


beat of a patient is a typical example for this.

5 The sensors used in ECG are the different Electrodes


connected to the patient’s body

6 Measuring instruments like Digital CRO, Digital Multi


meter, Logic Analyzer etc used in Control & Instrumentation
applications are also examples of embedded systems for
monitoring purpose.

Control

1 Embedded systems with control functionalities are used for


imposing control over some variables according to the
changes in input variables.

2 Embedded system with control functionality contains both


sensors and actuators
3 Sensors are connected to the input port for capturing the
changes in environmental variable or measuring variable.

4 The actuators connected to the output port are controlled


according to the changes in input variable to put an impact
20 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

on the controlling variable to bring the controlled variable to


the specified range.

5 Air conditioner for controlling room temperature is a typical


example for embedded system with ‘Control’ functionality.

6 Air conditioner contains a room temperature sensing element


(sensor) which may be a thermistor and a handheld unit for
setting up (feeding) the desired temperature.

7 The air compressor unit acts as the actuator. The compressor


is controlled according to the current room temperature and
the desired temperature set by the end user.

Application Specific User Interface

1 Embedded systems which are designed for a specific


application.

2 Contains Application Specific User interface (rather than


general standard UI ) like key board, Display units etc.

3 Aimed at a specific target group of users.

4 Mobile handsets, Control units in industrial applications etc


are examples.

1.7 Embedded System Design Process

This section provides an overview of the embedded system


design process aimed at two objectives. First, it will give us an
introduction to the various steps in embedded system design
before we delve into them in more detail. Second, it will allow us
to consider the design methodology itself. A design methodology
is important for three reasons. First, it allows us to keep a
scorecard on a design to ensure that we have done everything we
1.7. EMBEDDED SYSTEM DESIGN PROCESS 21

need to do, such as optimizing performance or performing


functional tests. Second, it allows us to develop computer-aided
design tools. Developing a single program that takes in a concept
for an embedded system and emits a completed design would be
a daunting task, but by first breaking the process into manageable
steps, we can work on automating (or at least semi automating)
the steps one at a time. Third, a design methodology makes it
much easier for members of a design team to communicate.

The below Figure 1.1summarizes the major steps in the


embedded system design process. In this top–down view, we start
with the system requirements.

Figure 1.1: Major levels of abstraction in the design process

Requirements

Clearly, before we design a system, we must know what we are


designing. The initial stages of the design process capture this
information for use in creating the architecture and components.
We generally proceed in two phases: First, we gather an informal
description from the customers known as requirements, and we
refine the requirements into a specification that contains enough
information to begin designing the system architecture.

Requirements may be functional or nonfunctional. We


22 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

must of course capture the basic functions of the embedded


system, but functional description is often not sufficient. Typical
nonfunctional requirements include:

1 Performance: The speed of the system is often a major


consideration both for the usability of the system and for its
ultimate cost. As we have noted, performance may be a
combination of soft performance metrics such as
approximate time to perform a user-level function and hard
deadlines by which a particular operation must be
completed.

2 Cost: The target cost or purchase price for the system is


almost always a consideration. Cost typically has two major
components: manufacturing cost includes the cost of
components and assembly; nonrecurring engineering (NRE)
costs include the personnel and other costs of designing the
system.

3 Physical size and weight: The physical aspects of the final


system can vary greatly depending upon the application. An
industrial control system for an assembly line may be
designed to fit into a standard-size rack with no strict
limitations on weight. A handheld device typically has tight
requirements on both size and weight that can ripple
through the entire system design.

4 Power consumption: Power, of course, is important in


battery-powered systems and is often important in other
applications as well. Power can be specified in the
requirements stage in terms of battery life—the customer is
unlikely to be able to describe the allowable wattage.
A sample requirements form that can be filled out at the start
of the project. We can use the form as a checklist in
considering the basic characteristics of the system. Let’s
consider the entries in the form:
1.7. EMBEDDED SYSTEM DESIGN PROCESS 23

5 Name: This is simple but helpful. Giving a name to the


project not only simplifies talking about it to other people
but can also crystallize the purpose of the machine.
6 Purpose: This should be a brief one- or two-line description
of what the system is supposed to do. If you can’t describe
the essence of your system in one or two lines, chances are
that you don’t understand it well enough.
7 Inputs and outputs: These two entries are more complex
than they seem. The inputs and outputs to the system
encompass a wealth of detail:
(a) Types of data: Analog electronic signals? Digital data?
Mechanical inputs?
(b) Data characteristics: Periodically arriving data, such as
digital audio samples? Occasional user inputs? How
many bits per data element?
(c) Types of I/O devices: Buttons? Analog/digital
converters? Video displays?
8 Functions: This is a more detailed description of what the
system does. A good way to approach this is to work from
the inputs to the outputs: When the system receives an input,
what does it do? How do user interface inputs affect these
functions? How do different functions interact?
9 Performance: Many embedded computing systems spend at
least some time controlling physical devices or processing
data coming from the physical world. In most of these cases,
the computations must be performed within a certain time
frame. It is essential that the performance requirements be
identified early since they must be carefully measured
during implementation to ensure that the system works
properly.

10 Manufacturing cost: This includes primarily the cost of the


hardware components. Even if you don’t know exactly how
24 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

much you can afford to spend on system components, you


should have some idea of the eventual cost range. Cost has a
substantial influence on architecture: A machine that is meant
to sell at 10 dollar most likely has a very different internal
structure than a 100 dollar system.

11 Power: Similarly, you may have only a rough idea of how


much power the system can consume, but a little information
can go a long way. Typically, the most important decision
is whether the machine will be battery powered or plugged
into the wall. Battery-powered machines must be much more
careful about how they spend energy.

12 Physical size and weight: You should give some indication


of the physical size of the system to help guide certain
architectural decisions. A desktop machine has much more
flexibility in the components used than, for example, a lapel
mounted voice recorder.

1.8 Characteristics of Embedded systems

Embedded systems possess certain specific characteristics and


these are unique to each Embedded system.

1 Application and Domain Specific


(a) Each E.S has certain functions to perform and they are
developed in such a manner to do the intended functions
only.
(b) They cannot be used for any other purpose.
(c) Ex – The embedded control units of the microwave oven
cannot be replaced with AC’S embedded control unit
because the embedded control units of microwave oven
and AC are specifically designed to perform certain
specific tasks.
1.8. CHARACTERISTICS OF EMBEDDED SYSTEMS 25

2 Reactive and Real Time

(a) Embedded System 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.
(b) Any changes 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.
(c) E.S produce changes in output in response to the changes
in the input, so they are referred as reactive systems.
(d) Real Time system operation means the timing behavior of
the system should be deterministic ie the system should
respond to requests in a known amount of time.
(e) Example – E.S which are mission critical like flight control
systems, Antilock Brake Systems (ABS) etc are Real Time
systems.

3 Operates in Harsh Environment

(a) The design of E.S should take care of the operating


conditions of the area where the system is going to
implement.
(b) Ex – 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.
(c) Also proper shock absorption techniques should be
provided to systems which are going to be
commissioned in places subject to high shock.

4 Distributed

(a) It means that embedded systems may be a part of a larger


system.
26 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

(b) Many numbers of such distributed embedded systems


form a single large embedded control unit.
(c) Ex – Automatic vending machine. It contains a card
reader, a vending unit etc. Each of them are independent
embedded units but they work together to perform the
overall vending function.

5 Small Size and Weight


(a) Product aesthetics (size, weight, shape, style, etc) is an
important factor in choosing a product.
(b) It is convenient to handle a compact device than a bulky
product.

6 Power Concerns
(a) Power management is another important factor that
needs to be considered in designing embedded systems.
(b) E.S should be designed in such a way as to minimize the
heat dissipation by the system.

7 Single-functioned: Dedicated to perform a single function

8 Complex functionality: We have to run sophisticated


algorithms or multiple algorithms in some applications.

9 Tightly-constrained: Low cost, low power, small, fast, etc

10 Safety-critical: Must not endanger human life and the


environment

1.9 Quality Attributes of Embedded System

Quality attributes are the non-functional requirements that need


to be documented properly in any system design.

Quality attributes can be classified as :


1.9. QUALITY ATTRIBUTES OF EMBEDDED SYSTEM 27

1 Operational quality attributes

2 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.

Operational Quality Attributes are:

1 Response
(a) It is the measure of quickness of the system.
(b) It tells how fast the system is tracking the changes in
input variables.
(c) Most of the E.S demands fast response which should be
almost real time.
(d) Ex – Flight control application.

2 Throughput
(a) It deals with the efficiency of a system.
(b) It can be defined as the rate of production or operation of
a defined process over a stated period of time.
(c) The rates can be expressed in terms of products, batches
produced or any other meaningful measurements.
(d) Ex – In case of card reader throughput means how many
transactions the reader can perform in a minute or in an
hour or in a day.
(e) Throughput is generally measured in terms of
’Benchmark’.
(f) A Benchmark is a reference point by which something
can be measured
28 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

3 Reliability
(a) It is a measure of how much we can rely upon the proper
functioning of the system.
(b) Mean Time Between Failure (MTBF) and Mean Time To
Repair (MTTR) are the terms used in determining system
reliability.
(c) MTBF gives the frequency of failures in
hours/weeks/months.
(d) MTTR specifies how long the system is allowed to be out
of order following a failure.
(e) For embedded system with critical application need, it
should be of the order of minutes.
4 Maintainability
(a) It deals with support and maintenance to the end user or
client in case of technical issues and product failure or on
the basis of a routine system checkup.
(b) Reliability and maintainability are complementary to
each other.
(c) A more reliable system means a system with less
corrective maintainability requirements and vice versa.
(d) Maintainability can be broadly classified into two
categories :
i. Scheduled or Periodic maintenance (Preventive
maintenance)
ii. Corrective maintenance to unexpected failures

5 Security
(a) Confidentiality, Integrity and availability are the three
major measures of information security.
(b) Confidentiality deals with protection of data and
application from unauthorized disclosure.
1.9. QUALITY ATTRIBUTES OF EMBEDDED SYSTEM 29

(c) Integrity deals with the protection of data and application


from unauthorized modification.
(d) Availability deals with protection of data and application
from unauthorized users.
6 Safety
(a) Safety deals with the possible damages that can happen
to the operator, public and the environment due to the
breakdown of an Embedded System.
(b) The breakdown of an embedded system may occur due
to a hardware failure or a firmware failure.
(c) 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
damage 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.

1 Testability and Debug-ability


(a) Testability deals with how easily one can test the design,
application and by which means it can be done.
(b) For an E.S testability is applicable to both the embedded
hardware and firmware.
(c) Embedded hardware testing ensures that the peripherals
and total hardware functions in the desired manner,
whereas firmware testing ensures that the firmware is
functioning in the expected way.
(d) Debug-ability is a means of debugging the product from
unexpected behavior in the system
30 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

(e) Debug-ability is two level process :


i. Hardware level: It is used for finding the issues
created by hardware problems.
ii. Software level: It is employed for finding the errors
created by the flaws in the software.
2 Evolvability
(a) It is a term which is closely related to Biology.
(b) It is referred as the non-heritable variation.
(c) For an embedded system evolvability refers to the ease
with which the embedded product can be modified to
take advantage of new firmware or hardware
technologies.

3 Portability
(a) It is the measure of system independence.
(b) An embedded product is said to be portable if the
product is capable of functioning in various
environments, target processors and embedded
operating systems.
(c) ‘Porting’ represents the migration of embedded
firmware written for one target processor to a different
target processor.

4 Time-to-Prototype and Market


(a) It is the time elapsed between the conceptualization of a
product and the time at which the product is ready for
selling.
(b) The commercial embedded product market is highly
competitive and time to market the product is critical
factor in the success of commercial embedded product.
(c) There may be multiple players in embedded industry
who develop products of the same category (like mobile
phone).
1.10. SUMMARY 31

5 Per Unit Cost and Revenue

(a) Cost is a factor which is closely monitored by both end


user and product manufacturer.
(b) Cost is highly sensitive factor for commercial products
(c) 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.
(d) Proper market study and cost benefit analysis should be
carried out before taking a decision on the per-unit cost
of the embedded product.
(e) The ultimate aim of the product is to generate marginal
profit so the budget and total cost should be properly
balanced to provide a marginal profit.

1.10 Summary

1 An embedded system is an electronic/electromechanical


system designed to perform a specific function and is a
combination of both hardware and firmware (software).

2 A general purpose computing system is a combination of


generic hardware and general purpose operating system for
executing a variety of applications, whereas an embedded

3 System is a combination of special purpose hardware and


embedded OS/firmware for executing a specific set of
applications.

4 Apollo Guidance Computer (AGC) is the first recognized


modern embedded system and Autonetics D-17, the
guidance computer for the Minuteman-I missile, was the
first mass produced embedded system.
32 CHAPTER 1. INTRODUCTION TO EMBEDDED SYSTEMS

5 Based on the complexity and performance requirements,


embedded systems are classified into small-scale,
medium-scale and large-scale/complex.

6 The presences of embedded system vary from simple


electronic system toys to complex flight and missile control
systems.

7 Embedded systems are designed to serve the purpose of any


one or combination of data
collection/storage/representation, data processing,
monitoring, control or application specific user interface.

8 Wearable devices refer to embedded systems which are


incorporated into accessories and apparels. It envisions the
bonding of embedded technology in our day to day lives.
Chapter 2

Typical Embedded System

2.1 Elements of Embedded System

An embedded system is a combination of 3 things, Hardware


Software Mechanical Components and it is supposed to do one
specific task only. A typical embedded system contains a single
chip controller which acts as the master brain of the system.
Diagrammatically an embedded system can be represented as
follows:

Figure 2.1: Real World

33
34 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Embedded systems are basically designed to regulate a


physical variable (such Microwave Oven) or to manipulate the
state of some devices by sending some signals to the actuators or
devices connected to the output port system (such as temperature
in Air Conditioner), in response to the input signal provided by
the end users or sensors which are connected to the input ports.
Hence the embedded systems can be viewed as a reactive system.

The control is achieved by processing the information


coming from the sensors and user interfaces and controlling
some actuators that regulate the physical variable.

Keyboards, push button, switches, etc. are Examples of


common user interface input devices and LEDs, LCDs,
Piezoelectric buzzers, etc examples for common user interface
output devices for a typical embedded system.The requirement
of type of user interface changes from application to application
based on domain.

Some embedded systems do not require any manual


intervention for their operation. They automatically sense the
input parameters from real world through sensors which are
connected at input port. The sensor information is passed to the
processor after signal conditioning and digitization. The core of
the system performs some predefined operations on input data
with the help of embedded firmware in the system and sends
some actuating signals to the actuator connect connected to the
output port of the system.

The memory of the system is responsible for holding the


code (control algorithm and other important configuration
details). There are two types of memories are used in any
embedded system. Fixed memory (ROM) is used for storing code
or program. The user cannot change the firmware in this type of
memory. The most common types of memories used in
embedded systems for control algorithm storage are
OTP,PROM,UVEPROM,EEPROM and FLASH .
2.2. THE CORE OF THE EMBEDDED SYSTEMS 35

An embedded system without code (i.e. the control


algorithm) implemented memory has all the peripherals but is
not capable of making decisions depending on the situational as
well as real world changes.

Memory for implementing the code may be present on


the processor or may be implemented as a separate chip
interfacing the processor,

In a controller based embedded system, the controller


may contain internal memory for storing code such controllers
are called Micro-controllers with on-chip ROM, eg. Atmel
AT89C51.

2.2 The Core of the Embedded Systems

The core of the embedded system falls into any one of the
following categories.

1 General Purpose and Domain Specific Processors


(a) Microprocessors
(b) Microcontrollers
(c) Digital Signal Processors

2 Programmable Logic Devices (PLDs)

3 Application Specific Integrated Circuits (ASICs)

4 Commercial off the shelf Components (COTS)

General Purpose and Domain Specific Processors

1 Almost 80% of the embedded systems are processor/


controller based.
36 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

2 The processor may be microprocessor or a microcontroller or


digital signal processor, depending on the domain and
application.

Microprocessor

1 A silicon chip representing a Central Processing Unit (CPU),


which is capable of performing arithmetic as well as logical
operations according to a pre-defined set of Instructions,
which is specific to the manufacturer.

2 In general the CPU contains the Arithmetic and Logic Unit


(ALU), Control Unit and Working registers.

3 Microprocessor is a dependent unit and it requires the


combination of other hardware like Memory, Timer Unit,
and Interrupt Controller etc for proper functioning.

4 Intel claims the credit for developing the first Microprocessor


unit Intel 4004, a 4 bit processor which was released in Nov
1971.

5 Developers of microprocessors:

(a) Intel – Intel 4004 – November 1971(4-bit)


(b) Intel – Intel 4040.
(c) Intel – Intel 8008 – April 1972.
(d) Intel – Intel 8080 – April 1974(8-bit).
(e) Motorola – Motorola 6800.
(f) Intel – Intel 8085 – 1976.
(g) Zilog - Z80 – July 1976
2.2. THE CORE OF THE EMBEDDED SYSTEMS 37

Microcontroller

1 A highy integrated silicon chip containing a CPU, scratch


pad RAM, Special and General purpose Register Arrays, On
chip ROM/FLASH memory for program storage, Timer and
Interrupt control units and dedicated I/O ports.

2 Microcontrollers can be considered as a super set of


microprocessors.

3 Microcontroller can be general purpose (like Inte 8051,


designed for generic applications and domains) or
application specific (like Automotive AVR from Atmel
Corporation. Designed specifically for automotive
applications).

4 Since a microcontroller contains all the necessary functional


blocks for independent working, they found greater place in
the embedded domain in place of microprocessors.

5 Microcontrollers are cheap, cost effective and are readily


available in the market.
6 Texas Instruments TMS 1000 is considered as the world’s first
microcontroller.
38 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Microprocessor Vs Microcontroller

S.N. Microprocessor Microcontroller


1 A silicon chip representing A microcontroller is a highly
a Central Processing Unit integrated chip that contains
(CPU), which is capable of a CPU, scratch pad RAM,
performing arithmetic as Special and General purpose
well as logical operations Register Arrays, On Chip
according to a pre-defined ROM/FLASH memory for
set of Instructions program storage, Timer and
Interrupt control units and
dedicated I/O ports
2 It is a dependent unit. It It is a self contained unit and
requires the combination it doesn’t require external
of other chips like Timers, Interrupt Controller, Timer,
Program and data memory UART etc for its functioning
chips, Interrupt controllers
etc for functioning
3 Most of the time general Mostly application oriented
purpose in design and or domain specific
operation
4 Doesn’t contain a built in Most of the processors
I/O port. The I/O Port contain multiple built-in I/O
functionality needs to be ports which can be operated
implemented with the help as a single 8 or 16 or 32 bit
of external Programmable Port or as individual port
Peripheral Interface Chips pins
like 8255
5 Targeted for high end Targeted for embedded
market where performance market where performance
is important is not so critical (At present
this demarcation is invalid)
6 Limited power saving Includes lot of power saving
options compared to features
microcontrollers
2.3. GENERAL PURPOSE PROCESSOR (GPP) VS APPLICATION SPECIFIC INSTRUCTION

2.3 General Purpose Processor (GPP) Vs


Application Specific Instruction Set Processor
(ASIP)

1 General purpose processor or GPP is a processor designed for


general computational tasks.

2 GPPs are produced in large volumes and targeting the


general market. due to the high volume production, the per
unit cost for a chip is low compared to ASIC or other specific
ICs.
3 A typical general purpose processor contains an arithmetic
and Logic Unit (ALU) and Control Unit (CU).

4 Application Specific Instruction Set processors (ASIPs) are


processors with architecture and instruction set optimized to
specific domain/application requirements like Network
processing, Automotive, Telecom, media applications,
digital signal processing, control applications etc.

5 ASIPs fill the architectural spectrum between General


Purpose Processors and Application Specific Integrated
Circuits (ASICs).

6 The need for an ASIP arises when the traditional general


purpose processor are unable to meet the increasing
application needs.

7 Some Microcontrollers (Like Automotive AVR, USB AVR


from Atmel), System on chips, Digital Signal Processors etc
are examples of Application Specific Instruction Set
Processors (ASIPs).

8 ASIPs incorporate a processor and on-chip peripherals,


demanded by the application requirement, program and
data memory.
40 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Digital Signal Processors (DSPs):

1 Powerful special purpose 8/16/32 bit microprocessors


designed specifically to meet the computational demands
and power constraints of today’s embedded audio, video,
and communications applications.

2 Digital Signal Processors are 2 to 3 times faster than the


general purpose microprocessors in signal processing
applications.

3 DSPs implement algorithms in hardware which speeds up


the execution whereas general purpose processors
implement the algorithm in firmware and the speed of
execution depends primarily on the clock for the processors.

4 DSP can be viewed as a microchip designed for performing


high speed computational operations for addition ,
subtraction, multiplication and division.

5 A typical Digital Signal Processor incorporates the following


key units
(a) Program Memory
(b) Data Memory
(c) Computational Engine
(d) I/O Unit

6 Audio video signal processing, telecommunication and


multimedia applications are typical examples where DSP is
employed
2.4. RISC V/S CISC PROCESSORS/CONTROLLERS 41

2.4 RISC V/s CISC Processors/Controllers

S.N. RISC CISC


1 Lesser no. of instructions Greater no. of Instructions
2 Instruction Pipelining and Generally no instruction
increased execution speed. pipelining feature
3 Orthogonal Instruction Set Non Orthogonal Instruction
(Allows each instruction to Set (All instructions are
operate on any register and not allowed to operate on
use any addressing mode) any register and use any
addressing mode. It is
instruction specific)
4 Operations are performed Operations are performed
on registers only, the only on registers or memory
memory operations are load depending on the instruction
and store
5 Large number of registers are Limited no. of general
available purpose registers
6 Programmer needs to write A programmer can achieve
more code to execute a task the desired functionality
since the instructions are with a single instruction
simpler ones which in turn provides the
effect of using more simpler
single instructions in RISC
7 Single, Fixed length Variable length Instructions
Instructions
8 Less Silicon usage and pin More silicon usage since
count more additional decoder
logic is required to
implement the complex
instruction decoding.
9 With Harvard Architecture Can be Harvard or Von-
Neumann Architecture
42 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

2.5 Harvard V/s Von-Neumann


Processor/Controller Architecture

1 The terms Harvard and Von-Neumann refers to the processor


architecture design.

2 Microprocessors/controllers based on the common bus for


fetching both instructions stored in a common main memory.

3 Von-Neumann architecture shares a single and data. Program


instructions and data are Microprocessors/controllers based
on the Harvard architecture will have separate data bus and
instruction bus. This allows the data transfer and program
fetching to occur simultaneously on both buses.

4 With Harvard architecture, the data memory can be read and


written while the program memory is being accessed. These
separated data memory and code memory buses allow one
instruction to execute while the next instruction is fetched
(’Pre-fetching’).

Figure 2.2:

S.N. Harvard Architecture Von-Neumann Architecture


1 Separate buses for Single shared bus for
Instruction and Data fetching Instruction and Data fetching
2.6. BIG-ENDIAN V/S LITTLE-ENDIAN PROCESSORS 43

2 Easier to Pipeline, so high Low performance Compared


performance can be achieved to Harvard Architecture
3 Comparatively high cost Cheaper
4 No memory alignment Allows self modifying codes
problems
5 Since data memory and Since data memory and
program memory are stored program memory are stored
physically in different physically in same chip,
locations, no chances for chances for accidental
accidental corruption of corruption of program
program memory memory

2.6 Big-endian V/s Little-endian processors

1 Endianness specifies the order in which the data is stored in


the memory by processor. operations in a multi byte system
(Processors whose word size is greater than one byte).
Suppose the word length is two byte then data can be stored
in memory in two different ways.

(a) Higher order of data byte at the higher memory and


lower order of data byte at location just below the higher
memory.
(b) Lower order of data byte at the higher memory and
higher order of data byte at location just below the
higher memory.

2 Little-endian means the lower-order byte of the data is stored


in memory at the lowest address, and the higher order byte
at the highest address. (The little end comes first).

3 Big-endian means the higher-order byte of the data is stored


in memory at the lowest address, and the lower-order byte at
the highest address. (The big end comes first.)
44 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Figure 2.3: Big-endian operation

2.7 Load Store Operation & Instruction Pipelining

The RISC processor instruction set is orthogonal and it operates on


registers. The memory access related operations are performed by
the special instructions load and store. If the operand is specified as
memory location, the content of it is loaded to a register using the
load instruction. The instruction store stores data from a specified
register to a specified memory location.

Figure 2.4: Load-Store operation


2.8. APPLICATION SPECIFIC INTEGRATED CIRCUIT (ASIC) 45

1 The conventional instruction execution by the processor


follows the fetch-decode-execute sequence

2 The ’fetch’ part fetches the instruction from program memory


or code memory and the decode part decodes the instruction
to generate the necessary control signals

Figure 2.5: A single stage pipelining concept

3 The execute stage reads the operands, perform ALU


operations and stores the result. In conventional program
execution, the fetch and decode operations are performed in
sequence.

4 During the decode operation the memory address bus is


available and if it possible to effectively utilize it for an
instruction fetch, the processing speed can be increased.

5 In its simplest form instruction pipelining refers to the


overlapped execution of instructions.

2.8 Application Specific Integrated Circuit (ASIC)

1 A microchip designed to perform a specific or unique


application. It is used as replacement to conventional
general purpose logic chips.
46 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

2 ASIC integrates several functions into a single chip and


thereby reduces the system development cost.

3 Most of the ASICs are proprietary products. As a single chip,


ASIC consumes very small area in the total system and
thereby helps in the design of smaller systems with high
capabilities/functionalities.

4 ASICs can be pre-fabricated for a special application or it can


be custom fabricated by using the components from a
re-usable ’building block’ library of components for a
particular customer application.

Figure 2.6: Application Specific Integrated Circuit

5 Fabrication of ASICs requires a non-refundable initial


investment (Non Recurring Engineering (NRE) charges) for
the process technology and configuration expenses

6 If the Non-Recurring Engineering Charges (NRE) is born by


a third party and the Application Specific Integrated Circuit
(ASIC) is made openly available in the market, the ASIC is
referred as Application Specific Standard Product (ASSP)

7 The ASSP is marketed to multiple customers just as a general-


purpose product , but to a smaller number of customers since
it is for a specific application.
2.9. PROGRAMMABLE LOGIC DEVICES (PLDS) 47

8 Some ASICs are proprietary products , the developers are not


interested in revealing the internal details.

2.9 Programmable Logic Devices (PLDs)

1 Logic devices provide specific functions including


device-to-device interfacing data communication, signal
processing, data display, timing and control operations, and
almost every other function a system must perform.

2 Logic devices can be classified into two broad categories-


fixed and programmable. The circuits in a fixed logic device
are permanent, they perform one function or set of functions
- once manufactured, they cannot be changed.

3 Programmable logic devices (PLDs) offer customers a wide


range of logic capacity, features, speed and voltage
characteristics - and these devices can be reconfigured to
perform any number of functions at any time.

4 Designers can use inexpensive software tools to quickly


develop, simulate and test their logic designs in PLD based
design. The design can be quickly programmed into a device
and immediately tested in a live circuit.

5 PLDs are based on re-writable memory technology and the


device is reprogrammed to change the design.

6 Field Programmable Gate Arrays (FPGAs) and Complex


Programmable Logic Devices (CPLDs) are the two major
types of programmable logic devices
48 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Field Programmable Gate Array

1 FPGA is an IC designed to be configured by a designer after


manufacturing.

2 FPGAs offer the highest amount of logic density, the most


features, and the highest performance.

3 Logic gate is Medium to high density ranging from 1K to


500K system gates.

4 These advanced FPGA devices also offer features such as


built-in hardwired processors (such as the IBM Power PC),
substantial amounts of memory, clock management systems,
and support for many of the latest, very fast device-to-device
signaling technologies.

Figure 2.7: FPGA Architecture

5 These advanced FPGA devices also offer features such as


built-in hardwired processors, substantial amounts of
memory, clock management systems, and support for many
of the latest, very fast device-to-device signaling
technologies.
2.9. PROGRAMMABLE LOGIC DEVICES (PLDS) 49

6 FPGAs are used in a wide variety of applications ranging


from data processing and storage, to instrumentation,
telecommunications, and digital signal processing

Complex Programmable Logic Devices

1 A complex programmable logic device (CPLD) is a


programmable logic device with complexity between that of
PALs and FPGAs, and architectural features of both.

2 CPLDs, by contrast, offer much smaller amounts of logic - up


to about 10,000 gates.

3 CPLDs offer very predictable timing characteristics and are


therefore ideal for critical control applications.

Figure 2.8: Structure of CPLD

4 CPLDs such as the Xilinx CoolRunner series also require


extremely low amounts of power and are very inexpensive,
making them ideal for cost-sensitive, battery-operated,
portable applications such as mobile phones and digital
handheld assistants.
50 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

ADVANTAGES OF PLDs

1 PLDs offer customer much more flexibility during design


cycle.

2 PLDs do not require long lead times for prototype or


production-the PLDs are already on a distributor’s self and
ready for shipment.

3 PLDs do not require customers to pay for large NRE costs and
purchase expensive mask sets.

4 PLDs allow customers to order just the number of parts


required when they need them. allowing them to control
inventory.

5 PLDs are reprogrammable even after a piece of equipment is


shipped to a customer.

6 The manufacturers able to add new features or upgrade the


PLD based products that are in the field by uploading new
programming file.

2.10 Commercial off the Shelf Component (COTS)

1 A Commercial off-the-shelf (COTS) product is one which is


used ’as-is’

2 COTS products are designed in such a way to provide easy


integration and interoperability with existing system
components.

3 Typical examples for the COTS hardware unit are Remote


Controlled Toy Car control unit including the RF Circuitry
part, High performance, high frequency microwave
electronics (2 to 200 GHz), High bandwidth analog-to-digital
2.10. COMMERCIAL OFF THE SHELF COMPONENT (COTS) 51

converters, Devices and components for operation at very


high temperatures, Electro-optic IR imaging arrays, UV/IR
Detectors etc.

Figure 2.9:

4 A COTS component in turn contains a General Purpose


Processor (GPP) or Application Specific Instruction Set
Processor (ASIP) or Application Specific Integrated Chip
(ASIC)/Application Specific Standard Product (ASSP) or
Programmable Logic Device (PLD).

Figure 2.10:

5 The major advantage of using COTS is that they are readily


available in the market, cheap and a developer can cut down
his/her development time to a great extend.
52 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

6 There is no need to design the module yourself and write the


firmware .

7 Everything will be readily supplied by the COTs


manufacturer.

8 The major problem faced by the end-user is that there are no


operational and manufacturing standards.

9 The major drawback of using COTs component in embedded


design is that the manufacturer may withdraw the product or
discontinue the production of the COTs at any time if rapid
change in technology.

10 This problem adversely affect a commercial manufacturer of


the embedded system which makes use of the specific COTs

2.11 Memory

1 Memory is an important part of an embedded system. The


memory used in embedded system can be either Program
Storage Memory (ROM) or Data memory (RAM).

2 Certain Embedded processors/controllers contain built in


program memory and data memory and this memory is
known as on-chip memory.

3 Certain Embedded processors/controllers do not contain


sufficient memory inside the chip and requires external
memory called off-chip memory or external memory.

Memory – Program Storage Memory:

1 Stores the program instructions.


2.11. MEMORY 53

2 Retains its contents even after the power to it is turned off. It


is generally known as Non-volatile storage memory.

3 Depending on the fabrication, erasing and programming


techniques they are classified into :

Figure 2.11: Memory Classification

(a) Masked ROM (MROM)


i. One-time programmable memory.
ii. Uses hardwired technology for storing data.
iii. The device is factory programmed by masking and
metallization process according to the data provided
by the end user.
iv. The primary advantage of MROM is low cost for high
volume production.
v. MROM is the least expensive type of solid state
memory.
vi. Different mechanisms are used for the masking
process of the ROM, like
• Creation of an enhancement or depletion mode
transistor through channel implant.
• By creating the memory cell either using a
standard transistor or a high threshold transistor.
• In the high threshold mode, the supply voltage
required to turn ON the transistor is above the
normal ROM IC operating voltage.
54 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

• This ensures that the transistor is always off and


the memory cell stores always logic 0.
vii. The limitation with MROM based firmware storage
is the inability to modify the device firmware against
firmware upgrades.
viii. The MROM is permanent in bit storage, it is not
possible to alter the bit information.
(b) Programmable Read Only Memory (PROM) / (OTP)
i. It is not pre-programmed by the manufacturer.
ii. The end user is responsible for Programming these
devices.
iii. PROM/OTP has nichrome or polysilicon wires
arranged in a matrix, these wires can be functionally
viewed as fuses.
iv. It is programmed by a PROM programmer which
selectively burns the fuses according to the bit
pattern to be stored.
v. Fuses which are not blown/burned represents a logic
’1’ where as fuses which are blown/burned
represents a logic ’0’.The default state is logic ’1’.
vi. OTP is widely used for commercial production of
embedded systems whose proto-typed versions are
proven and the code is finalized.
vii. It is a low cost solution for commercial production.
viii. OTPs cannot be reprogrammed.
(c) Erasable Programmable Read Only Memory (EPROM)
i. Erasable Programmable Read Only (EPROM)
memory gives the flexibility to re-program the same
chip.
ii. During development phase , code is subject to
continuous changes and using an OTP is not
economical.
iii. EPROM stores the bit information by charging the
floating gate of an FET
2.11. MEMORY 55

iv. Bit information is stored by using an EPROM


Programmer, which applies high voltage to charge
the floating gate.
v. EPROM contains a quartz crystal window for erasing
the stored information. If the window is exposed to
Ultra violet rays for a fixed duration, the entire
memory will be erased.
vi. Even though the EPROM chip is flexible in terms of
re-programmability, it needs to be taken out of the
circuit board and needs to be put in a UV eraser
device for 20 to 30 minutes.
(d) Electrically Erasable Programmable Read Only
Memory (EEPROM)
i. Erasable Programmable Read Only (EPROM)
memory gives the flexibility to re-program the same
chip using electrical signals.
ii. The information contained in the EEPROM memory
can be altered by using electrical signals at the
register/Byte level.
iii. They can be erased and reprogrammed within the
circuit.
iv. These chips include a chip erase mode and in this
mode they can be erased in a few milliseconds.
v. It provides greater flexibility for system design.
vi. The only limitation is their capacity is limited when
compared with the standard ROM (A few kilobytes).
(e) Program Storage Memory – FLASH
i. FLASH memory is a variation of EEPROM
technology.
ii. FALSH is the latest ROM technology and is the most
popular ROM technology used in today’s embedded
designs.
iii. It combines the re-programmability of EEPROM and
the high capacity of standard ROMs.
56 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

iv. FLASH memory is organized as sectors (blocks) or


pages.
v. FLASH memory stores information in an array of
floating gate MOSFET transistors.
vi. The erasing of memory can be done at sector level or
page level without affecting the other sectors or
pages.
vii. Each sector/page should be erased before
re-programming.
viii. The typical erasable capacity of FLASH is of the order
of a few 1000 cycles.

4 Read-Write Memory/Random Access Memory (RAM)


(a) RAM is the data memory or working of the
controller/processor.
(b) RAM is volatile, meaning when the power is turned off,
all the contents are destroyed.
(c) RAM is a direct access memory, meaning we can access
the desired memory location directly without the need
for traversing through the entire memory locations to
reach the desired memory position (i.e. Random Access
of memory location)

Figure 2.12: Classification of RAM

(d) Static RAM (SRAM)


2.11. MEMORY 57

i. Static RAM stores data in the form of voltage.


ii. They are made up of flip-flops.
iii. In typical implementation, an SRAM cell (bit) is
realized using 6 transistors (or 6 MOSFETs).
iv. Four of the transistors are used for building the latch
(flip-flop) part of the memory cell and 2 for
controlling the access.
v. Static RAM is the fastest form of RAM available.
vi. SRAM is fast in operation due to its resistive
networking and switching capabilities.

Figure 2.13: SRAM Cell Implementation

(e) Dynamic RAM (DRAM)

i. Dynamic RAM stores data in the form of charge. They


are made up of MOS transistor gates.
ii. The advantages of DRAM are its high density and low
cost compared to SRAM.
iii. The disadvantage is that since the information is
stored as charge it gets leaked off with time and to
prevent this they need to be refreshed periodically.
iv. Special circuits called DRAM controllers are used for
the refreshing operation. The refresh operation is
done periodically in milliseconds interval.
58 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

Figure 2.14: DRAM Cell implementation

(f) Non Volatile RAM (NVRAM)


i. Random access memory with battery backup.
ii. It contains Static RAM based memory and a minute
battery for providing supply to the memroy in the
absence of external power supply.
iii. The memory and battery are packed together in a
single package.
iv. NVRAM is used for the non volatile storage of results
of operations or for setting up of flags etc.
v. The life span of NVRAM is expected to be around 10
years.
vi. DS1744 from Maxim/Dallas is an example for 32KB
NVRAM.
SRAM Vs DRAM :
S.N. SRAM DRAM
1 Made up of 6 CMOS Made up of a MOSFET and
transistors (MOSFET) a capacitor
2 Doesn’t Require refreshing Requires refreshing
3 Low capacity (Less dense) High Capacity (Highly
dense)
4 More expensive Less Expensive
2.11. MEMORY 59

5 Fast in operation. Typical Slow in operation due


access time is 10ns to refresh requirements.
Typical access time is 60ns.
Write operation is faster
than read operation.

Memory selection for Embedded Systems

1 Selection of suitable memory is very much essential step in


high performance applications, because the challenges and
limitations of the system performance are often decided upon
the type of memory architecture.

2 Systems memory requirement depend primarily on the


nature of the application that is planned to run on the
system.

3 Memory performance and capacity requirement for low cost


systems are small, whereas memory throughput can be the
most critical requirement in a complex, high performance
system.

4 Following are the factors that are to be considered while


selecting the memory devices,

(a) Speed
(b) Data storage size and capacity
(c) Bus width
(d) Power consumption
(e) Cost
60 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

2.12 Embedded system requirements

1 Program memory for holding control algorithm or embedded


OS and the applications designed to run on top of OS.

2 Data memory for holding variables and temporary data


during task execution.

3 Memory for holding non-volatile data which are modifiable


by the application.

• The memory requirement for an embedded system in terms


of RAM (SRAM/DRAM) and ROM
(EEPROM/FLASH/NVRAM) is solely dependent on the
type of the embedded system and applications for which it is
designed.
• There is no hard and fast rule for calculating the memory
requirements.
• Lot of factors need to be considered for selecting the type and
size of memory for embedded system.
• Example: Design of Embedded based electronic Toy.
• SOC or microcontroller can be selected based type(RAM &
ROM) and size of on-chip memory for the design of
embedded system.
• If on-chip memory is not sufficient then how much external
memory need to be interfaced.
• If the ES design is RTOS based ,the RTOS requires certain
amount of RAM for its execution and ROM for storing RTOS
Image.
• The RTOS suppliers gives amount of run time RAM
requirements and program memory requirements for the
RTOS.
2.12. EMBEDDED SYSTEM REQUIREMENTS 61

• Additional memory is required for executing user tasks and


user applications.

• On a safer side, always add a buffer value to the total


estimated RAM and ROM requirements.

• A smart phone device with windows OS is typical example


for embedded device requires say 512MB RAM and 1GB
ROM are minimum requirements for running the mobile
device.

• And additional RAM & ROM memory is required for running


user applications. So estimate the memory requirements for
install and run the user applications without facing memory
space.

• Memory can be selected based on size of the memory ,data


bus and address bus size of the processor/controller.

• Memory chips are available in standard sizes like 512


bytes,1KB,2KB ,4KB,8KB,16 KB upto 1MB etc.

• FLASH memory is the popular choice for ROM in embedded


applications .

• It is powerful and cost-effective solid state storage


technology for mobile electronic devices and other consumer
applications.

• Flash memory available in two major variants

1. NAND FLASH
2. NOR FLASH

• NAND FLASH is a high density low cost non-volatile storage


memory.

• NOR FLASH is less dense and slightly expensive but


supports Execute in place(XIP).
62 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

• The XIP technology allows the execution of code memory


from ROM itself without the need for copying it to the RAM.

• The EEPROM is available as either serial interface or parallel


interface chip.

• If the processor/controller of the device supports serial


interface and the amount of data to write and read to and
from the device (Serial EEPROM) is less.

• The serial EEPROM saves the address space of the total


system.

• The memory capacity of the serial EEPROM is expressed in


bits or Kilobits.

• Industrial grade memory chips are used in certain


embedded devices may be operated at extreme
environmental conditions like high temperature.

2.13 Sensors and Actuators

1 Embedded system is in constant interaction with the real


world.

2 Controlling/monitoring functions executed by the


embedded system is achieved in accordance with the
changes happening to the Real World.

3 The changes in the system environment or variables are


detected by the sensors connected to the input port of the
embedded system.

4 If the embedded system is designed for any controlling


purpose, the system will produce some changes in
controlling variable to bring the controlled variable to the
desired value.
2.13. SENSORS AND ACTUATORS 63

5 It is achieved through an actuator connected to the out port


of the embedded system.

Sensor

1 A transducer device which converts energy from one form


to another for any measurement or control purpose. Sensors
acts as input device.

2 Eg. Hall Effect Sensor which measures the distance between


the cushion and magnet in the Smart Running shoes from
adidas

3 Example: IR, humidity , PIR(passive infra red) , ultrasonic ,


piezoelectric , smoke sensors

Figure 2.15: Sensors

Actuator

1 A form of transducer device (mechanical or electrical) which


converts signals to corresponding physical action (motion).
Actuator acts as an output device.
64 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

2 Eg. Micro motor actuator which adjusts the position of the


cushioning element in the Smart Running shoes from adidas.

Figure 2.16: Actuators

2.14 The I/O Subsystem

1 The I/O subsystem of the embedded system facilitates the


interaction of the embedded system with external world.

2 The interaction happens through the sensors and actuators


connected to the Input and output ports respectively of the
embedded system.

3 The sensors may not be directly interfaced to the Input ports,


instead they may be interfaced through signal conditioning
and translating systems like ADC, Optocouplers etc

2.14.1 I/O Devices - Light Emitting Diode (LED)

1 Light Emitting Diode (LED) is an output device for visual


indication in any embedded system.
2.14. THE I/O SUBSYSTEM 65

2 LED can be used as an indicator for the status of various


signals or situations.

3 Typical examples are indicating the presence of power


conditions like ’Device ON’, ’Battery low’ or ’Charging of
battery’ for a battery operated handheld embedded devices

4 LED is a p-n junction diode and it contains an anode and a


cathode.
5 For proper functioning of the LED, the anode of it should be
connected to +ve terminal of the supply voltage and cathode
to the –ve terminal of supply voltage

6 The current flowing through the LED must limited to a value


below the maximum current that it can conduct.
7 A resister is used in series between the power supply and the
resistor to limit the current through the LED.

2.14.2 I/O Devices - 7-Segment LED Display

1 The 7 - segment LED display is an output device for


displaying alpha numeric characters

2 It contains 8 light-emitting diode (LED) segments arranged


in a special form. Out of the 8 LED segments, 7 are used for
displaying alpha numeric characters.

3 The LED segments are named A to G and the decimal point


LED segment is named as DP.

4 The LED Segments A to G and DP should be lit accordingly


to display numbers and characters.

5 The 7 – segment LED displays are available in two different


configurations, namely; Common anode and Common
cathode.
66 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

6 In the Common anode configuration, the anodes of the 8


segments are connected commonly whereas in the Common
cathode configuration, the 8 LED segments share a common
cathode line.

7 Based on the configuration of the 7 – segment LED unit, the


LED segment anode or cathode is connected to the Port of
the processor/controller in the order ’A’ segment to the Least
significant port Pin and DP segment to the most significant
Port Pin.

8 The current flow through each of the LED segments should be


limited to the maximum value supported by the LED display
unit.

9 The typical value for the current falls within the range of
20mA.

10 The current through each segment can be limited by


connecting a current limiting resistor to the anode or cathode
of each segment.

Figure 2.17:

2.14.3 I/O Devices – Optocoupler

1 Optocoupler is a solid state device to isolate two parts of a


circuit.
2.14. THE I/O SUBSYSTEM 67

2 Optocoupler combines an LED and a photo-transistor in a


single housing (package).

3 In electronic circuits, optocoupler is used for suppressing


interference in data communication, circuit isolation, High
voltage separation, simultaneous separation and
intensification signal etc.

4 Optocouplers can be used in either input circuits or in output


circuits.

Figure 2.18: Optocoupler in input and output circuit

2.14.4 I/O Devices – Stepper Motor

1 Stepper motor is an electro mechanical device which


generates discrete displacement (motion) in response to dc
electrical signals.

2 It differs from the normal dc motor in its operation. The dc


motor produces continuous rotation on applying dc voltage
whereas a stepper motor produces discrete rotation in
response to the dc voltage applied to it.

3 Stepper motors are widely used in industrial embedded


applications, consumer electronic products and robotics
control systems.
68 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

4 The paper feed mechanism of a printer/fax makes use of


stepper motors for its functioning.
5 Based on the coil winding arrangements, a two phase stepper
motor is classified into :
(a) Unipolar : A unipolar stepper motor contains two
windings per phase. The direction of rotation (clockwise
or anticlockwise) of a stepper motor is controlled by
changing the direction of current flow. current in one
direction flows through one coil and in the opposite
direction flows through the other coil. it is easy to shift
the direction of rotation by just switching the terminals
to which the coils are connected.
(b) Bipolar: A bipolar stepper motor contains single winding
per phase. For reversing the motor rotation the current
flow through the windings is reversed dynamically. It
requires complex circuitry for current flow reversal.

Figure 2.19: Stepper Motor Circuit

2.14.5 The I/O Subsystem – I/O Devices – Relay

1 An electro mechanical device which acts as dynamic path


selectors for signas and power.
2 The ’Relay’ unit contains a relay coil made up of insulated
wire on a metal core and a metal armature with one or more
contacts.
2.14. THE I/O SUBSYSTEM 69

3 ’Relay’ works on electromagnetic principle.

4 When a voltage is applied to the relay coil, current flows


through the coil, which in turn generates a magnetic field.

5 The magnetic field attacts the armature core and moves the
contact point.

6 The movement of the contact point changes the power/signal


flow path.

7 The Relay is normally controlled using a relay driver circuit


connected to the port pin of the processor/controller.

8 A transistor can be used as the relay driver. The transistor


can be selected depending on the relay driving current
requirements.

Figure 2.20:

2.14.6 I/O Devices -Piezo Buzzer

1 It is a piezoelectric device for generating audio indications in


embedded applications.

2 A Piezo buzzer contains a piezoelectric diaphragm which


produces audible sound in response to the voltage applied to
it.
70 CHAPTER 2. TYPICAL EMBEDDED SYSTEM

3 Piezoelectric buzzers are available in two types :


(a) Self-driving
(b) External driving

4 Self-driving contains are the necessary components to


generate sound at a predefined tone.

5 External driving piezo Buzzers supports the generation of


different tones.
6 The tone can be varied by applying a variable pulse train to
the piezoelectric buzzer.

7 A Piezo Buzzer can be directly interfaced to the port pin of


the processor/Controller.

2.14.7 I/O Devices – Push button switch

1 Push Button switch is an input device.

2 Push button comes in two configurations, namely ’Push to


Make’ and ’Push to Break’.
3 The switch is normally in the open state and it makes a circuit
contact when it is pushed or pressed in the ’Push to Make’
configuration.

4 In the ’Push to Break’ configuration, the switch is normally


in the closed state and it breaks the circuit contact when it is
pushed or pressed.

5 The push button stays in the ’closed’ (For Push to Make type)
or ’Open’ (For Push to Break type) state as long as it is kept
in the pused state and it breaks/makes the circuit connection
when it is released.
6 Push button is used for generating a momentary pulse.
2.14. THE I/O SUBSYSTEM 71

Figure 2.21: Push Button Switch


72 CHAPTER 2. TYPICAL EMBEDDED SYSTEM
Chapter 3

Communication Interface

3.1 Communication Interface

Figure 3.1:

1 Communication interface is essential for communicating


with various subsystems of the embedded system and with
the external world

2 The communication interface can be viewed in two different


perspectives; namely;

73
74 CHAPTER 3. COMMUNICATION INTERFACE

(a) Device/board level communication interface (Onboard


Communication Interface)
(b) Product level communication interface (External
Communication Interface)

3.1.1 Device/board level communication interface


(Onboard Communication Interface)

The communication channel which interconnects the various


components within an embedded product is referred as
Device/board level communication interface (Onboard
Communication Interface).

Examples: Serial interfaces like I2C, SPI, UART, 1-Wire etc and
Parallel bus interface

3.1.2 Product level communication interface (External


Communication Interface)

The ’Product level communication interface’ (External


Communication Interface) is responsible for data transfer
between the embedded system and other devices or modules.
The external communication interface can be either wired media
or wireless media and it can be a serial or parallel interface.

• Examples for wireless communication interface: Infrared


(IR), Bluetooth (BT), Wireless LAN (Wi-Fi), Radio Frequency
waves (RF), GPRS etc.

• Examples for wired interfaces: RS-232C/RS-422/RS 485,


USB, Ethernet (TCP-IP), IEEE 1394 port, Parallel port etc.
3.2. DEVICE/BOARD LEVEL OR ON BOARD COMMUNICATION INTERFACES75

3.2 Device/board level or On board communication


interfaces

Communication channel which interconnects the various


components within an embedded product is referred as
Device/board level communication interface (Onboard
Communication Interface) These are classified into -

1 I 2 C (Inter Integrated Circuit) Bus

2 SPI (Serial Peripheral Interface) Bus

3 UART (Universal Asynchronous Receiver Transmitter)

4 1-Wires Interface

5 Parallel Interface

3.2.1 I 2 C (Inter Integrated Circuit) Bus

Inter Integrated Circuit Bus (I 2 C - Pronounced ’I square C’) is a


synchronous bi-directional half duplex (one-directional
communication at a given point of time) two wire serial interface
bus.The concept of I2C bus was developed by ’Philips
Semiconductors’ in the early 1980’s. The original intention of I2C
was to provide an easy way of connection between a
microprocessor/microcontroller system and the peripheral chips
in Television sets.

The I 2 C bus is comprised of two bus lines, namely; Serial


Clock – SCL and Serial Data – SDA.
76 CHAPTER 3. COMMUNICATION INTERFACE

Figure 3.2:

Figure 3.3: I 2 C Bus Interfacing

SCL line is responsible for generating synchronization


clock pulses and SDA is responsible for transmitting the serial
data across devices.I 2 C bus is a shared bus system to which
many number of I 2 C devices can be connected. Devices
connected to the I2C bus can act as either ’Master’ device or
’Slave’ device.

The ’Master’ device is responsible for controlling the


communication by initiating/terminating data transfer, sending
data and generating necessary synchronization clock pulses.
3.2. DEVICE/BOARD LEVEL OR ON BOARD COMMUNICATION INTERFACES77

Slave devices wait for the commands from the master


and respond upon receiving the commands. Master and slave
devices can act as either transmitter or receiver. Regardless
whether a master is acting as transmitter or receiver, the
synchronization clock signal is generated by the ’Master’ device
only. I 2 C supports multi masters on the same bus.

The sequence of operation for communicating with an


2
I C slave device is:

1 Master device pulls the clock line (SCL) of the bus to ’HIGH’

2 Master device pulls the data line (SDA) ’LOW’, when the SCL
line is at logic ’HIGH’ (This is the ’Start’ condition for data
transfer).

Figure 3.4:

3 Master sends the address (7 bit or 10 bit wide) of the ’Slave’


device to which it wants to communicate, over the SDA line.
4 Clock pulses are generated at the SCL line for synchronizing
the bit reception by the slave device.

5 The MSB of the data is always transmitted first.

6 The data in the bus is valid during the ’HIGH’ period of the
clock signal.

7 In normal data transfer, the data line only changes state when
the clock is low.
78 CHAPTER 3. COMMUNICATION INTERFACE

Figure 3.5:

8 Master waits for the acknowledgement bit from the slave


device whose address is sent on the bus along with the
Read/Write operation command.

9 Slave devices connected to the bus compares the address


received with the address assigned to them.

10 The Slave device with the address requested by the master


device responds by sending an acknowledge bit (Bit value =1)
over the SDA line.
11 Upon receiving the acknowledge bit, master sends the 8bit
data to the slave device over SDA line, if the requested
operation is ’Write to device’.

12 If the requested operation is ’Read from device’, the slave


device sends data to the master over the SDA line.
13 Master waits for the acknowledgement bit from the device
upon byte transfer complete for a write operation and sends
an acknowledge bit to the slave device for a read operation.

14 Master terminates the transfer by pulling the SDA line


’HIGH’ when the clock line SCL is at logic ’HIGH’
(Indicating the ’STOP’ condition).
3.2. DEVICE/BOARD LEVEL OR ON BOARD COMMUNICATION INTERFACES79

Figure 3.6:

Figure 3.7:

3.2.2 Serial Peripheral Interface (SPI) Bus

The Serial Peripheral Interface Bus (SPI) is a synchronous


bi-directional full duplex four wire serial interface bus. The
concept of SPI is introduced by Motorola. SPI is a single master
multi-slave system.
80 CHAPTER 3. COMMUNICATION INTERFACE

• It is possible to have a system where more than one SPI device


can be master, provided the condition only one master device
is active at any given point of time, is satisfied.
• SPI is used to send data between Microcontrollers and small
peripherals such as shift registers, sensors, and SD cards.

Figure 3.8:

SPI requires four signal lines for communication. They


are:

1 Master Out Slave In (MOSI): Signal line carrying the data


from master to slave device. It is also known as Slave
Input/Slave Data In (SI/SDI)

2 Master In Slave Out (MISO): Signal line carrying the data


from slave to master device. It is also known as Slave Output
(SO/SDO)
3 Serial Clock (SCLK): Signal line carrying the clock signals

4 Slave Select (SS): Signal line for slave device select. It is an


active low signal. The master device is responsible for
generating the clock signal. Master device selects the
required slave device by asserting the corresponding slave
devices slave select signal ’LOW’.
3.2. DEVICE/BOARD LEVEL OR ON BOARD COMMUNICATION INTERFACES81

(a) The data out line (MISO) of all the slave devices when not
selected floats at high impedance state
(b) The serial data transmission through SPI Bus is fully
configurable.
(c) SPI devices contain certain set of registers for holding
these configurations.
(d) The Serial Peripheral Control Register holds the various
configuration parameters like master/slave selection for
the device, baud rate selection for communication, clock
signal control etc.
(e) The status register holds the status of various conditions
for transmission and reception.SPI works on the principle
of ’Shift Register’.
(f) The master and slave devices contain a special shift
register for the data to transmit or receive.
(g) The size of the shift register is device dependent.
Normally it is a multiple of 8.

Figure 3.9: Master/Slave Serial peripheral Communication

(h) During transmission from the master to slave, the data in


the master’s shift register is shifted out to the MOSI pin
and it enters the shift register of the slave device through
the MOSI pin of the slave device.
(i) At the same time the shifted out data bit from the slave
device’s shift register enters the shift register of the
82 CHAPTER 3. COMMUNICATION INTERFACE

master device through MISO pin.

Figure 3.10:

I 2 C V/S SPI

S.N. I 2 C SPI
1 Speed limit varies from 100 More than 1 Mbps, 10
kbps, 400 kbps, 1Mbps, Mbps till 100 Mbps can be
3.4 Mbps depending on I 2 achieved.
version.
2 Half Duplex Synchronous Full duplex synchronous
protocol. protocol.
3 Support Multimaster Multi master configuration is
configuration. not possible.
4 Acknowledgment at each No acknowledgment
transfer
5 Requires two pins only SDA, Require separate MISO,
SCL MOSI, CLK and CS signal
for each slave.
6 Addition of new device on Addition of new device on
the bus is easy. the bus is not much easy as
I2C
7 More overlead (due to Less overhead
acknowledgment, start and
stop)
3.2. DEVICE/BOARD LEVEL OR ON BOARD COMMUNICATION INTERFACES83

8 Noise sensitivity is high Less noise sensitivity

3.2.3 1-wire interface (protocol)

1- Wire is a device communications bus system designed by


Dallas Semiconductor Corp. that provides low-speed data,
signaling, and power over a single conductor.

1-Wire is similar in concept to I 2 C, but with lower data


rates and longer range. It is typically used to communicate with
small inexpensive devices such as digital thermometers and
weather instruments.

One distinctive feature of the bus is the possibility of


using only two wires: data and ground. To accomplish this,
1-Wire devices include an 800 pF capacitor to store charge, and to
power the device during periods when the data line is active.

There is always one master in overall charge, which may


be a PC or a microcontroller. The master initiates activity on the
bus, simplifying the avoidance of collisions on the bus. Protocols
are built into the software to detect collisions. After a collision, the
master retries the required communication.

Figure 3.11:

Many devices can share the same bus. Each device on


84 CHAPTER 3. COMMUNICATION INTERFACE

the bus has a unique 64-bit serial number. The least significant
byte of the serial number is an 8-bit number that tells the type of
the device. The most significant byte is a standard (for the 1-wire
bus) 8-bit CRC.

The master starts a transmission with a reset pulse,


which pulls the wire to 0 volts for at least 480 µs. This resets
every slave device on the bus. After that, any slave device, if
present, shows that it exists with a ”presence” pulse: it holds the
bus low for at least 60 µs after the master releases the bus.

To send a ”1”, the bus master sends a very brief (1– 15


µs) low pulse. To send a ”0”, the master sends a 60 µs low
pulse.When receiving data, the master start sends a 1–15-µs
0-volt pulse to slave each bit. If the transmitting does unit wants
to send a ”1”, it to the nothing, and the bus goes transmitting
pulled-up voltage. If the ”0”, it pulls slave wants to send the data
line to ground for 60 µs.

3.2.4 Parallel Communication

In data transmission, parallel communication is a method of


conveying multiple binary digits (bits) simultaneously. It
contrasts with communication. The communication channel is
the number of electrical conductors used at the physical layer to
convey bits.

Parallel communication implies more than one such


conductor. For example, an 8-bit parallel channel will convey
eight bits (or a byte) simultaneously, whereas a serial channel
would convey those same bits sequentially, one at a time. Parallel
communication is and always has been widely used within
integrated circuits, in peripheral buses, and in memory devices
such as RAM.
3.3. PRODUCT LEVEL COMMUNICATION INTERFACE (EXTERNAL COMMUNICATION

Figure 3.12:

3.3 Product level communication interface


(External Communication Interface)

The Product level communication interface (External


Communication Interface) is responsible for data transfer
between the embedded system and other devices or modules.

It is classified into two types -

1 Wired communication interface

2 Wireless communication interface

3.3.1 Wired communication interface

Wired communication interface is an interface used to transfer


information over a wired network.

It is classified into following types.

1 RS-232C/RS-422/RS 485

2 USB
86 CHAPTER 3. COMMUNICATION INTERFACE

RS-232C

1 RS-232 C (Recommended Standard number 232, revision C


from the Electronic Industry Association) is a legacy, full
duplex, wired, asynchronous serial communication interface

2 RS-232 extends the UART communication signals for external


data communication.
3 UART uses the standard TTL/CMOS logic (Logic ’High’
corresponds to bit value 1 and Logic ’LOW’ corresponds to
bit value 0) for bit transmission whereas RS232 use the EIA
standard for bit transmission.
4 As per EIA standard, a logic ’0’ is represented with voltage
between +3 and +25V and a logic ’1’ is represented with
voltage between -3 and -25V.

5 In EIA standard, logic ’0’ is known as ’Space’ and logic ’1’ as


’Mark’.

The RS232 interface define various handshaking and


control signals for communication apart from the ’Transmit’ and
’Receive’ signal lines for data communication

RS-232 supports two different types of connectors,


namely; DB-9: 9-Pin connector and DB-25: 25-Pin connector.

Figure 3.13: DB-25:25-Pin connector


3.3. PRODUCT LEVEL COMMUNICATION INTERFACE (EXTERNAL COMMUNICATION

Figure 3.14: DB-9:9-Pin connector

Figure 3.15:

• RS-232 is a point-to-point communication interface and the


devices involved in RS-232 communication are called ’Data
Terminal Equipment (DTE’ and ’Data Communication
Equipment (DCE)’.
• If no data flow control is required, only TXD and RXD signal
lines and ground line (GND) are required for data
transmission and reception.
• The RXD pin of DCE should be connected to the TXD pin of
DTE and vice versa for proper data transmission.
• If hardware data flow control is required for serial
transmission, various control signal lines of the RS-232
connection are used appropriately.
88 CHAPTER 3. COMMUNICATION INTERFACE

• The control signals are implemented mainly for modem


communication and some of them may be irrelevant for
other type of devices.
• The Request to Send (RTS) and Clear To Send (CTS) signals
co-ordinate the communication between DTE and DCE.
• Whenever the DTE has a data to send, it activates the RTS line
and if the DCE is ready to accept the data, it activates the CTS
line.
• The Data Terminal Ready (DTR) signal is activated by DTE
when it is ready to accept data.
• The Data Set Ready (DSR) is activated by DCE when it is
ready for establishing a communication link.
• DTR should be in the activated state before the activation of
DSR.
• The Data Carrier Detect (DCD) is used by the DCE to indicate
the DTE that a good signal is being received.
• Ring Indicator (RI) is a modem specific signal line for
indicating an incoming call on the telephone line.
• As per the EIA standard RS-232 C supports baudrates up to
20Kbps (Upper limit 19.2Kbps).
• The commonly used baudrates by devices are 300 bps, 1200
bps, 2400 bps, 9600 bps, 11.52 Kbps and 19.2 Kbps.
• The maximum operating distance supported in RS-232
communication is 50 feet at the highest supported baudrate.
• Embedded devices contain a UART for serial
communication and they generate signal levels conforming
to TTL/CMOS logic.
• A level translator IC like MAX 232 from Maxim Dallas
semiconductor is used for converting the signal lines from
the UART to RS-232 signal lines for communication.
3.3. PRODUCT LEVEL COMMUNICATION INTERFACE (EXTERNAL COMMUNICATION

• On the receiving side the received data is converted back to


digital logic level by a converter IC.

• Converter chips contain converters for both transmitter and


receiver.

• RS-232 uses single ended data transfer and supports only


point-to-point communication and not suitable for
multi-drop communication.

3.3.2 USB (UNIVERSAL SERIAL BUS):

1 External Bus Standard.

2 Allows connection of peripheral devices.

3 Connects Devices such as keyboards, mice, scanners,


printers, joysticks, audio devices, disks.

4 Facilitates transfers of data at 480 (USB 2.0 only), 12 or 1.5


Mb/s (mega- bits/second).

5 Developed by a Special Interest Group including Intel,


Microsoft, Compact, DEC, IBM, Northern Telecom and NEC
originally in 1994.

6 Low-Speed: 10 – 100 kb/s

7 1.5 Mb/s signaling bit rate

8 Full-Speed: 500 kb/s – 10 Mb/s 12 Mb/s signaling bit rate

9 High-Speed: 400 Mb/s

10 480 Mb/s signaling bit rate

11 NRZI with bit stuffing used


90 CHAPTER 3. COMMUNICATION INTERFACE

12 SYNC field present for every packet

13 There exist two pre-defined connectors in any USB system -


Series “A” and Series “B” Connectors.

14 Series “A” cable: Connects USB devices to a hub port.

15 Series “B” cable: Connects detachable devices (hot-


swappable)

3.4 Bus Topology

1 Connects computer to peripheral devices.

2 Ultimately intended to replace parallel and serial ports

3 Tiered Star Topology

4 All devices are linked to a common point referred to as the


root hub.

5 Specification allows for up to 127 (27 − 1) different devices.

Figure 3.16: Bus topology


3.5. WIRELESS COMMUNICATION INTERFACE 91

6 Four wire cable serves as interconnect of system - power,


ground and two differential signaling lines.

7 USB is a polled bus-all transactions are initiated by host.


USB HOST: Device that controls entire system usually a PC
of some form. Processes data arriving to and from the USB
port.
USB HUB: Tests for new devices and maintains status
information of child devices.Serve as repeaters, boosting
strength of up and downstream signals. Electrically isolates
devices from one another - allowing an expanded number of
devices.

3.5 Wireless communication interface

Wireless communication interface is an interface used to


transmission of information over a distance without help of
wires, cables or any other forms of electrical conductors.

They are basically classified into following types -

1 Infrared

2 Bluetooth

3 Wi-Fi

4 Zigbee

5 GPRS

3.5.1 Infrared

1 Infrared is a certain region in the light spectrum


92 CHAPTER 3. COMMUNICATION INTERFACE

2 Ranges from 0.7µ to 1000µ or 0.1mm4

3 Broken into near, mid, and far infrared

4 One step up on the light spectrum from visible light

5 Measure of heat

Figure 3.17: Infrared Spectrum

Most of the thermal radiation emitted by objects near


room temperature is infrared. Infrared radiation is used in
industrial, scientific, and medical applications. Night-vision
devices using active near-infrared illumination allow people or
animals to be observed without the observer being detected.

Figure 3.18:

IR Transmission : The transmitter of an IR LED inside its circuit,


which emits infrared light for every electric pulse given to it. This
3.5. WIRELESS COMMUNICATION INTERFACE 93

pulse is generated as a button on the remote is pressed, thus


completing the circuit, providing bias to the LED.

The LED on being biased emits light of the wavelength


of 940nm as a series of pulses, corresponding to the button
pressed. However since along with the IR LED many other
sources of infrared light such as us human beings, light bulbs,
sun, etc, the transmitted information can be interfered. A solution
to this problem is by modulation. The transmitted signal is
modulated using a carrier frequency of 38 KHz (or any other
frequency between 36 to 46 KHz). The IR LED is made to oscillate
at this frequency for the time duration of the pulse. The
information or the light signals are pulse width modulated and
are contained in the 38 KHz frequency.

• IR supports data rates ranging from 9600bits/second to


16Mbps
• Serial infrared: 9600bps to 115.2 kbps
• Medium infrared: 0.576Mbps to 1.152 Mbps
• Fast infrared: 4Mbps

3.5.2 Bluetooth

Bluetooth is a wireless technology standard for short distances


(using short-wavelength UHF band from 2.4 to 2.485 GHz)for
exchanging data over radio waves in the ISM and mobile devices,
and building personal area networks (PANs).Invented by telecom
vendor Ericsson in 1994, it was originally conceived as a wireless
alternative to RS- 232 data cables.

Bluetooth uses a radio technology called frequency-


hopping spread spectrum. Bluetooth divides transmitted data
into packets, and transmits each packet on one of 79 designated
Bluetooth channels. Each channel has a bandwidth of 1 MHz. It
94 CHAPTER 3. COMMUNICATION INTERFACE

usually performs 800 hops per second, with Adaptive


Frequency-Hopping (AFH) enabled.

Originally, Gaussian frequency-shift keying (GFSK)


modulation was the only modulation scheme available. Since the
introduction of Bluetooth 2.0 + EDR, π/4-DQPSK (Differential
Quadrature Phase Shift Keying) and 8DPSK modulation may also
be used between compatible devices. Bluetooth is a packet-based
protocol with a master- slave structure. One master may
communicate with up to seven slaves in a piconet. All devices
share the master’s clock. Packet exchange is based on the basic
clock, defined by the master, which ticks at 312.5 µs intervals.

A master BR/EDR Bluetooth device can communicate


with a maximum of seven devices in a piconet (an ad-hoc
computer network using Bluetooth technology), though not all
devices reach this maximum. The devices can switch roles, by
agreement, and the slave can become the master (for example, a
headset initiating a connection to a phone necessarily begins as
master—as initiator of the connection—but may subsequently
operate as slave).

3.5.3 Wi-Fi

1 Wi-Fi is the name of a popular wireless networking


technology that uses radio waves to provide wireless
high-speed Internet and network connections

2 Wi-Fi follows the IEEE 802.11 standard

3 Wi-Fi is intended for network communication and it supports


Internet Protocol (IP) based communication

4 Wi-Fi based communications require an intermediate agent


called Wi-Fi router/Wireless Access point to manage the
communications.
3.5. WIRELESS COMMUNICATION INTERFACE 95

5 The Wi-Fi router is responsible for restricting the access to


a network, assigning IP address to devices on the network,
routing data packets to the intended devices on the network.

Figure 3.19:

6 Wi-Fi enabled devices contain a wireless adaptor for


transmitting and receiving data in the form of radio signals
through an antenna.

7 Wi-Fi operates at 2.4GHZ or 5GHZ of radio spectrum and


they co-exist with other ISM band devices like Bluetooth.

8 A Wi-Fi network is identified with a Service Set Identifier


(SSID). A Wi-Fi device can connect to a network by selecting
the SSID of the network and by providing the credentials if
the network is security enabled

9 Wi-Fi networks implements different security mechanisms


for authentication and data transfer.

10 Wireless Equivalency Protocol (WEP), Wireless Protected


Access (WPA) etc are some of the security mechanisms
supported by Wi-Fi networks in data communication.
96 CHAPTER 3. COMMUNICATION INTERFACE

3.5.4 ZIGBEE

Zigbee is an IEEE 802.15.4-based specification for a suite of high-


level communication protocols used to create personal area
networks with small, low-power digital radios, such as for home
automation, medical device data collection, and other low-power
low-bandwidth needs, designed for small scale projects which
need wireless connection.Hence, zigbee is a low-power, low data
rate, and close proximity (i.e., personal area) wireless ad hoc
network.The technology defined by the zigbee specification is
intended to be simpler and less expensive than other wireless
personal area networks (WPANs), such as Bluetooth or Wi-Fi .
Applications include wireless light switches, electrical meters
with in-home-displays, traffic management systems, and other
consumer and industrial equipment that require short-range low-
rate wireless data transfer. Its low power consumption limits
transmission distances to 10– 100 meters line-of-sight, depending
on power output and environmental characteristics. Zigbee
devices can transmit data over long distances by passing data
through a mesh network of intermediate devices to reach more
distant ones.

Figure 3.20:

• Zigbee Coordinator: The zigbee coordinator acts as the root


of the zigbee network. The ZC is responsible for initiating the
3.5. WIRELESS COMMUNICATION INTERFACE 97

Zigbee network and it has the capability to store information


about the network.
• Zigbee Router: Responsible for passing information from
device to another device or to another ZR.
• Zigbee end device:End device containing zigbee
functionality for data communication. It can talk only with a
ZR or ZC and doesn’t have the capability to act as a
mediator for transferring data from one device to another.

Zigbee supports an operating distance of up to 100


metres at a data rate of 20 to 250 Kbps.

3.5.5 GPRS

General Packet Radio Service (GPRS) is a packet oriented mobile


data service on the 2G and 3G cellular communication system’s
global system for mobile communications (GSM).GPRS was
originally standardized by European Telecommunications
Standards Institute (ETSI) GPRS usage is typically charged based
on volume of data transferred, contrasting with circuit switched
data, which is usually billed per minute of connection time.
Sometimes billing time is broken down to every third of a
minute. Usage above the bundle cap is charged per megabyte,
speed limited, or disallowed.

Services Offered :

1 GPRS extends the GSM Packet circuit switched data


capabilities and makes the following services possible:

2 SMS messaging and broadcasting

3 ”Always on” internet access

4 Multimedia messaging service (MMS)


98 CHAPTER 3. COMMUNICATION INTERFACE

5 Push-to-talk over cellular (PoC)

6 Instant messaging and presence-wireless village Internet


applications for smart devices through wireless application
protocol (WAP).

7 Point-to-point (P2P) service: inter-networking with the


Internet (IP).

8 Point-to-multipoint (P2M) service : point-to- multipoint


multicast and point-to-multipoint group calls.
Chapter 4

Embedded Firmware Design and


Development

4.1 Introduction

1 The control algorithm (Program instructions) and or the


configuration settings that an embedded system developer
dumps into the code (Program) memory of the embedded
system

2 It is an un-avoidable part of an embedded system.

3 The embedded firmware can be developed in various


methods like

(a) Write the program in high level languages like


Embedded C/C++ using an Integrated Development
Environment (The IDE will contain an editor, compiler,
linker, debugger, simulator etc. IDEs are different for
different family of processors/controllers.
(b) Write the program in Assembly Language using the
Instructions Supported by your application’s target
processor/controller

99
100 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

4.2 Embedded Firmware Design and Development

1 The embedded firmware is responsible for controlling the


various peripherals of the embedded hardware and
generating response in accordance with the functional
requirements of the product.

2 The embedded firmware is the master brain of the embedded


system. The embedded firmware imparts intelligence to an
Embedded system. It is a onetime process and it can happen
at any stage.

3 The product starts functioning properly once the intelligence


imparted to the product by embedding the firmware in the
hardware.
4 The product will continue serving the assigned task till
hardware breakdown occurs or a corruption in embedded
firmware.
5 In case of hardware breakdown, the damaged component
may need to be replaced and for firmware corruptions the
firmware should be re-loaded, to bring back the embedded
product to the normal functioning.

6 The embedded firmware is usually stored in a permanent


memory (ROM) and it is non alterable by end users.

7 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 low level Assembly Language or High level language
like C/C++ or a combination of the two).
8 The embedded firmware development process starts with
the conversion of the firmware requirements into a program
4.2. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT 101

model using various modeling tools.

9 The firmware design approaches for embedded product is


purely dependent on the complexity of the functions to be
performed and speed of operation required.

10 There exist two basic approaches for the design and


implementation of embedded firmware, namely;
(a) The Super loop based approach
(b) The Embedded Operating System based approach

11 The decision on which approach needs to be adopted for


firmware development is purely dependent on the
complexity and system requirements

4.2.1 Embedded firmware Design Approaches – The Super


loop

1 The Super loop based firmware development approach is


Suitable for applications that are not time critical and where
the response time is not so important (Embedded systems
where missing deadlines are acceptable).

2 It is very similar to a conventional procedural programming


where the code is executed task by task.

3 The tasks are executed in a never ending loop.

4 The task listed on top on the program code is executed first


and the tasks just below the top are executed after completing
the first task.
5 A typical super loop implementation will look like:
(a) Configure the common parameters and perform
initialization for various hardware components memory,
registers etc.
102 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

(b) Start the first task and execute it


(c) Execute the second task
(d) Execute the next task
(e) Execute the next task
(f) Execute the next task
(g) Execute the last defined task
(h) Jump back to the first task and follow the same flow.

Pros:

• Doesn’t require an Operating System for task scheduling and


monitoring and free from OS related overheads

• Simple and straight forward design

• Reduced memory footprint

Cons :

• Non Real time in execution behavior (As the number of tasks


increases the frequency at which a task gets CPU time for
execution also increases).

• Any issues in any task execution may affect the functioning


of the product (This can be effectively tackled by using Watch
Dog Timers for task execution monitoring).

Enhancements :

• Combine Super loop based technique with interrupts.

• Execute the tasks (like keyboard handling) which require Real


time attention as Interrupt Service routines.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS103

4.2.2 Embedded firmware Design Approaches – Embedded


OS based Approach

1 The embedded device contains an Embedded Operating


System which can be one of:
(a) A Real Time Operating System (RTOS)
(b) A Customized General Purpose Operating System
(GPOS)
2 The Embedded OS is responsible for scheduling the execution
of user tasks and the allocation of system resources among
multiple tasks.

3 It Involves lot of OS related overheads apart from managing


and executing user defined tasks Microsoft® Windows XP
Embedded is an example of GPOS for embedded devices.

4 Point of Sale (PoS) terminals, Gaming Stations, Tablet PCs


etc are examples of embedded devices running on
embedded GPOSs.
5 ‘Windows CE’, ‘Windows Mobile’,‘QNX’, ‘VxWorks’, ‘ThreadX’,
‘MicroC/OS-II’, ‘Embedded Linux’, ‘Symbian’ etc are examples
of RTOSs employed in Embedded Product development

6 Mobile Phones, PDAs, Flight Control Systems etc are


examples of embedded devices that runs on RTOSs

4.3 Embedded firmware Development


Languages/Options

1 Assembly Language

2 High Level Language


(a) Subset of C (Embedded C)
104 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

(b) Subset of C++ (Embedded C++)


(c) Any other high level language with supported
Cross-compiler
3 Mix of Assembly & High level Language
(a) Mixing High Level Language (Like C) with Assembly
Code
(b) Mixing Assembly code with High Level Language (Like
C)
(c) Inline Assembly

4.3.1 Embedded firmware Development


Languages/Options – Assembly Language

1 ‘Assembly Language’ is the human readable notation of


‘machine language’
2 ‘Machine language’ is a processor understandable language

3 Machine language is a binary representation and it consists


of 1s and 0s Assembly language and machine languages are
processor/controller dependent
4 An Assembly language program written for one
processor/controller family will not work with others.
5 Assembly language programming is the process of writing
processor specific machine code in mnemonic form,
converting the mnemonics into actual processor instructions
(machine language) and associated data using an assembler.
6 The general format of an assembly language instruction is an
Opcode followed by Operands.
7 The Opcode tells the processor/controller what to do and
the Operands provide the data and information required to
perform the action specified by the opcode.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS105

8 It is not necessary that all opcode should have Operands


following them. Some of the Opcode implicitly contains the
operand and in such situation no operand is required. The
operand may be a single operand, dual operand or more.
The 8051 Assembly Instruction

M OV A, #30

Moves decimal value 30 to the 8051 Accumulator register.


Here MOV A is the Opcode and 30 is the operand (single
operand). The same instruction when written in machine
language will look like

0111010000011110

The first 8 bit binary value 01110100 represents the opcode


MOV A and the second 8 bit binary value 00011110 represents
the operand 30.

9 Assembly language instructions are written one per line.

10 A machine code program consists of a sequence of assembly


language instructions, where each statement contains a
mnemonic (Opcode + Operand).

11 Each line of an assembly language program is split into four


fields as:

LABEL OPCODE OPERAND COMMENTS

LABEL is an optional field. A ‘LABEL’ is an identifier used


extensively in programs to reduce the reliance on
programmers for remembering where data or code is
located. LABEL is commonly used for representing -

1 A memory location, address of a program, sub-routine,


code portion etc.
106 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

2 The maximum length of a label differs between


assemblers. Assemblers insist strict formats for labeling.
Labels are always suffixed by a colon and begin with a
valid character. Labels can contain number from 0 to 9
and special character (underscore).

4.3.2 Assembly Language – Source File to Hex File


Translation

Figure 4.1: Assembly Language to machine language conversion process

1 The Assembly language program written in assembly code is


saved as .asm (Assembly file) file or a .src (source) file or a
format supported by the assembler

2 Similar to ‘C’ and other high level language programming, it


is possible to have multiple source files called modules in
assembly language programming. Each module is
represented by a ‘.asm’ or ‘.src’ file or the assembler
supported file format similar to the ‘.c’ files in C
programming.

3 The software utility called ‘Assembler’ performs the


translation of assembly code to machine code.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS107

4 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.

5 Each source file can be assembled separately to examine the


syntax errors and incorrect assembly instructions.

6 Assembling of each source file generates a corresponding


object file. The object file does not contain the absolute
address of where the generated code needs to be placed (a
re-locatable code) on the program memory.

7 The software program called linker/locater is responsible for


assigning absolute address to object files during the linking
process.

8 The Absolute object file created from the object files


corresponding to different source code modules contain
information about the address where each instruction needs
to be placed in code memory.

9 A software utility called ‘Object to Hex file converter’


translates the absolute object file to corresponding hex file
(binary file).

Advantages

1 Efficient Code Memory & Data Memory Usage (Memory


Optimization)
(a) The developer is well aware of the target processor
architecture and memory organization, so optimized
code can be written for performing operations.
(b) This leads to less utilization of code memory and efficient
utilization of data memory.

2 High Performance
108 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

(a) Optimized code not only improves the code memory


usage but also improves the total system performance.
(b) Through effective assembly coding, optimum
performance can be achieved for target processor.

3 Low level Hardware Access Most of the code for low level
programming like accessing external device specific registers
from OS kernel ,device drivers, and low level interrupt
routines, etc are making use of direct assembly coding.

4 Code Reverse Engineering


(a) It is the process of understanding the technology behind
a product by extracting the information from the finished
product.
(b) It can easily be converted into assembly code using a dis-
assembler program for the target machine.

Drawbacks

1 High Development time


(a) The developer takes lot of time to study about
architecture ,memory organization, addressing modes
and instruction set of target processor/controller.
(b) More lines of assembly code is required for performing a
simple action.

2 Developer dependency
There is no common written rule for developing assembly
language based applications.

3 Non portable
(a) Target applications written in assembly instructions are
valid only for that particular family of processors and
cannot be re-used for another target
processors/controllers.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS109

(b) If the target processor/controller changes, a complete re-


writing of the application using assembly language for
new target processor/controller is required.

4.3.3 Embedded firmware Development


Languages/Options – High Level Language

1 The embedded firmware is written in any high level language


like C, C++.

2 A software utility called ‘cross-compiler’ converts the high


level language to target processor specific machine code.

3 The cross-compilation of each module generates a


corresponding object file. The object file does not contain the
absolute address of where the generated code needs to be
placed (a re-locatable code) on the program memory.

4 The software program called linker/locater is responsible for


assigning absolute address to object files during the linking
process.

5 The Absolute object file created from the object files


corresponding to different source code modules contain
information about the address where each instruction needs
to be placed in code memory.

6 A software utility called ‘Object to Hex file converter’


translates the absolute object file to corresponding hex file
(binary file).
110 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

4.3.4 Embedded firmware Development


Languages/Options – High Level Language – Source
File to Hex File Translation

Figure 4.2: High level language to machine language conversion process

Advantages

1 Reduced Development time: Developer requires less or little


knowledge on internal hardware details and architecture of
the target processor/Controller.

2 Developer independency: The syntax used by most of the


high level languages are universal and a program written
high level can easily understand by a second person
knowing the syntax of the language.

3 Portability: An Application written in high level language


for particular target processor /controller can be easily be
converted to another target processor/controller specific
application with little or less effort.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS111

4.3.5 Drawbacks

1 The cross compilers may not be efficient in generating the


optimized target processor specific instructions.

2 Target images created by such compilers may be messy and


non- optimized in terms of performance as well as code size.

3 The investment required for high level language based


development tools (IDE) is high compared to Assembly
Language based firmware development tools.

4.3.6 Embedded firmware Development


Languages/Options – Mixing of Assembly Language
with High Level Language

1 Embedded firmware development may require the mixing of


Assembly Language with high level language or vice versa.

2 Interrupt handling, Source code is already available in high


level language/Assembly Language etc are examples.

3 High Level language and low level language can be mixed in


three different ways

(a) Mixing Assembly Language with High level language


like ‘C’
(b) Mixing High level language like ‘C’ with Assembly
Language
(c) In line Assembly

4 The passing of parameters and return values between the


high level and low level language is cross-compiler specific.
112 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

Mixing Assembly Language with High level language like ‘C’


(Assembly Language with ‘C’)

1 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 built in support for implementing certain
features like ISR.

2 If the programmer wants to take advantage of the speed and


optimized code offered by the machine code generated by
hand written assembly rather than cross compiler generated
machine code.

3 For accessing certain low level hardware ,the timing


specifications may be very critical and cross compiler
generated machine code may not be able to offer the
required time specifications accurately.

4 Writing the hardware/peripheral access routine in


processor/controller specific assembly language and
invoking it from ‘C’ is the most advised method.

5 Mixing ‘C’ and assembly is little complicated.

6 The programmer must be aware of how to pass parameters


from the ‘C’ routine to assembly and values returned from
assembly routine to ‘C’ and how Assembly routine is invoked
from the ‘C’ code.

7 Passing parameter to the assembly routine and returning


values from the assembly routine to the caller ‘C’ function
and the method of invoking the assembly routine from ‘C’
code is cross compiler dependent.

8 There is no universal written rule for purpose.

9 We can get this information from documentation of the cross


compiler.
4.3. EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES/OPTIONS113

10 Different cross compilers implement these features in


different ways depending on GPRs and memory supported
by target processor/controller.

Mixing High level language like ‘C’ with Assembly Language


(‘C’ with Assembly Language)

1 The source code is already available in assembly language


and routine written in a high level language needs to be
included to the existing code.
2 The entire source code is planned in Assembly code for
various reasons like optimized code, optimal performance,
efficient code memory utilization and proven expertise in
handling the assembly.
3 The functions written in ‘C’ use parameter passing to the
function and returns values to the calling functions.
4 The programmer must be aware of how parameters are
passed to the function and how values returned from the
function and how function is invoked from the assembly
language environment.
5 Passing parameter to the function and returning values from
the function using CPU registers , stack memory and fixed
memory.
6 Its implementation is cross compiler dependent and varies
across compilers.

4.3.7 In line Assembly

1 Inline assembly is another technique for inserting the target


processor/controller specific assembly instructions at any
location of source code written in high level language ‘C’
114 CHAPTER 4. EMBEDDED FIRMWARE DESIGN AND DEVELOPMENT

2 Inline Assembly avoids the delay in calling an assembly


routine from a ‘C’ code.
3 Special keywords are used to indicate the start and end of
Assembly instructions

4 Example :

#pragma asm
Mov A,#13H
#pragma ensasm

5 Keil C51 uses the keywords #pragma asm and #pragma


endasm to indicate a block of code written in assembly.
Chapter 5

RTOS Based Embedded System


Design

5.1 Operating System Basics

1 The Operating System acts as a bridge between the user


applications/tasks and the underlying system resources
through a set of system functionalities and services.

2 OS manages resources and available to the system makes


them the user applications/tasks on a need basis.

Figure 5.1:

3 The primary functions of an Operating system is -

115
116 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

(a) Make the system convenient to use.


(b) Organize and manage the system resources efficiently
and correctly.

Figure 5.2: The Architecture of Operating System

5.2 The Kernel

1 The kernel is the core of the operating system.

2 It is responsible for managing the system resources and the


communication among the hardware and other system
services.
3 Kernel acts as the abstraction layer between system resources
and user applications.

4 Kernel contains a set of system libraries and services.

5 For a general purpose OS, the kernel contains different


services like
(a) Process Management
(b) Primary Memory Management
(c) File System management
5.2. THE KERNEL 117

(d) I/O System (Device) Management


(e) Secondary Storage Management
(f) Protection
(g) Time management
(h) Interrupt Handling

5.2.1 Kernel Space and User Space

1 The program code corresponding to the kernel


applications/services are kept in a contiguous area (OS
dependent) of primary (working) memory and is protected
from the un-authorized access by user
programs/applications

2 The memory space at which the kernel code is located is


known as ‘Kernel Space’.

3 All user applications are loaded to a specific area of primary


memory and this memory area is referred as ‘User Space’.

4 The partitioning of memory into kernel and user space is


purely Operating System dependent.

5 An operating system with virtual memory support, loads the


user applications into its corresponding virtual memory
space with demand paging technique

6 Most of the operating systems keep the kernel application


code in main memory and it is not swapped out into the
secondary memory

5.2.2 Monolithic Kernel

1 All kernel services run in the kernel space.


118 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

2 All kernel modules run within the same memory space under
a single kernel thread.

3 The tight internal integration of kernel modules in monolithic


kernel architecture allows the effective utilization of the low-
level features of the underlying system.

4 The major drawback of monolithic kernel is that any error or


failure in any one of the kernel modules leads to the crashing
of the entire kernel application.

5 LINUX, SOLARIS, MS-DOS kernels are examples of


monolithic kernel.

Figure 5.3: The Monolithic Kernel Model

5.2.3 Microkernel

1 The microkernel design incorporates only the essential set of


Operating System services into the kernel.

2 Rest of the Operating System services are implemented in


programs known as ‘Servers’ which runs in user space.

3 The kernel design is highly modular provides OS-neutral


abstraction.
5.3. TYPES OF OPERATING SYSTEMS 119

4 Memory management, process management, timer systems


and interrupt handlers are examples of essential services,
which forms the part of the microkernel.

5 QNX, Minix 3 kernels are examples for microkernel.

Figure 5.4: The Microkernel Model

Benefits of Microkernel

1 Robustness: If a problem is encountered in any services in


server can reconfigured and re-started without the need for
re-starting the entire OS.

2 Configurability: Any services , which run as ‘server’


application can be changed without need to restart the
whole system.

5.3 Types of Operating Systems

Depending on the type of kernel and kernel services, purpose


and type of computing systems where the OS is deployed and the
responsiveness to applications, Operating Systems are classified
into
120 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

1 General Purpose Operating System (GPOS)

2 Real Time Purpose Operating System (RTOS)

5.3.1 General Purpose Operating System (GPOS)

1 Operating Systems, which are deployed in general


computing systems.

2 The kernel is more generalized and contains all the required


services to execute generic applications.

3 Need not be deterministic in execution behavior.

4 May inject random delays into application software and thus


cause slow responsiveness of an application at unexpected
times.
5 Usually deployed in computing systems where deterministic
behavior is not an important criterion.

6 Personal Computer/Desktop system is a typical example for


a system where GPOSs are deployed.

7 Windows XP/MS-DOS etc are examples of General Purpose


Operating System.

5.3.2 Real Time Purpose Operating System (RTOS)

1 Operating Systems, which are deployed in embedded


systems demanding real-time response.

2 Deterministic in execution behavior. Consumes only known


amount of time for kernel applications.

3 Implements scheduling policies for executing the highest


priority task/application always.
5.4. THE REAL TIME KERNEL 121

4 Implements policies and rules concerning time-critical


allocation of a system’s resources.

5 Windows CE, QNX, VxWorks , MicroC/OS-II etc are


examples of Real Time Operating Systems (RTOS).

5.4 The Real Time Kernel

The kernel of a Real Time Operating System is referred as Real


Time kernel. In complement to the conventional OS kernel, the
Real Time kernel is highly specialized and it contains only the
minimal set of services required for running the user
applications/tasks. The basic functions of a Real Time kernel are -

1 Task/Process management

2 Task/Process scheduling

3 Task/Process synchronization

4 Error/Exception handling

5 Memory Management

6 Interrupt handling

7 Time management

Task/Process Management

Deals with setting up the memory space for the tasks, loading the
task’s code into the memory space, allocating system resources,
setting up a Task Control Block (TCB) for the task and
task/process termination/deletion. A Task Control Block (TCB)
is used for holding the information corresponding to a task. TCB
usually contains the following set of information.
122 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

1 Task ID: Task Identification Number

2 Task State: The current state of the task. (E.g. State= ‘Ready’
for a task which is ready to execute)

3 Task Type: Indicates what is the type for this task. The task
can be a hard real time or soft real time or background task.

4 Task Priority: Task priority (E.g. Task priority =1 for task


with priority = 1)

5 Task Context Pointer: Context pointer. Pointer for context


saving

6 Task Memory Pointers: Pointers to the code memory, data


memory and stack memory for the task

7 Task System Resource Pointers: Pointers to system resources


(semaphores, mutex etc) used by the task

8 Task Pointers: Pointers to other TCBs (TCBs for preceding,


next and waiting tasks)

9 Other Parameters Other relevant task parameters

The parameters and implementation of the TCB is


kernel dependent. The TCB parameters vary across different
kernels, based on the task management implementation

Task/Process Scheduling

Deals with sharing the CPU among various tasks/processes. A


kernel application called ‘Scheduler’ handles the task scheduling.
Scheduler is nothing but an algorithm implementation, which
performs the efficient and optimal scheduling of tasks to provide
a deterministic behavior.
5.4. THE REAL TIME KERNEL 123

Task/Process Synchronization

Deals with synchronizing the concurrent access of a resource,


which is shared across multiple tasks and the communication
between various tasks.

Error/Exception handling

Deals with registering and handling the errors


occurred/exceptions raised during the execution of tasks.
Insufficient memory, timeouts, deadlocks, deadline missing, bus
error, divide by zero, unknown instruction execution etc, are
examples of errors/exceptions. Errors/Exceptions can happen at
the kernel level services or at task level. Deadlock is an example
for kernel level exception, whereas timeout is an example for a
task level exception. The OS kernel gives the information about
the error in the form of a system call (API).

Memory Management

1 The memory management function of an RTOS kernel is


slightly different compared to the General Purpose
Operating Systems.

2 The memory allocation time increases depending on the size


of the block of memory needs to be allocated and the state of
the allocated memory block (initialized memory block
consumes more allocation time than un- initialized memory
block).

3 Since predictable timing and deterministic behavior are the


primary focus for an RTOS, RTOS achieves this by
compromising the effectiveness of memory allocation.

4 RTOS generally uses ‘block’ based memory allocation


124 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

technique, instead of the usual dynamic memory allocation


techniques used by the GPOS.

5 RTOS kernel uses blocks of fixed size of dynamic memory


and the block is allocated for a task on a need basis. The
blocks are stored in a ‘Free buffer Queue’.

6 Most of the RTOS kernels allow tasks to access any of the


memory blocks without any memory protection to achieve
predictable timing and avoid the timing overheads.

7 RTOS kernels assume that the whole design is proven correct


and protection is unnecessary. Some commercial RTOS
kernels allow memory protection as optional and the kernel
enters a fail-safe mode when an illegal memory access occurs.

8 The memory management function of an RTOS kernel is


slightly different compared to the General Purpose
Operating Systems

9 A few RTOS kernels implement Virtual Memory concept for


memory allocation if the system supports secondary memory
storage (like HDD and FLASH memory).

10 In the ‘block’ based memory allocation, a block of fixed


memory is always allocated for tasks on need basis and it is
taken as a unit. Hence, there will not be any memory
fragmentation issues.

11 The memory allocation can be implemented as constant


functions and thereby it consumes fixed amount of time for
memory allocation. This leaves the deterministic behavior of
the RTOS kernel untouched.
5.4. THE REAL TIME KERNEL 125

Interrupt Handling

1 Interrupts inform the processor that an external device or an


associated task requires immediate attention of the CPU.

2 Interrupts can be either Synchronous or Asynchronous.

3 Interrupts which occurs in sync with the currently executing


task is known as Synchronous interrupts. Usually the
software interrupts fall under the Synchronous Interrupt
category. Divide by zero, memory segmentation error etc are
examples of Synchronous interrupts.

4 For synchronous interrupts, the interrupt handler runs in the


same context of the interrupting task.

5 Asynchronous interrupts are interrupts, which occurs at any


point of execution of any task, and are not in sync with the
currently executing task.

6 The interrupts generated by external devices (by asserting


the Interrupt line of the processor/controller to which the
interrupt line of the device is connected) connected to the
processor/controller, timer overflow interrupts, serial data
reception/ transmission interrupts etc are examples for
asynchronous interrupts.

7 For asynchronous interrupts, the interrupt handler is usually


written as separate task (Depends on OS Kernel
implementation) and it runs in a different context. Hence, a
context switch happens while handling the asynchronous
interrupts.

8 Priority levels can be assigned to the interrupts and each


interrupts can be enabled or disabled individually.

9 Most of the RTOS kernel implements ‘Nested Interrupts’


architecture. Interrupt nesting allows the pre-emption
126 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

(interruption) of an Interrupt Service Routine (ISR), servicing


an interrupt, by a higher priority interrupt.

Time Management

1 Interrupts inform the processor that an external device or an


associated task requires immediate attention of the CPU.

2 Accurate time management is essential for providing precise


time reference for all applications.

3 The time reference to kernel is provided by a high-resolution


Real Time Clock (RTC) hardware chip (hardware timer).

4 The hardware timer is programmed to interrupt the


processor/controller at a fixed rate. This timer interrupt is
referred as ‘Timer tick’.
5 The ‘Timer tick’ is taken as the timing reference by the
kernel. The ‘Timer tick’ interval may vary depending on the
hardware timer. Usually the ‘Timer tick’ varies in the
microseconds range.

6 The time parameters for tasks are expressed as the multiples


of the ‘Timer tick’
7 The System time is updated based on the ‘Timer tick’

8 If the System time register is 32 bits wide and the ‘Timer tick’
interval is 1 microsecond, the System time register will reset
in
232 × 10−6
= 0.0497Days = 1.19Hours
24 × 60 × 60
If the ‘Timer tick’ interval is 1 millisecond, the System time
register will reset in

232 × 10−3
= 49.7Days = 50Days
24 × 60 × 60
5.5. HARD REAL-TIME SYSTEM 127

The ‘Timer tick’ interrupt is handled by the ‘Timer Interrupt’


handler of kernel. The ‘Timer tick’ interrupt can be utilized
for implementing the following actions.
9 Save the current context (Context of the currently executing
task).

10 Increment the System time register by one. Generate timing


error and reset the System time register if the timer tick count
is greater than the maximum range available for System time
register.

11 Update the timers implemented in kernel (Increment or


decrement the timer registers for each timer depending on
the count direction setting for each register. Increment
registers with count direction setting = ‘count up’ and
decrement registers with count direction setting = ‘count
down’).

12 Activate the periodic tasks, which are in the idle state.

13 Invoke the scheduler and schedule the tasks again based on


the scheduling algorithm.

14 Delete all the terminated tasks and their associated data


structures (TCBs).

15 Load the context for the first task in the ready queue. Due
to the re- scheduling, the ready task might be changed to a
new one from the task, which was pre-empted by the ‘Timer
Interrupt’ task.

5.5 Hard Real-time System

1 A Real Time Operating Systems which strictly adheres to the


timing constraints for a task.
128 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

2 A Hard Real Time system must meet the deadlines for a task
without any slippage.

3 Missing any deadline may produce catastrophic results for


Hard Real Time Systems, including permanent data lose and
irrecoverable damages to the system/users.

4 Emphasize on the principle ‘A late answer is a wrong answer’.

5 Air bag control systems and Anti-lock Brake Systems (ABS)


of vehicles are typical examples of Hard Real Time Systems.

6 As a rule of thumb, Hard Real Time Systems does not


implement the virtual memory model for handling the
memory. This eliminates the delay in swapping in and out
the code corresponding to the task to and from the primary
memory.

7 The presence of Human in the loop (HITL) for tasks


introduces un- expected delays in the task execution. Most
of the Hard Real Time Systems are automatic and does not
contain a ‘human in the loop’.

5.6 Soft Real-time System

1 Real Time Operating Systems that does not guarantee


meeting deadlines, but, offer the best effort to meet the
deadline.

2 Missing deadlines for tasks are acceptable if the frequency of


deadline missing is within the compliance limit of the Quality
of Service (QoS).

3 A Soft Real Time system emphasizes on the principle ‘A late


answer is an acceptable answer, but it could have done bit faster’.
5.7. TASKS, PROCESSES & THREADS 129

4 Soft Real Time systems most often have a ‘human in the loop
(HITL)’.
5 Automatic Teller Machine (ATM) is a typical example of Soft
Real Time System. If the ATM takes a few seconds more than
the ideal operation time, nothing fatal happens.

6 An audio video play back system is another example of Soft


Real Time system. No potential damage arises if a sample
comes late by fraction of a second, for play back.

5.7 Tasks, Processes & Threads

1 In the Operating System context, a task is defined as the


program in execution and the related information
maintained by the Operating system for the program.

2 Task is also known as ‘Job’ in the operating system context.

3 A program or part of it in execution is also called a ‘Process’.

4 The terms ‘Task’, ‘job’ and ‘Process’ refer to the same entity in
the Operating System context and most often they are used
interchangeably.

5 A process requires various system resources like CPU for


executing the process, memory for storing the code
corresponding to the process and associated variables, I/O
devices for information exchange etc.

The structure of a Processes

1 The concept of ‘Process’ leads to concurrent execution (pseudo


parallelism) of tasks and thereby the efficient utilization of the
CPU and other system resources.
130 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

2 Concurrent execution is achieved through the sharing of CPU


among the processes.

3 A process mimics a processor in properties and holds a set


of registers, process status, a Program Counter (PC) to point
to the next executable instruction of the process, a stack for
holding the local variables associated with the process and
the code corresponding to the process.

Figure 5.5: Structure of a Process

4 A process, which inherits all the properties of the CPU, can


be considered as a virtual processor, awaiting its turn to have
its properties switched into the physical processor.

5 When the process gets its turn, its registers and Program
counter register becomes mapped to the physical registers of
the CPU.
5.7. TASKS, PROCESSES & THREADS 131

Memory organization of Processes

Figure 5.6: Memory organization of a Process

1 The memory occupied by the process is segregated into three


regions namely; Stack memory, Data memory and Code
memory.

2 The ‘Stack’ memory holds all temporary data such as


variables local to the process.

3 Data memory holds all global data for the process.

4 The code memory contains the program code (instructions)


corresponding to the process.

5 On loading a process into the main memory, a specific area of


memory is allocated for the process.

6 The stack memory usually starts at the highest memory


address from the memory area allocated for the process
(Depending on the OS kernel implementation).
132 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

Process States & State Transition

1 The creation of a process to its termination is not a single step


operation

2 The process traverses through a series of states during its


transition from the newly created state to the terminated
state
3 The cycle through which a process changes its state from
‘newly created’ to ‘execution completed’ is known as ‘Process Life
Cycle’. The various states through which a process traverses
through during a Process Life Cycle indicates the current
status of the process with respect to time and also provides
information on what it is allowed to do next.

Figure 5.7: Process states and State transition

(a) Created State: The state at which a process is being


created is referred as ‘Created State’. The Operating
System recognizes a process in the ‘Created State’ but no
resources are allocated to the process.
(b) Ready State: The state, where a process is incepted into
the memory and awaiting the processor time for
execution, is known as ‘Ready State’. At this stage, the
5.7. TASKS, PROCESSES & THREADS 133

process is placed in the ‘Ready list’ queue maintained by


the OS.
(c) Running State: The state where in the source code
instructions corresponding to the process is being
executed is called ‘Running State’. Running state is the
state at which the process execution happens.
(d) Blocked State/Wait State: Refers to a state where a
running process is temporarily suspended from
execution and does not have immediate access to
resources. The blocked state might have invoked by
various conditions like- the process enters a wait state
for an event to occur (E.g. Waiting for user inputs such
as keyboard input) or waiting for getting access to a
shared resource like semaphore, mutex etc.
(e) Completed State: A state where the process completes its
execution.
i. The transition of a process from one state to another
is known as ‘State transition’,
ii. When a process changes its state from Ready to
running or from running to blocked or terminated or
from blocked to running, the CPU allocation for the
process may also change.

Threads

1 A thread is the primitive that can execute code.

2 A thread is a single sequential flow of control within a


process.

3 ‘Thread’ is also known as lightweight process.

4 A process can have many threads of execution.


134 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

5 Different threads, which are part of a process, share the same


address space; meaning they share the data memory, code
memory and heap memory area.

6 Threads maintain their own thread status (CPU register


values), Program Counter (PC) and stack.

Figure 5.8: Memory organization of process and its associated Threads

The Concept of multithreading

Use of multiple threads to execute a process brings the following


advantage.

Figure 5.9: Process with multi-threads


5.7. TASKS, PROCESSES & THREADS 135

1 Better memory utilization. Multiple threads of the same


process share the address space for data memory. This also
reduces the complexity of inter thread communication since
variables can be shared across the threads.
2 Since the process is split into different threads, when one
thread enters a wait state, the CPU can be utilized by other
threads of the process that do not require the event, which
the other thread is waiting, for processing. This speeds up
the execution of the process.

3 Efficient CPU utilization. The CPU is engaged all time.

Advantages of Threads

1 Better memory utilization: Multiple threads of the same


process share the address space for data memory. This also
reduces the complexity of inter thread communication since
variables can be shared across the threads.
2 Efficient CPU utilization: The CPU is engaged all time.

3 Speeds up the execution of the process: The process is split


into different threads, when one thread enters a wait state,
the CPU can be utilized by other threads of the process that
do not require the event, which the other thread is waiting,
for processing.

Thread Vs Process

S.N. Thread Process


1 Thread is a single unit of Process is a program in
execution and is part of execution and contains one
process. or more threads.
136 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

2 A thread does not have its Process has its own code
own data memory and heap memory, data memory and
memory. It shares the data stack memory.
memory and heap memory
with other threads of the
same process.
3 A thread cannot live A process contains at least
independently; it lives one thread.
within the process.
4 There can be multiple Threads within a process
threads in a process. The share the code, data and heap
first thread (main thread) memory. Each thread holds
calls the main function and separate memory area for
occupies the start of the stack stack (shares the total stack
memory of the process. memory of the process).
5 Threads are very inexpensive Processes are very expensive
to create. to create. Involves many OS
overhead.
6 Context switching is Context switching is
inexpensive and fast. complex and involves lot
of OS overhead and is
comparatively slower.
7 If a thread expires, its stack is If a process dies, the
reclaimed by the process. resources allocated to it
are reclaimed by the OS and
all the associated threads of
the process also dies.

5.8 Multiprocessing & Multitasking

1 The ability to execute multiple processes simultaneously is


referred as multiprocessing.

2 Systems which are capable of performing multiprocessing are


5.9. TYPES OF MULTITASKING 137

known as multiprocessor systems.

3 Multiprocessor systems possess multiple CPUs and can


execute multiple processes simultaneously.

4 The ability of the Operating System to have multiple


programs in memory, which are ready for execution, is
referred as multiprogramming.

5 Multitasking refers to the ability of an operating system to


hold multiple processes in memory and switch the processor
(CPU) from executing one process to another process.

6 Multitasking involves ‘Context switching’, ‘Context saving’ and


‘Context retrieval’.

7 Context switching refers to the switching of execution


context from task to other.

8 When a task/process switching happens, the current context


of execution should be saved to (Context saving) retrieve it
at a later point of time when the CPU executes the process,
which is interrupted currently due to execution switching

9 During context switching, the context of the task to be


executed is retrieved from the saved context list. This is
known as Context retrieval.

10 Multiprogramming: The ability of the Operating System to


have multiple programs in memory, which are ready for
execution, is referred as multiprogramming.

5.9 Types of Multitasking

Depending on how the task/process execution switching act is


implemented, multitasking can is classified into -
138 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

1 Co-operative Multitasking: Co-operative multitasking is the


most primitive form of multitasking in which a task/process
gets a chance to execute only when the currently executing
task/process voluntarily relinquishes the CPU. In this
method, any task/process can avail the CPU as much time
as it wants. Since this type of implementation involves the
mercy of the tasks each other for getting the CPU time for
execution, it is known as co-operative multitasking. If the
currently executing task is non-cooperative, the other tasks
may have to wait for a long time to get the CPU

2 Preemptive Multitasking: Preemptive multitasking ensures


that every task/process gets a chance to execute. When and
how much time a process gets is dependent on the
implementation of the preemptive scheduling. As the name
indicates, in preemptive multitasking, the currently running
task/process is preempted to give a chance to other
tasks/process to execute. The preemption of task may be
based on time slots or task/process priority

3 Non-preemptive Multitasking: The process/task, which is


currently given the CPU time, is allowed to execute until it
terminates (enters the ‘Completed’ state) or enters the
‘Blocked/Wait’ state, waiting for an I/O. The co- operative
and non-preemptive multitasking differs in their behavior
when they are in the ‘Blocked/Wait’ state. In co-operative
multitasking, the currently executing process/task need not
relinquish the CPU when it enters the ‘Blocked/Wait’ sate,
waiting for an I/O, or a shared resource access or an event to
occur whereas in non-preemptive multitasking the currently
executing task relinquishes the CPU when it waits for an
I/O.
5.10. TASK SCHEDULING 139

5.10 Task Scheduling

1 In a multitasking system, there should be some mechanism


in place to share the CPU among the different tasks and to
decide which process/task is to be executed at a given point
of time

2 Determining which task/process is to be executed at a given


point of time is known as task/process scheduling.

3 Task scheduling forms the basis of multitasking

4 Scheduling policies forms the guidelines for determining


which task is to be executed when.

5 The scheduling policies are implemented in an algorithm and


it is run by the kernel as a service.

6 The kernel service/application, which implements the


scheduling algorithm, is known as ‘Scheduler’.

7 The task scheduling policy can be pre-emptive, non-preemptive


or co- operative.

8 Depending on the scheduling policy the process scheduling


decision may take place when a process switches its state to

(a) ‘Ready’ state from ‘Running’ state


(b) ‘Blocked/Wait’ state from ‘Running’ state
(c) ‘Ready’ state from ‘Blocked/Wait’ state
(d) ‘Completed’ state

5.10.1 Task Scheduling - Scheduler Selection

The selection of a scheduling criteria/algorithm should consider


140 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

1 CPU Utilization: The scheduling algorithm should always


make the CPU utilization high. CPU utilization is a direct
measure of how much percentage of the CPU is being
utilized.
2 Throughput: This gives an indication of the number of
processes executed per unit of time. The throughput for a
good scheduler should always be higher.

3 Turnaround Time: It is the amount of time taken by a process


for completing its execution. It includes the time spent by the
process for waiting for the main memory, time spent in the
ready queue, time spent on completing the I/O operations,
and the time spent in execution. The turnaround time should
be a minimum for a good scheduling algorithm.

4 Waiting Time: It is the amount of time spent by a process in


the ‘Ready’ queue waiting to get the CPU time for execution.
The waiting time should be minimal for a good scheduling
algorithm.

5 Response Time: It is the time elapsed between the


submission of a process and the first response. For a good
scheduling algorithm, the response time should be as least as
possible.

To summarize, a good scheduling algorithm has high


CPU utilization, minimum Turn Around Time (TAT), maximum
throughput and least response time.

5.10.2 Task Scheduling - Queues

The various queues maintained by OS in association with CPU


scheduling are

1 Job Queue: Job queue contains all the processes in the system
5.11. NON-PREEMPTIVE SCHEDULING 141

2 Ready Queue: Contains all the processes, which are ready for
execution and waiting for CPU to get their turn for execution.
The Ready queue is empty when there is no process ready for
running.

3 Device Queue: Contains the set of processes, which are


waiting for an I/O device.

5.11 Non-preemptive scheduling

5.11.1 First Come First Served (FCFS)/First In First Out


(FIFO) Scheduling

1 Allocates CPU time to the processes based on the order in


which they enters the ‘Ready’ queue.

2 The first entered process is serviced first.

3 It is same as any real world application where queue systems


are used; E.g. Ticketing.

Drawbacks

1 Favors monopoly of process. A process, which does not


contain any I/O operation, continues its execution until it
finishes its task.

2 In general, FCFS favors CPU bound processes and I/O


bound processes may have to wait until the completion of
CPU bound process, if the currently executing process is a
CPU bound process. This leads to poor device utilization.

3 The average waiting time is not minimal for FCFS scheduling


algorithm.
142 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

Example 1 Three processes with process IDs P1, P2, P3 with estimated
completion time 10, 5, 7 milliseconds respectively enters the ready queue
together in the order P1, P2, P3. Calculate the waiting time and Turn
Around Time (TAT) for each process and the Average waiting time and
Turn Around Time (Assuming there is no I/O waiting for the processes).

Solution : The sequence of execution of the processes by the CPU


is represented as -

Figure 5.10:

Assuming the CPU is readily available at the time of


arrival of P1, P1 starts executing without any waiting in the
‘Ready’ queue. Hence the waiting time for P1 is zero.

Waiting Time for P1 = 0 ms (P1 starts executing first)


Waiting Time for P2 = 10 ms (P2 starts executing after completing
P1)
Waiting Time for P3 = 15 ms (P3 starts executing after completing
P1 and P2)

(Waiting time for all processes)


Average waiting time =
No. of Processes
Waiting time for (P 1 + P 2 + P 3)
=
3
(0 + 10 + 15)
= = 8.33 miliseconds
3

Turn Around Time (TAT) for P1 = 10 ms (Time spent in Ready


Queue + Execution Time)
5.11. NON-PREEMPTIVE SCHEDULING 143

Turn Around Time (TAT) for P2 = 15 ms


Turn Around Time (TAT) for P3 = 22 ms

(Turn around time for all processes)


Average Turn Around Time =
No. of Processes
Turn around time for (P1 + P2 + P3)
=
3
(10 + 15 + 22) 47
= =
3 3
= 15.66 milliseconds

5.11.2 Last Come First Served (LCFS)/Last In First Out


(LIFO) Scheduling

1 Allocates CPU time to the processes based on the order in


which they are entered in the ‘Ready’ queue.

2 The last entered process is serviced first.

3 LCFS scheduling is also known as Last In First Out (LIFO)


where the process, which is put last into the ‘Ready’ queue, is
serviced first.

Drawbacks

1 Favors monopoly of process. A process, which does not


contain any I/O operation, continues its execution until it
finishes its task.

2 In general, LCFS favors CPU bound processes and I/O


bound processes may have to wait until the completion of
CPU bound process, if the currently executing process is a
CPU bound process. This leads to poor device utilization.
144 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

3 The average waiting time is not minimal for LCFS scheduling


algorithm.

Example 2 Three processes with process IDs P1, P2, P3 with estimated
completion time 10, 5, 7 milliseconds respectively enters the ready
queue together in the order P1, P2, P3 (Assume only P1 is present in
the ‘Ready’ queue when the scheduler picks up it and P2, P3 entered
‘Ready’ queue after that). Now a new process P4 with estimated
completion time 6ms enters the ‘Ready’ queue after 5ms of scheduling
P1. Calculate the waiting time and Turn Around Time (TAT) for each
process and the Average waiting time and Turn Around Time
(Assuming there is no I/O waiting for the processes).Assume all the
processes contain only CPU operation and no I/O operations are
involved.

Solution : Initially there is only P1 available in the Ready queue


and the scheduling sequence will be P1, P3, P2. P4 enters the
queue during the execution of P1 and becomes the last process
entered the ‘Ready’ queue. Now the order of execution changes to
P1, P4, P3, and P2 as given below.

Figure 5.11:

The waiting time for all the processes are given as


Waiting Time for P1 = 0 ms (P1 starts executing first)
Waiting Time for P4 = 5 ms (P4 starts executing after completing
P1. But P4 arrived after 5ms of execution of P1. Hence its waiting
time = Execution start time – Arrival Time = 10-5 = 5)
Waiting Time for P3 = 16 ms (P3 starts executing after completing
5.11. NON-PREEMPTIVE SCHEDULING 145

P1 and P4)
Waiting Time for P2 = 23 ms (P2 starts executing after completing
P1, P4 and P3)

(Waiting time for all processes)


Average waiting time =
No. of Processes
Waiting time for (P 1 + P 4 + P 3 + P 2)
=
4
(0 + 5 + 16 + 23) 44
= =
4 4
= 11 milliseconds

Turn Around Time (TAT) for P1 = 10 ms (Time spent in Ready


Queue + Execution Time)
Turn Around Time (TAT) for P4 = 11 ms (Time spent in Ready
Queue + Execution Time = (Execution Start Time – Arrival Time)
+ Estimated Execution Time = (10-5) + 6 = 5 + 6)
Turn Around Time (TAT) for P3 = 23 ms (Time spent in Ready
Queue + Execution Time)
Turn Around Time (TAT) for P2 = 28 ms (Time spent in Ready
Queue + Execution Time)
(Turn around time for all processes)
Average Turn Around Time =
No. of processes
Turn around time for(P 1 + P 4 + P 3 + P 2)
=
4
(10 + 11 + 23 + 28)
=
4
= 18 milliseconds

5.11.3 Shortest Job First (SJF) Scheduling

1 Allocates CPU time to the processes based on the execution


completion time for tasks.
146 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

2 The average waiting time for a given set of processes is


minimal in SJF scheduling.

3 Optimal compared to other non-preemptive scheduling like


FCFS.

Drawbacks

1 A process whose estimated execution completion time is


high may not get a chance to execute if more and more
processes with least estimated execution time enters the
‘Ready’ queue before the process with longest estimated
execution time starts its execution
2 May lead to the ‘Starvation’ of processes with high estimated
completion time

3 Difficult to know in advance the next shortest process in the


‘Ready’ queue for scheduling since new processes with
different estimated execution time keep entering the ‘Ready’
queue at any point of time.

5.11.4 Priority based Scheduling

1 A priority, which is unique or same is associated with each


task
2 The priority of a task is expressed in different ways, like a
priority number, the time required to complete the execution
etc.
3 In number based priority assignment the priority is a number
ranging from 0 to the maximum priority supported by the OS.
The maximum level of priority is OS dependent.

4 Windows CE supports 256 levels of priority (0 to 255 priority


numbers, with 0 being the highest priority).
5.11. NON-PREEMPTIVE SCHEDULING 147

5 The priority is assigned to the task on creating it. It can also


be changed dynamically (If the Operating System supports
this feature).

6 The non-preemptive priority based scheduler sorts the


‘Ready’ queue based on the priority and picks the process
with the highest level of priority for execution.

Example 3 Three processes with process IDs P1, P2, P3 with estimated
completion time 10, 5, 7 milliseconds and priorities 0, 3, 2 (0- highest
priority, 3 lowest priority) respectively enters the ready queue together.
Calculate the waiting time and Turn Around Time (TAT) for each process
and the Average waiting time and Turn Around Time (Assuming there is
no I/O waiting for the processes) in priority based scheduling algorithm.

Solution : The scheduler sorts the ‘Ready’ queue based on the


priority and schedules the process with the highest priority (P1
with priority number 0) first and the next high priority process
(P3 with priority number 2) as second and so on. The order in
which the processes are scheduled for execution is represented as
-

Figure 5.12:

The waiting time for all the processes are given as -


Waiting Time for P1 = 0 ms (P1 starts executing first)
Waiting Time for P3 = 10 ms (P3 starts executing after completing
P1)
Waiting Time for P2 = 17 ms (P2 starts executing after completing
148 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

P1 and P3)
Waiting time for all processes
Average waiting time =
No. of processes
Waiting time for (P 1 + P 3 + P 2)
=
3
(0 + 10 + 17) 27
= =
3 3
= 9 milliseconds

Turn Around Time (TAT) for P1 = 10 ms (Time spent in


Ready Queue + Execution Time)
Turn Around Time (TAT) for P3 = 17 ms
Turn Around Time (TAT) for P2 = 22 ms
Turn around time for all processes
Average Turn Around Time =
N o.of processes
Turn around time for(P 1 + P 3 + P 2)
=
3
(10 + 17 + 22) 49
= =
3 3
= 16.33 milliseconds

Drawbacks

1 Similar to SJF scheduling algorithm, non-preemptive


priority based algorithm also possess the drawback of
‘Starvation’ where a process whose priority is low may not
get a chance to execute if more and more processes with
higher priorities enter the ‘Ready’ queue before the process
with lower priority starts its execution.

2 ‘Starvation’ can be effectively tackled in priority based


non-preemptive scheduling by dynamically raising the
priority of the low priority task/process which is under
starvation (waiting in the ready queue for a longer time for
getting the CPU time).
5.12. PREEMPTIVE SCHEDULING 149

3 The technique of gradually raising the priority of processes


which are waiting in the ‘Ready’ queue as time progresses,
for preventing ‘Starvation’, is known as ‘Aging’.

5.12 Preemptive scheduling

1 Employed in systems, which implements preemptive


multitasking model.

2 Every task in the ‘Ready’ queue gets a chance to execute.


When and how often each process gets a chance to execute
(gets the CPU time) is dependent on the type of preemptive
scheduling algorithm used for scheduling the processes.

3 The scheduler can preempt (stop temporarily) the currently


executing task/process and select another task from the
‘Ready’ queue for execution.

4 When to pre-empt a task and which task is to be picked up


from the ‘Ready’ queue for execution after preempting the
current task is purely dependent on the scheduling algorithm.

5 A task which is preempted by the scheduler is moved to the


‘Ready’ queue. The act of moving a ‘Running’ process/task
into the ‘Ready’ queue by the scheduler, without the
processes requesting for it is known as ‘Preemption’.

6 Time-based preemption and priority-based preemption are


the two important approaches adopted in preemptive
scheduling.
150 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

5.12.1 Preemptive SJF Scheduling/ Shortest Remaining


Time (SRT)

1 The non preemptive SJF scheduling algorithm sorts the


‘Ready’ queue only after the current process completes
execution or enters wait state, whereas the preemptive SJF
scheduling algorithm sorts the ‘Ready’ queue when a new
process enters the ‘Ready’ queue and checks whether the
execution time of the new process is shorter than the
remaining of the total estimated execution time of the
currently executing process.

2 If the execution time of the new process is less, the currently


executing process is preempted and the new process is
scheduled for execution.

3 Always compares the execution completion time (ie the


remaining execution time for the new process) of a new
process entered the ‘Ready’ queue with the remaining time
for completion of the currently executing process and
schedules the process with shortest remaining time for
execution.

Example 4 Three processes with process IDs P1, P2, P3 with estimated
completion time 10, 5, 7 milliseconds respectively enters the ready queue
together. A new process P4 with estimated completion time 2ms enters
the ‘Ready’ queue after 2ms. Assume all the processes contain only CPU
operation and no I/O operations are involved.

Solution : At the beginning, there are only three processes (P1, P2


and P3) available in the ‘Ready’ queue and the SRT scheduler
picks up the process with the Shortest remaining time for
execution completion (In this example P2 with remaining time
5ms) for scheduling. Now process P4 with estimated execution
completion time 2ms enters the ‘Ready’ queue after 2ms of start
5.12. PREEMPTIVE SCHEDULING 151

of execution of P2. The processes are re-scheduled for execution


in the following order-

Figure 5.13:

The waiting time for all the processes are given as -


Waiting Time for P2 = 0 ms + (4 -2) ms = 2ms
(P2 starts executing first and is interrupted by P4 and has to wait
till the completion of P4 to get the next CPU slot)
Waiting Time for P4 = 0 ms
(P4 starts executing by preempting P2 since the execution time for
completion of P4 (2ms) is less than that of the Remaining time for
execution completion of P2 (Here it is 3ms))
Waiting Time for P3 = 7 ms
(P3 starts executing after completing P4 and P2)
Waiting Time for P1 = 14 ms (P1 starts executing after completing
P4, P2 and P3)
Waiting time for all processes
Average waiting time =
No. of processes
Waiting time for (P 4 + P 2 + P 3 + P 1)
=
4
(0 + 2 + 7 + 14) 23
= =
4 4
= 5.75 milliseconds

Turn Around Time (TAT) for P2 = 7 ms


(Time spent in Ready Queue + Execution Time)
Turn Around Time (TAT) for P4 = 2 ms
(Time spent in Ready Queue + Execution Time = (Execution Start
Time – Arrival Time) + Estimated Execution Time = (2-2) + 2)
152 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

Turn Around Time (TAT) for P3 = 14 ms


(Time spent in Ready Queue + Execution Time)
Turn Around Time (TAT) for P1 = 24 ms
(Time spent in Ready Queue + Execution Time)

Turn around time for all processes


Average Turn Around Time =
N o.of processes
Turn around time for(P 2 + P 4 + P 3 + P 1)
=
4
(7 + 2 + 14 + 24) 47
= =
4 4
= 11.75 milliseconds

5.13 Round Robin (RR) Scheduling

1 Each process in the ‘Ready’ queue is executed for a


pre-defined time slot.

2 The execution starts with picking up the first process in the


‘Ready’ queue. It is executed for a pre-defined time.

Figure 5.14: Round Robin Scheduling

3 When the pre-defined time elapses or the process completes


(before the pre- defined time slice), the next process in the
‘Ready’ queue is selected for execution.
5.13. ROUND ROBIN (RR) SCHEDULING 153

4 This is repeated for all the processes in the ‘Ready’ queue.

5 Once each process in the ‘Ready’ queue is executed for the


pre-defined time period, the scheduler comes back and picks
the first process in the ‘Ready’ queue again for execution.

6 Round Robin scheduling is similar to the FCFS scheduling


and the only difference is that a time slice based preemption
is added to switch the execution between the processes in the
‘Ready’ queue.

Example 5 Three processes with process IDs P1, P2, P3 with estimated
completion time 6, 4, 2 milliseconds respectively, enters the ready queue
together in the order P1, P2, P3. Calculate the waiting time and Turn
Around Time (TAT) for each process and the Average waiting time and
Turn Around Time (Assuming there is no I/O waiting for the processes)
in RR algorithm with Time slice= 2ms.

Solution : The scheduler sorts the ‘Ready’ queue based on the


FCFS policy and picks up the first process P1 from the ‘Ready’
queue and executes it for the time slice 2ms. When the time slice
is expired, P1 is preempted and P2 is scheduled for execution.
The Time slice expires after 2ms of execution of P2. Now P2 is
preempted and P3 is picked up for execution. P3 completes its
execution within the time slice and the scheduler picks P1 again
for execution for the next time slice. This procedure is repeated
till all the processes are serviced. The order in which the
processes are scheduled for execution is represented as -

Figure 5.15:
154 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

The waiting time for all the processes are given as -


Waiting Time for P1 = 0 + (6-2) + (10-8) = 0+4+2= 6ms
(P1 starts executing first and waits for two time slices to get
execution back and again 1 time slice for getting CPU time)
Waiting Time for P2 = (2-0) + (8-4) = 2+4 = 6ms
(P2 starts executing after P1 executes for 1 time slice and waits for
two time slices to get the CPU time)
Waiting Time for P3 = (4 -0) = 4ms
(P3 starts executing after completing the first time slices for P1
and P2 and completes its execution in a single time slice.)

Waiting time for all processes


Average waiting time =
No. of processes
Waiting time for (P 1 + P 2 + P 3)
=
3
(6 + 6 + 4) 16
= =
3 3
= 5.33 milliseconds

Turn Around Time (TAT) for P1 = 12 ms


(Time spent in Ready Queue + Execution Time)
Turn Around Time (TAT) for P2 = 10 ms
Turn Around Time (TAT) for P3 = 6 ms

Turn around time for all processes


Average Turn Around Time =
N o.of processes
Turn around time for(P 1 + P 2 + P 3)
=
3
(12 + 10 + 6) 28
= =
3 3
= 9.33 milliseconds
5.14. PRIORITY BASED SCHEDULING 155

5.14 Priority based Scheduling

1 Same as that of the non-preemptive priority based scheduling


except for the switching of execution between tasks.

2 In preemptive priority based scheduling, any high priority


process entering the ‘Ready’ queue is immediately
scheduled for execution whereas in the non-preemptive
scheduling any high priority process entering the ‘Ready’
queue is scheduled only after the currently executing process
completes its execution or only when it voluntarily releases
the CPU.

3 The priority of a task/process in preemptive priority based


scheduling is indicated in the same way as that of the
mechanisms adopted for non- preemptive multitasking.

Example 6 Three processes with process IDs P1, P2, P3 with estimated
completion time 10, 5, 7 milliseconds and priorities 1, 3, 2 (0- highest
priority, 3 lowest priority) respectively enters the ready queue together.
A new process P4 with estimated completion time 6ms and priority 0
enters the ‘Ready’ queue after 5ms of start of execution of P1. Assume
all the processes contain only CPU operation and no I/O operations are
involved.

Solution : At the beginning, there are only three processes (P1, P2


and P3) available in the ‘Ready’ queue and the scheduler picks
up the process with the highest priority (In this example P1 with
priority 1) for scheduling. Now process P4 with estimated
execution completion time 6ms and priority 0 enters the ‘Ready’
queue after 5ms of start of execution of P1. The processes are
re-scheduled for execution in the following order -
156 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

Figure 5.16:

The waiting time for all the processes are given as -


Waiting Time for P1 = 0 + (11-5) = 0+6 =6 ms
(P1 starts executing first and gets Preempted by P4 after 5ms and
again gets the CPU time after completion of P4)
Waiting Time for P4 = 0 ms
(P4 starts executing immediately on entering the ‘Ready’ queue,
by preempting P1)
Waiting Time for P3 = 16 ms
(P3 starts executing after completing P1 and P4)
Waiting Time for P2 = 23 ms
(P2 starts executing after completing P1, P4 and P3)
Waiting time for all processes
Average waiting time =
No. of processes
Waiting time for (P 1 + P 4 + P 3 + P 2)
=
4
(6 + 0 + 16 + 23) 45
= =
4 4
= 11.25 milliseconds

Turn Around Time (TAT) for P1 = 16 ms


(Time spent in Ready Queue + Execution Time)
Turn Around Time (TAT) for P4 = 6ms
(Time spent in Ready Queue + Execution Time = (Execution Start
Time – Arrival Time) + Estimated Execution Time = (5-5) + 6 = 0 +
6)
Turn Around Time (TAT) for P3 = 23 ms
(Time spent in Ready Queue + Execution Time)
5.15. HOW TO CHOSE RTOS 157

Turn Around Time (TAT) for P2 = 28 ms


(Time spent in Ready Queue + Execution Time)

Turn around time for all processes


Average Turn Around Time =
N o.of processes
Turn around time for(P 2 + P 4 + P 3 + P 1)
=
4
(16 + 6 + 23 + 28) 73
= =
4 4
= 18.25 milliseconds

5.15 How to chose RTOS

1 The decision of an RTOS for an embedded design is very


critical.

2 A lot of factors need to be analyzed carefully before making a


decision on the selection of an RTOS.

3 These factors can be either

(a) Functional requirements


(b) Non-functional requirements

5.15.1 Functional Requirements

1 Processor support

(a) It is not necessary that all RTOS’s support all kinds of


processor architectures.
(b) It is essential to ensure the processor support by the RTOS

2 Memory Requirements
158 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

(a) The RTOS requires ROM memory for holding the OS files
and it is normally stored in a non-volatile memory like
FLASH.
(b) OS also requires working memory RAM for loading the
OS service.
(c) Since embedded systems are memory constrained, it is
essential to evaluate the minimal RAM and ROM
requirements for the OS under consideration.
(d) Real-Time Capabilities:
i. It is not mandatory that the OS for all embedded
systems need to be Real- Time and all embedded
OS’s are ‘Real-Time’ in behavior.
ii. The Task/process scheduling policies plays an
important role in the Real- Time behavior of an OS.

3 Kernel and Interrupt Latency

(a) The kernel of the OS may disable interrupts while


executing certain services and it may lead to interrupt
latency.
(b) For an embedded system whose response requirements
are high, this latency should be minimal.

4 Inter process Communication (IPC) and Task


Synchronization: The implementation of IPC and
Synchronization is OS kernel dependent.

5 Modularization Support

(a) Most of the OS’s provide a bunch of features.


(b) It is very useful if the OS supports modularization where
in which the developer can choose the essential modules
and re-compile the OS image for functioning.
(c) Support for Networking and Communication:
5.15. HOW TO CHOSE RTOS 159

i. The OS kernel may provide stack implementation


and driver support for a bunch of communication
interfaces and networking.
ii. Ensure that the OS under consideration provides
support for all the interfaces required by the
embedded product.

6 Development Language Support


(a) Certain OS’s include the run time libraries required for
running applications written in languages like JAVA and
C++.
(b) The OS may include these components as built-in
component, if not , check the availability of the same
from a third party.

5.15.2 Non-Functional Requirements

1 Custom Developed or Off the Shelf


(a) It is possible to go for the complete development of an
OS suiting the embedded system needs or use an off the
shelf, readily available OS.
(b) It may be possible to build the required features by
customizing an open source OS.
(c) The decision on which to select is purely dependent on
the development cost, licensing fees for the OS,
development time and availability of skilled resources.

2 Cost
The total cost for developing or buying the OS and
maintaining it in terms of commercial product and custom
build needs to be evaluated before taking a decision on the
selection of OS.
3 Development and Debugging tools Availability
160 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

(a) The availability of development and debugging tools is


a critical decision making factor in the selection of an OS
for embedded design.
(b) Certain OS’s may be superior in performance, but the
availability of tools for supporting the development may
be limited.
4 Ease of Use
How easy it is to use a commercial RTOS is another important
feature that needs to be considered in the RTOS selection.
5 After Sales
For a commercial embedded RTOS, after sales in the form of
e-mail, on-call services etc. for bug fixes, critical patch
updates and support for production issues etc. should be
analyzed thoroughly.

5.16 Device Drivers

Figure 5.17:

1 Device driver is a piece of software that acts as a bridge


between the operating system and the hardware.
5.16. DEVICE DRIVERS 161

2 The user applications talk to the OS kernel for all necessary


information exchange including communication with the
hardware peripherals.

3 The architecture of the OS kernel will not allow direct device


access from the user application.

4 All the device related access should flow through the OS


kernel and the OS kernel routes it to the concerned hardware
peripheral.

5 OS Provides interfaces in the form of Application


Programming Interfaces (APIs) for accessing the hardware.

6 The device driver abstracts the hardware from user


applications.

7 Device drivers are responsible for initiating and managing


the communication with the hardware peripherals.

8 Drivers which comes as part of the Operating system image is


known as ‘built-in drivers’ or ‘onboard’ drivers. Eg. NAND
FLASH driver.

9 Drivers which needs to be installed on the fly for


communicating with add- on devices are known as
‘Installable drivers’.

10 For installable drivers, the driver is loaded on a need basis


when the device is present and it is unloaded when the device
is removed/detached.

11 The ‘Device Manager service of the OS kernel is responsible


for loading and unloading the driver, managing the driver
etc.

12 The underlying implementation of device driver is OS kernel


dependent
162 CHAPTER 5. RTOS BASED EMBEDDED SYSTEM DESIGN

13 The driver communicates with the kernel is dependent on the


OS structure and implementation.

14 Device drivers can run on either user space or kernel space.

15 Device drivers which run in user space are known as user


mode drivers and the drivers which run in kernel space are
known as kernel mode drivers.

16 User mode drivers are safer than kernel mode drivers.

17 If an error or exception occurs in a user mode driver, it won’t


affect the services of the kernel.

18 If an exception occurs in the kernel mode driver, it may lead


to the kernel crash.

19 The way how a device driver is written and how the


interrupts are handled in it are Operating system and target
hardware specific.

20 The device driver implements the following:

(a) Device (Hardware) Initialization and Interrupt


configuration
(b) Interrupt handling and processing
(c) Client interfacing (Interfacing with user applications)

21 The basic Interrupt configuration involves the following :

(a) Set the interrupt type (Edge Triggered (Rising/Falling) or


Level Triggered (Low or High)), enable the interrupts and
set the interrupt priorities.
(b) The processor identifies an interrupt through IRQ.
(c) IRQs are generated by the Interrupt Controller.
5.16. DEVICE DRIVERS 163

(d) Register an Interrupt Service Routine (ISR) with an


Interrupt Request (IRQ).
(e) When an interrupt occurs, depending on its priority, it is
serviced and the corresponding ISR is invoked.
(f) The processing part of an interrupt is handled in an ISR.
(g) The whole interrupt processing can be done by the ISR
itself or by invoking an Interrupt Service Thread (IST)
(h) The IST performs interrupt processing on behalf of the
ISR
(i) It is always advised to use an IST for interrupt processing,
to make the ISR compact and short.

You might also like