Real Time Operating System

for
Embedded DSP Applications
By
P.S.Dey
Lecturer
Computer Science & Engg. Dept.
I.I.T. Kharagpur

Organization of the Talk

1. Real Time Systems an Overview.
2. Key Features of Embedded Systems.
3. Real Time Operating Systems Key
Features.
4. Case Studies.

Real Time Systems - 1

1. Any Real Time System MUST be capable to
sense some external / outside external world
events like Overheating of a Boiler, Incoming
call in a mobile.
2. Any Real Time System , MUST react/ respond
to the relevant External Events within a prespecified Deadline. ( Timeliness).
3. In addition to Timeliness , the Response
generated by the concerned Real Time
System MUST be correct in some way.

Reference Model of Real Time System :

The Key Elements
1) A re s ourc e Mode l that describes the the system
resources available to the applications.
2) Workload Mode l that describes the applications
supported by the system.
3) Sc he duling Alg orithm s that define how the
application system use the resources at all times. This is
where Real Time Operating Systems has a key role to
play.
N.B: In most cases we shall assume that all the resources as well
as the applications are already specified and we are primarily
concerned with specifying the Scheduling and Resource Usage
& Management Algorithms .

Modeling Real Time System

Key Components
1.

2.

3.
4.
5.

Job / Thread Unit of work that is sche d ule d &

e xe cute d b y a syste m e.g. Control Law
Computation, FFT Computation, A Packet
Transmission etc.
Task : A set of related jobs that jointly provide a
function e.g. the task of frequency control in a
Thermal Power Generating Station consists of a Host
of jobs ranging from Boiler Temperature Monitoring,
Turbine Speed Control , Gas recycling, Alternator
Frequency Monitoring , Grid Frequency Monitoring etc.
Associated Timing Constraints of a Job/ Task.
Available Resources.
The Scheduling Policy of Tasks to available
Resources.

Real Time System

Key Timing Constraints of a Job

z Release Time of a Job : The instant of

time when the job becomes available for
execution I.e. the instant of time when the
concerned job comes in the Ready State /
Ready Queue. The job can be scheduled and
executed at any time after its release time
whenever its data and control dependency
conditions are met.
z Release time of a job Ji will hence forth be
referred to as ri

Real Time System

Release Time Example
z

Furnace Controlling System :

a) Several say N number of Furnaces are to be controlled.
b) Samples , Reads as well as stores the Temperature of each Furnace at an
Interval of 100 msec ( T units of time ) .
c) It also computes the control law of each furnace once in every 100 msec (T
units of time) in order to process the temperature reading as well as determines
the various control parameters.
d) Suppose the system , after start up begins the first operation ( Control law
computation ) at 20 msec ( S units of time).
e) The different Control Law computation of jobs of the N furnaces are denoted by
J0, J1, J2, ,, .., JN I.e. Jk ( K = 0 N)
f) Release Time of the job Jk in this job sequence considering periodic release
sequence of the jobs once in every 100 msec ( T units of time) after a starting
time of 20 msec ( S units of time).
r tk = 20 ( S) + k X 100 ( T ).
N.B: The jobs have no release Time if all the jobs are released / ready to be
scheduled and executed as soon as the system starts execution.

Real Time System

Key Timing Components
Deadline (Relative & Absolute), Response Time &
Execution Time
z Deadline of a Job Ji : The instant of time by which its execution is
to be completed .
z Response Time of a Job Ji [ Ti ]: The interval of time between a
jobs release time and its completion time .
z Relative Deadline of a Job Ji [ Di ] : Maximum allowable
re s pons e tim e of a job .
z Deadline / Absolute deadline of a job Ji [ di ]= Its Release Time
+ Its Relative Deadline.
z Relative Deadline [ Di ] is the most Important parameter of any job
Ji in any Real Time System.
z Execution Time of a Job Ji [ ei ] = The amount of time required to
complete the job when it executes alone with exclusive ownership of
all its resources. Clearly in a real life scenario Response Time [ Ti ]
OR Deadline [ Di ] > Execution Time [ei] .

Real Time System

Timing Constraints : Hard & Soft Deadlines

zHard Deadline :

Failure to meet such a deadline is

considered to be a fatal fault and will lead to disastrous
consequences e.g. Response of the break system of a
speeding Train approaching a Red Signal to the stop
command must come before the train crosses the Red
signal.

zSoft Deadline : Failure to miss a Soft Deadline is

undesirable but a few misses does no serious harm like
occasional delay in an on line trading of stocks. However
the systems overall performance becomes poorer and
poorer as more and more jobs starts missing the
deadline.

Hard & Soft Timing Constraints

Measure of Usefulness
z How serious the consequence of any job missing the specified
deadline OR finishing earlier than its Deadline / Usefulness of
the concerned Real Time system
= function of Tardiness / Lateness of that Job.
z Tardiness of a job : The time interval between its actual
completion time / Response Time and its pre-specified deadline
( relative/absolute) always +ve.
z Lateness of a job : The time interval between its actual
completion time and its pre-specified deadline
( relative/absolute) can be ve OR +ve ideally Zero.
z The usefulness of the result produced by any soft real time
job decreases gradually with increase in its tardiness or +ve
lateness. However for a Hard Deadline JOB finishing early (-ve
lateness) is also undesirable since it amounts to wastage of
resource.

Embedded System
Key Features
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

These are special purpose computer systems built into a larger device .
Most of these are usually Non User Programmable.
These systems are produced in Bulk.
It is less costly because of Bulk Production.
The devices like M obile Phones usually work under severe power budget
constraints to enhance their Battery life.
All such systems are usually application specific hence g e ne ral p urp ose
p e rip he ral inte rface s are absent.
Any Embedded System should have less M emory Requirement.
Relocation facility of faulty Electronic Memory to some unused good
Memory block should exist.
Usually Hard Timing Constraints are associated for most of its
functions necessitating usage of Real Time System features.
In general, each & every Embedded System happens to be application
specific Uni-Processor system, which is built on a simple hardware
architecture platform.

Real Time Operating System

Key Features
1.

Real-time operating system (RTOS) is a class of operating system

intended for real-time applications. Embedded Systems like
programmable thermostats, household appliance controllers, mobile
telephones, industrial robots, represent the largest class of such systems.

2.

An RTOS does not necessarily have high throughput; rather, a RTOS

provides facilities which, if used properly, guarantee that system
deadlines can be met generally ("soft real-time") or deterministically
("hard real-time").

3.

An RTOS is valued more for how quickly and/or predictably it can

respond to a particular event than for the given amount of work it can
perform over time. Key factors in an RTOS are therefore minimal
interrupt Latency as well as minimal Context switching Time.

4.

An RTOS will typically use specialized scheduling algorithms in order to

provide the real-time developer with the tools necessary to produce
deterministic behavior in the final system.

Real Time Operating System

Various Asp e cts & The ir Ap p licab ility in Emb e d d e d
Ap p lications

A.
B.
C.
D.

Overall System Architecture.

Process Handling.
Scheduling Strategy.
Synchronization & Inter Process
Communication.
E. Network Support & Other Features.

Various Aspects of RTOS 1

Overall Architecture
1. Monolithic.
2. Layered.
3. Micro Kernel.

Various Typ e s of Re al Time Op e rating Syste m

Overall Architecture - 1
1.

Monolithic
a) Uni _Prcessor and Single layered.
b) Operating System mostly runs in previliged mode.
c) All type of Service Requests are made by the User Processes through
dedicated System Calls.
d) Interrups are handled directly by the Kernel and Interrupt Handlers are not full
fledged processes.
e) Interrupt handlers cannot invoke / use most of the system services.
f) O.S. Schedulers are disabled during Handling of the Interrupt since it operates
at the Highest priority.
g) Useful for very small application specific systems, because of its simplicity
and very low processor and memory overhaead.
h) Applications , as a whole can also be run in the Supervisor mode by bnding it
with the O.S. code during Link Time. However this can make debugging very
very difficult.
i) Upgradation of individual software components is NOT POSSIBLE, without
replacing the old Operating System as a whole followed by reboting.

Various Typ e s of Re al Time Op e rating Syste m

Overall Architecture - 2

2. Layered :
a) Modular design where any O.S. Module is
dependent on the Modules lying in the layer
below it as well as it provides service to its
upper layer (s).
b) O.S. Interface as well as Interrupt Handling
are like Monolithic Systems.
c) Easier maintainability as well as
Upgradeability because of Layered
Organization.

Various Typ e s of Re al Time Op e rating Syste m

Overall Architecture - 3
3. Micro Kernel :
a) Modular design with a M inimal Privileged O .S. KERNEL code.
b) Most Operating System Functions are moved from the KERNEL up to the User level.
c) Applications request O.S. services by sending a message to the appropriate O.S.
Server and waiting for a reply.
d) Handling of Inter Process Communications , enforcing securities, Accessing I/O
Peripherals are done in the User mode.
e) Easier to manage and maintain.
f) Reliability increases because since the Operating System Services run in User Mode
, failure of some will make that service unavailable but will not cause a System Crash.
Moreover failed system can be restarted and replaced without shutting down the
System.
g) Easily extendable to distributed systems where operating system functions can be
split across a set of distinct machines connected by a communication network.
Micro Kernel Architecture is one of the best suited for handling Embedded
Applications.

Various Aspects of RTOS 2

Process Handling Options
1.
2.
3.
4.

Multi Programming & Multi Tasking .

Multi Processing.
Multi Threading
Hyper Threading.

Multi Programming
(State Diagram)
Ready Queue
of User Programs | |||

Dispatch / Schedule
(Predefined Policy)

Running

Finished Peripheral Oper. [Interrupt #1]

Waiting ( doing Peripheral # 1)

Finished
Peripheral
Operation
[ Interrupt #n]

Request for
Peripheral
Operation
(SVC)

Wait ing (doing Peripheral # n)

M u l t ipr o g r a mmin g
Timin g D ia g r a m ( 3 Us er Pr o g r a ms )

P1

Running

P2

Ready

P3

Ready

T1

Peripheral Operation

Runnin
g
Ready

T2

Peripheral Operation

Running

T3

Time

Multi Programmed System

Key Features
z Single CPU / Uni-processor system.
z Simultaneous existence of more than one user program in
memory.
z Established & Well Defined Peripheral usage protocol must
exist for each of the peripherals.
z Dedicated CALLs ( System Calls/ Software Interrupts) must
exist enabling any user program to utilize essential services, by
invoking any Peripheral Operation .
z Dedicated Peripheral Interfaces (I/O Channels ) must exist for
each of the peripherals.
z Device Driver / I/O Channel Programs for each & every type of
peripherals must exist along with exclusive Supervisor Mode
accessibility.
z Existence of Hardware / Device Interrupt mechanism is a must.

Multi -programming / Shortcomings

1. New user program /process gets to execute /
allocated CPU provided the currently running
process releases the CPU due to Peripheral
request.
2. Such voluntary CPU release skews in favour of
the User Process that gets the CPU first.
3. Processes coming in later on may starve
thereby affecting their Response Time.
Hence one way to overcome this is to increase
resource by incorporating several instances of
the processor itself.

M u l t i Pr o c es s in g I ( St a t e
D ia g r a m)
z Several User pr oc esses
z Several CPU / CPU Cores with Identical Func tionality.

ed
d/
e
l
u
d
Sche
Scheduled / Dispatched

Centralized O.S. & Global Memor y. Dispatch

Global
Ready Queue

Sch edu
led / Dis
pa

CPU / Core #1

CPU/ Core # J

tched

CPU/ Core #N
Peripheral Over
(H/W Interrupt) Peripheral
WAIT Queue
Peripheral Over
(H/W Interrupt)

Peripheral request
(SVC)

Peripheral Request (SVC)

Peripheral Request (SVC)

Multiprocessing - II
( Timing Diagram for 2 CPUs / 2 Cores )
P1

Running on CPU1

P2

Running on CPU2

P3

Ready

Doing I/O
Doing I/O

Running on CPU 1 / CPU 2

Running on CPU 1 / CPU 2

Exit
Running on CPU2

Time

Multi Processing Problems

1. Requires more than one processor unit/core.
2. All managed by Common Operating System
and share same Memory ( Tightly Coupled
System).
3. Synchronization & management overhead
increases since it involves allocating User tasks
to each of the existing Processors whenever it
becomes Free.
4. Achieving Load Balance among the various
processors is difficult.

Multi Processing Multi-Tasking

1. CPU speed is much higher than the Real
World clock.
2. Single CPU core can be used to handle
multiple user tasks with not much
degradation in response time.
3. Share the time of one CPU core among
several processes i.e. Concurrently
running several processes each within its
pre-fixed Time Slice.

Multitasking ( State Diagram)

Dispatch the Selected Process (for allocated Time)

Ready Queue
Of Processes

Time Out
( After Pre-fixed Interval)

Running

Event Takes Place

(Interrupt)

Request for
Peripheral / Wait for Event # 1
Request for
Peripheral / Wait for Event #n

Event Takes Place

(Interrupt)

Wait / BLOCKED for Event # 1

Wait / BLOCKED for Event # n

Multitasking (Timing Diagram)

Running

Doing I/O

Running

P1
Ready

Running

Time Out

Running

Time Out

P2
Runnin
g

Ready
P3

T1

T2

Time Out

Doing I/O

T3

M u l t i Ta s k in g
( Sa l ien t F ea t u r es )
z Eliminates / Minimizes CPU waiting time / process in order to
give guaranteed response time to each user process lying in
the READY Queue.
z Eliminates need for multiple CPUs.
z Round Robin / Time shared scheduling of tasks/processes
to a single CPU . ( Co-Operative / Pre_Emptive).
z Each process is granted a prefixed Time Slice based on a
prefixed policy. After using CPU for that prefixed Time Period ,
the concerned process either voluntarily yields the CPU to other
processes [ Co-Operative] or is preempted through a internally
generated Timer Interrupt.
z Existence of a dedicated Hardware Interval Timer which is
initialized by the O.S. in addition to all the features of any Multi
programmed System is necessary.

Multi Threading
1. Thread is the basic Execution unit.
2. Threads share among themselves address space [ global
variables+ code], peripherals [ NOT CONCURRENTLY] .
3. Each thread has got its own set of Registers and Stack.
4. Sharing a CPU among several peer threads of the same
process OR among peer threads of different User
Processes in a Time Shared Fashion.
5. Whenever the currently running thread becomes BLOCKED /
goes to WAIT state some other thread is scheduled for
execution .
6. Multi Threading hence represents a very fine grain multi
tasking at the level of a very few instructions thereby
permitting FAST SWITCHING among them.

Multithreading ( State Diagram)

Dispatch one Thread of the Selected Process (for allocated Time)

Ready Queue
of Threads ?

Time Out
( After Pre-fixed Interval)

Running

Event Takes Place

(Interrupt)

Request for
Peripheral / Wait for Event # 1
Request for
Peripheral / Wait for Event #n

Event Takes Place

(Interrupt)

Wait / BLOCKED for Event # 1

Wait / BLOCKED for Event # n

Hyper Threading
1.
2.
3.
4.

Existence of several identical CPU cores.

Governed by single O.S.
Shared Memory.
Threads are allocated to a Core whenever it
is free.
5. Time Slice allocated to a Thread is CPU
core independent.
6. It aims to mimic Symmetric Multi Processing
by allocating separate CPU Cores to
execute separate threads.
7. Symmetric Multi Threading .

H y per Th r ea d in g ( St a t e D ia g r a m)
z Several thr eads
z Several identical CPU Cores

CPU / Core #1
ed
/
d
e
l
u
d
e
TIMED
OUT
h
c
S
Scheduled / Dispatched
CPU/ Core # J

tch
Centralized O.S. & Some Global l Memor
Dispa y.

Ready Queue
Of THREADS ?

Sch edu
led / DisTIMED OUT
patched

CPU/ Core #N
TIMED OUT
Peripheral Over
(H/W Interrupt) Peripheral
WAIT Queue
Peripheral Over
(H/W Interrupt)

Peripheral request
(SVC)

Peripheral Request (SVC)

Peripheral Request (SVC)

Preferred Process Mgt Strategy

for Embedded Applications

z Multi Threading because of the following

reasons :
1) Uni- Processor System.
2) Basic Schedulable & Executable entity
happens to be the Thread which allows
Fast Context Switching that helps in
satisfying Deadlines.

Various Aspects of RTOS 3

Scheduling Strategies
1. First in First out ( FIFO ) with pre Fixed Static
Priority Classes. [ Priority Inversion may
happen (to be discussed later)].
2. Earliest Deadline First ( EDF) : Allows dynamic
assignment of Priorities based on the Thread
whose Deadline is nearest. The most suitable
for Embedded Applications.
3. Sporadic Server : Useful for handling sporadic
Events only depends on the Execution
Capacity & Replenishment period of each
Thread.

Various Aspects of RTOS 4

Synchronization & Inter process Communication

1. Semaphores : Requires low level System

Supported Synchronization Primitives. Works
on the principle of Shared Memory.
2. M onit ors : High Level Synchronization
Primitives based on Shared Memory.
3. M essage Passing : Supports explicit Data
Transfer through SEND & RECEIVE primitives
and do not require shared Memory Structure.
Message Passing is most Suitable.

Various Aspects of RTOS 5

Network Support & Other Features
1. Socket Paradigm: Supported by the
POSIX ( Portable Operating System
Interface for Computing Environments)
supports uniform way of communication.
2. Application Programming Interface
( API) : Less general than socket based
but more rich & efficient.
In M icro Kernel Based Design API is most
Suitable.

Case Studies
A. Mars Pathfinder ( A Classic Case of
Priority Inversion).
B. Symbian Operating System used in
Mobile Phones.

The Spacecraft : Mars Pathfinder

This mission was accomplished in July 4, 1997 with its landing on the
Maritan Surface. The mission includes the following :
1) Unconventional landing ( bouncing onto the Maritan surface surrounded by
Air Bags) .
2) Deploying the Sojourner Rover.
3) Gathering and Transmitting Voluminous data back to Earth Stations that
included Meteorological Data as well as Photographs.
The Fault : The Spacecraft began experiencing Total Syste m Re se ts , each
resulting in a loss of Data.
The Embedded Kernel used inside Mars Pathfinder was VxWorks ,
developed by Wind River Systems.

Mars Pathfinder & VxWorks

The Inside Story
1.

Each of the Tasks carried out by the Space Craft was treated as a Thread with
pre-fixed static priority.
2.
VxWorks provides pre-emptive priority based scheduling of these threads.
3.
The Pathfinder contained an information bus which can be thought of as a
shared memory area used for passing information between its different
components.
4.
Access to this piece of shared memory was controlled by mutual exclusion locks
(Semaphores).
5.
A Bus Management task ran frequently with high priority to move certain kinds of
data in and out of this shared information Bus.
6.
Meteorological Data Gathering was a low priority thread while the communications
task having medium priority.
7.
If at any point of time , albeit infrequently, any of the lower priority threads holds
the shared information bus thereby forcing the high priority Bus Management
task to WAIT for more than a predefined period a time out signal from a watchdog
timer will cause system reset.
Solution : Allow the low priority thread currently using the BUS to INHERIT the
high priority of the Blocked process for the time being to prevent the
WATCHDOG TIMER to go off.

Symbian Operating System

z Symbian OS is an operating system, designed
for mobile devices, with associated libraries,
user interface frameworks and reference
implementations of common tools, produced by
Symbian Ltd. It is a descendant of Psion's EPOC
and runs exclusively on ARM processors.
z Symbian is currently owned by Ericsson
(15.6%), Nokia (47.9%), Panasonic (10.5%),
Samsung (4.5%), Siemens AG (8.4%), and Sony
Ericsson (13.1%).

Symbian Operating System for Mobile Phones

( The Primary Motivational Factors )
1.
2.
3.
4.
5.
6.

7.

Mobile phones are both small and mobile .

Mobile phones are ubiquitous they target a mass-market of consumer,
enterprise and professional users.
Mobile phones are occasionally connected they can be used when
connected to the wireless phone network, locally to other devices, or on
their own.
Manufacturers need to differentiate their products in order to innovate
and compete in a fast-evolving market .
The platform has to be open to enable independent technology and
software vendors to develop third-party applications, technologies and
services.
Reliability is a major issue for mass-market phones. Data loss in a
personal mobile phone causes a loss of trust between the user and the
phone. A mobile phone therefore must be at least as resilient as paper
diaries and agendas.
Even though nobody can guarantee bug-free software, a good operating
system can make it much easier to write robust and reliable applications.

Symbian Operating System

Key Features
1.

2.

3.
4.

It is a 32 bit multitasking operating system wherein

events often happen asynchronously and applications
are designed to interact with one another.
It includes a file system, a graphical user interface
framework, multimedia support, a TCP/IP stack and
libraries for all the communication features found on
smart phones.
Symbian OS has software development kits available
for third-party application development.
The hardware layers of the operating system are
abstracted, so that phone manufacturers can port the
OS to the specific requirements of their phone.

Symbian Operating System

Overview

Symbian Operating System

The Kernel (EKA 2)

The Symbian Kernel (EKA 2)

Distinctive Features
1. Second Iteration of Symbians 32 bit
kernel Architecture.
2. It is able to run full Telephone Signalling
stacks.
3. It allows many Threads easing up tasks
of writing Device drivers that involve
complex state machines.
4. The HAL provides a generic hardware
Independent API to the KERNEL.

Symbian ( User vs. KERNEL)

Symbian O.S.
[ Client Server Model ]

Symbian O.S.
[ Communication Architecture ]

References
1.
2.
3.
4.

The Embedded Systems Handbook.

Real Time Systems by Prof. Rajiv Mall.
Prof. P.S.Deys Lecture Slides.
The Term Paper submitted by M.Tech.
Students.