IT18_RTOS

Real Time Operating System

ASeminar Report

OnREAL TIME OPERATING SYSTEM

SUBMITTED BY:THANKI BHARGAV A.

ENROLLMENT NO: 100830116018

Under the Guidance ofProf. Taruna R. Shyara

DEPARTMENT OF INFORMATION TECHNOLOGY

DR. SUBHASH TECHNICAL CAMPUS, JUNAGADH

OCTOBER – 2012

Department of IT, Dr. STC - Junagadh 1


CERTIFICATE

Enrollment No: 100830116018

This is to certify that the practical work

satisfactorily carried out and hence recorded

in this journal is the bonafide work of

Mr./Miss Thanki Bhargav A. students of

Computer Science and Engineering/

Information Technology Sem 5 th in the

150705 – Seminar Laboratory of Dr. Subhash

Technical Campus during the academic year

2012.

Submission Date: 29-Oct-2012



Subject Principal Incharge



ACKNOWLEDGEMENT:

First of all, I am grateful to The Almighty God for establishing me to complete the

seminar.

I wish to express my sincere thanks to Dr. S.T.Rajan Sir, Principal of the college, for

providing me with all the necessary facilities.

I place on record, my sincere gratitude to Prof. Taruna R. Shyara, HOD & Dean

Administrative , Department of Information Technology, for his constant encouragement.

I am extremely grateful and indepted to Prof.Taruna.R.Shyara for her expert, sincere

and valuable guidance and encouragement extended to me.

I take this opportunity to record our sincere thanks to all the faculty members of the

I.T. Department for their help and encouragement.

I also place on record, my sense of gratitude to one and all who, directly or indirectly,

have lent their helping hand in this venture.

- Thanki Bhargav A.



ABSTRACT

A real-time operating system (RTOS) is an operating system (OS) intended for

real-time applications. Such operating systems serve application requests nearly real-

time. A real-time operating system offers programmers more control over process

priorities. ...

Real time Operating System is the key to many embedded systems and

provides a platform to built application.

The heart of this embedded systems are real time operating system.

The real time operating system differ from the general purpose operating

system in terms of timing behavior , output and in terms of application as well.

Based on the degree of tolerance in meeting deadlines Real Time Operating

System is classified into 3 categories :

1. Hard Real Time Operating System.

2. Firm Real Time Operating System. And

3. Soft Real Time Operating System.

The features of Real Time Operating System are Multithreading and

Preemptivity, Task priority, Priority inheritance , control memory management , etc.

The Architecture of Real Time Operating System includes Kernal , Task

management, Schedular, Dispatcher, Task Syncronization, etc.

The Real Time Operating System is used in control of TV and washing

machine, control of automobile engine, air conditioners , control of flights etc.



INDEX

SR.NO DETAILS PAGE NO

1 Introduction 7

2 Difference: RTOS v/s General Purpose OS 8

3 RTOS Classification 9

4 Features of RTOS 10

5 RTOS Architecture 12

6 Application of RTOS 21

7 Conclusion 21

8 Scope of future work 22

9 References 23



List of Figure

Sr. No Name of Figure Page No

1 Figure 1 – Real time embedded system with RTOS 8

2 Figure 2 – General Architecture of RTOS 12

3 Figure 3 – RTOS Kernal Services 14

4 Figure 4 – Typical Task Control Block(TCB) 15

5 Figure 5 – Possible state transition of Task 16

6 Figure 6 – Non preemptive Scheduling 17

7 Figure 7 – Preemptive Scheduling 17



1.INTRODUCTON :

Suppose a person is driving a car on a highway at a speed of 70 miles per hour. Now,

somehow the car meets with an accident. Fortunately the airbag deployed at the right time

and saved the life of the driver.

So, we see that airbag is a very good feature in a car which can save a life someday.

But, did we think what would have happened if the airbag would have deployed a few

seconds late? Yes, we would have lost a life. So just imagine the dependency on the accuracy

of opening of the airbag.

So, what makes that airbag deploy at the right time? Well, welcome to the world of

RTOS

RTOS stands for Real time operating systems.

A Real-Time Operating System (RTOS) comprises of two components, viz., “Real-

Time” and “Operating System”.

An Operating system (OS) is nothing but a collection of system calls or functions

which provides an interface between hardware and application programs. It manages the

hardware resources of a computer and hosting applications that run on the computer. An OS

typically provides multitasking, synchronization, Interrupt and Event Handling, Input/

Output, Inter-task Communication, Timers and Clocks and Memory Management. Core of

the OS is the Kernel which is typically a small, highly optimised set of libraries.

Real-time systems are those systems in which the correctness of the system depends

not only on the logical result of computation, but also on the time at which the results are

produced.

RTOS is therefore an operating system that supports real-time applications by

providing logically correct result within the deadline required. Basic Structure is similar to

regular OS but, in addition, it provides mechanisms to allow real time scheduling of tasks.



Though real-time operating systems may or may not increase the speed of execution,

they can provide much more precise and predictable timing characteristics than general-

purpose OS.

In modern times we have seen an evolution of embedded systems. Nowadays

embedded systems can be found all around us. Be it on cellphones, air conditioners, digital

homes, cars etc. Little we realize their contribution in making our life comfortable and safe.

Safety is one aspect in which we are now depending more and more on these computerized

embedded systems. The heart of these systems is the OS they use. Most of these systems use

RTOS.

RTOS is key to many embedded systems and provides a platform to build

applications. All embedded systems are not designed with RTOS. Embedded systems with

relatively simple/small hardware/code might not require an RTOS. Embedded systems with

moderate-to-large software applications require some form of scheduling, and hence RTOS.

2.DIFFERENCE: RTOS v/s GENERAL PURPOSE OS:

Determinism:

The key difference between general-computing operating systems and real-time

operating systems is the “deterministic " timing behavior in the real-time operating systems.

"Deterministic" timing means that OS consume only known and expected amounts of time.

RTOS have their worst case latency defined. Latency is not of a concern for General Purpose

OS.



Task scheduling:

General purpose operating systems are optimized to run a variety of applications and

processes simultaneously, thereby ensuring that all tasks receive at least some processing

time. As a consequence, low-priority tasks may have their priority boosted above other higher

priority tasks, which the designer may not want. However, RTOS uses priority-based

preemptive scheduling, which allows high-priority threads to meet their deadlines

consistently. All system calls are deterministic, implying time bounded operation for all

operations and ISRs. This is important for embedded systems where delay could cause a

safety hazard. The scheduling in RTOS is time based. In case of General purpose OS, like

Windows/Linux, scheduling is process based.

Preemptive kernel :

In RTOS, all kernel operations are preemptible

Priority inversion :

RTOS have mechanisms to prevent priority inversion

Usage :

RTOS are typically used for embedded applications, while General Purpose OS are

used for Desktop PCs or other generally purpose PCs.

3.RTOS CLASSIFICATION :

RTOS specifies a known maximum time for each of the operations that it performs.

Based upon the degree of tolerance in meeting deadlines, RTOS are classified into following

categories :

1. Hard real-time

2. Firm real-time

3. Soft real-time



1.Hard Real Time Operating System :

These type of RTOS strictly adhere to the deadline associated with the tasks. Missing

on a deadline can have catastrophic affects. The air-bag example we discussed in the

beginning of this article is example of a hard RTOS as missing a deadline there could cause a

life.

2.Firm Real Time Operating System :

These type of RTOS are also required to adhere to the deadlines because missing a

deadline may not cause a catastrophic affect but could cause undesired affects, like a huge

reduction in quality of a product which is highly undesired.

3.Soft Real Time Operating System :

In these type of RTOS, missing a deadline is acceptable. For example On-line

Databases.

For a life saving device, automatic parachute opening device for skydivers, delay can

be fatal. Parachute opening device deploys the parachute at a specific altitude based on

various conditions. If it fails to respond in specified time, parachute may not get deployed at

all leading to casualty. Similar situation exists during inflation of air bags, used in cars, at the

time of accident. If airbags don’t get inflated at appropriate time, it may be fatal for a driver.

So such systems must be hard real time systems, whereas for TV live broadcast, delay can be

acceptable. In such cases, soft real time systems can be used.

4.FEATURES OF RTOS :

The design of an RTOS is essentially a balance between providing a reasonably rich

feature set for application development and deployment and, not sacrificing predictability and

timeliness. A basic RTOS will be equipped with the following features :

i.Multitasking and Preemptibility :

An RTOS must be multi-tasked and preemptible to support multiple tasks in real-

time applications. The scheduler should be able to preempt any task in the system and

allocate the resource to the task that needs it most even at peak load.



ii. Task Priority :

Preemption defines the capability to identify the task that needs a resource the most

and allocates it the control to obtain the resource. In RTOS, such capability is achieved by

assigning individual task with the appropriate priority level. Thus,

it is important for RTOS to be equipped with this feature.

iii. Reliable and Sufficient Inter Task Communication

Mechanism:

For Multiple tasks to communicate in a timely manner and to ensure data integrity

among each other, reliable and sufficient inter-task communication and synchronization

mechanisms are required.

iv. Priority Inheritance:

To allow applications with stringent priority requirements to be implemented, RTOS

must have a sufficient number of priority levels when using priority scheduling.

v. Predefined Short Latencies:

An RTOS needs to have accurately defined short timing of its system calls. The

behavior metrics are:

• Task switching latency: The time needed to save the context of a currently

executing task and switching to another task is desirable to be short.

• Interrupt latency: The time elapsed between execution of the last instruction of

the interrupted task and the first instruction in the interrupt handler.

• Interrupt dispatch latency: The time from the last instruction in the interrupt

handler to the next task scheduled to run.

vi. Control of Memory Management:

To ensure predictable response to an interrupt, an RTOS should provide way for task

to lock its code and data into real memory.



4.RTOS ARCHITECTURE:

The architecture of an RTOS is dependent on the complexity of its deployment.

Good RTOSs are scalable to meet different sets of requirements for different applications.

For simple applications, an RTOS usually comprises only a kernel. For more complex

embedded systems, an RTOS can be a combination of various modules, including the kernel,

networking protocol stacks, and other components as illustrated in Figure.

Fig2.General Architecture of RTOS

a).Kernel :

An operating system generally consists of two parts: kernel space (kernel mode) and

user space (user mode). Kernel is the smallest and central component of an operating system.

Its services include managing memory and devices and also to provide an interface for

software applications to use the resources. Additional services such as managing protection

of programs and multitasking may be included depending on architecture of operating

system. There are three broad categories of kernel models available, namely:



i.Monolithic kernel :

It runs all basic system services (i.e. process and memory management, interrupt

handling and I/O communication, file system, etc) in kernel space. As such, monolithic

kernels provide rich and powerful abstractions of the underlying hardware. Amount of

context switches and messaging involved are greatly reduced which makes it run faster than

microkernel. Examples are Linux and Windows.

ii. Microkernel :

It runs only basic process communication (messaging) and I/O control. The other

system services (file system, networking, etc) reside in user space in the form of

daemons/servers. Thus, micro kernels provide a smaller set of simple hardware abstractions.

It is more stable than monolithic as the kernel is unaffected even if the servers failed (i.e. File

System). Examples are AmigaOS and QNX.

iii.Exokernel :

The concept is orthogonal to that of micro- vs. monolithic kernels by giving an

application efficient control over hardware. It runs only services protecting the resources (i.e.

tracking the ownership, guarding the usage, revoking access to resources, etc) by providing

low-level interface for library operating systems (libOSes) and leaving the management to the

application.

An RTOS generally avoids implementing the kernel as a large monolithic program.

The kernel is developed instead as a micro-kernel with added configurable functionalities.

This implementation gives resulting benefit in increase system configurability, as each

embedded application requires a specific set of system services with respect to its

characteristics. The kernel of an RTOS provides an abstraction layer between the application

software and hardware. This abstraction layer comprises of six main types of common

services provided by the kernel to the application software. Figure shows the six common

services of an RTOS kernel.



Fig3. RTOS Kernel Services

b).Task Management :

Task management allows programmers to design their software as a number of

separate “chunks” of codes with each handling a distinct goal and deadline. This service

encompasses mechanism such as scheduler and dispatcher that creates and maintain task

objects.

i.Task Object :



To achieve concurrency in real-time application program, the application is

decompose into small, schedulable, and sequential program units known as “Task”. In real-

time context, task is the basic unit of execution and is governed by three time-critical

properties; release time, deadline and execution time. Release time refers to the point in time

from which the task can be executed. Deadline is the point in time by which the task must

complete. Execution time denotes the time the task takes to execute.

A task object is defined by the following set of components:

• Task Control block (Task data structures residing in RAM and only accessible by RTOS)

• Task Stack (Data defined in program residing in RAM and accessible by stack pointer)

• Task Routine (Program code residing in ROM)

Fig4.Typical Task Control Block(TCB)

Each task may exist in any of the four states, including running, ready, or blocked and

dormant as shown in Figure. During the execution of an application program, individual tasks

are continuously changing from one state to another. However, only one task is in the running

mode (i.e. given CPU control) at any point of the execution. In the process where CPU

control is change from one task to another, context of the to-be-suspended task will be saved

while context of the to-be-executed task will be retrieved. This process of saving the context

of a task being suspended and restoring the context of a task being resumed is called context

switching.



Fig5. Possible States Transition of Tasks

c).Scheduler :

The scheduler keeps record of the state of each task and selects from among them that

are ready to execute and allocates the CPU to one of them. A scheduler helps to maximize

CPU utilization among different tasks in a multi-tasking program and to minimize waiting

time. There are generally two types of schedulers: non-preemptive and priority-based

preemptive.

Non-preemptive scheduling or cooperative multitasking requires the tasks to

cooperate with each other to explicitly give up control of the processor. When a task releases

the control of the processor, the next most important task that is ready to run will be

executed. A task that is newly assigned with a higher priority will only gain control of the

processor when the current executing task voluntarily gives up the control. Figure 10 gives an

example of a non-preemptive scheduling



Fig6. Non-preemptive Scheduling

Priority-based preemptive scheduling requires control of the processor be given to the

task of the highest priority at all time. In the event that makes a higher priority task ready to

run, the current task is immediately suspended and the control of the processor is given to the

higher priority task. Figure 11 shows an example of a preemptive scheduling.

Fig7. Preemptive Scheduling

d). Dispatcher :

The dispatcher gives control of the CPU to the task selected by the scheduler by

performing context switching and changes the flow of execution. At any time an RTOS is

running, the flow of execution passes through one of three areas: through the task program

code, through an interrupt service routine, or through the kernel.



e).Task Synchronization & Intertask Communication :

Task synchronization and intertask communications serves to enable information to

be transmitted safely from one task to another. The service also makes it possible for tasks to

coordinate and cooperate with one another.

f).Task Synchronization :

Synchronization is essential for tasks to share mutually exclusive resources (devices,

buffers, etc) and/or allow multiple concurrent tasks to be executed (e.g. Task A needs a result

from task B, so task A can only run till task B produces it).

Task synchronization is achieved using two types of mechanisms; 1) Event Objects and 2)

Semaphores.

Event objects are used when task synchronization is required without resource

sharing. They allow one or more tasks to keep waiting for a specified event to occur. An

event object can exist in either of two states: triggered and non-triggered.

An event object in a triggered state indicates that a waiting task may resume. In

contrast, if the event object is in a nontriggered state, a waiting task will need to stay

suspended.

Sharing of resource among tasks can be a problem when the coordination is not well

done. For instance, if task A begins reading a set of data currently being updated by task B,

task A might received corrupted data – mixture of new and existing data. To resolve this

problem, RTOS kernels provide a semaphore object and associated semaphore services to

ensure the integrity of data.

A semaphore has an associated resource count and a wait queue. The resource count

indicates availability of resource.

The wait queue manages the tasks waiting for resources from the semaphore. A

semaphore functions like a key that define whether a task has the access to the resource. A

task gets an access to the resource when it acquires the semaphore. The resource count of a

semaphore determines the number of times the semaphore can be acquired. When a task

acquires the semaphore, its count decrement by one. Likewise, its count increment by one

when a task releases the semaphore. Generally, There are three types of semaphore:

• Binary Semaphores (semaphore value of either 0 or 1 to indicate unavailability and

availability respectively)

• Counting Semaphores (semaphore value of 0 or greater indicating it can be

acquired/released multiple times)



• Mutually Exclusion Semaphores (semaphore value of 0 or 1 but lock count can be 0

or greater for recursive locking)

g).Intertask Communication :

Intertask communication involves sharing of data among tasks through sharing of

memory space, transmission of data and etc. Few of mechanisms available for executing

intertask communications includes:

• Message queues

• Pipes

• Remote procedural calls (RPC)

A message queue is an object used for intertask communication through which task

send or receive messages placed in a shared memory. Tasks and ISRs send and receive

messages to the queue through services provided by the kernel. A task seeking for a message

from an empty queue is blocked either for a duration or until a message is received. The

sending and receiving of messages to and from the queue may follow 1) First In First Out

(FIFO), 2) Last in First Out (LIFO) or 3) Priority (PRI) sequence. Usually, a message queue

comprises of an associated queue control block (QCB), name, unique ID, memory buffers,

queue length, maximum message length and one or more task waiting lists. A message queue

with a length of 1 is commonly known as a mailbox.

A pipe is an object that provide simple communication channel used for unstructured

data exchange among tasks. A pipe can be opened, closed, written to and read from.

Traditionally, a pipe is a unidirectional data exchange facility. There are two descriptors

respectively at each end of the pipe for reading and writing. Data is written into the pipe as an

unstructured byte stream via one descriptor and read from the pipe in the FIFO order from the

other. Unlike message queue, a pipe does not store multiple messages but stream of bytes. In

addition, data flow from a pipe cannot be prioritized.

Remote procedure call (RPC) component permits distributed computing where task

can invoke the execution of an another task on a remote computer, as if the task ran on the

same computer.



h). Memory Management :

An embedded RTOS usually strive to achieve small footprint by including only the

functionality needed for the user’s applications. There are two types of memory management

in RTOSs. They are Stack and Heap managements.

In a multi-tasking RTOS, each task needs to be allocated with an amount of memory

for storing their contexts (i.e. volatile information such as registers contents, program

counter, etc) for context switching. This allocation of memory is done using task-control

block model. This set of memory is commonly known as kernel stack and the management

process termed Stack Management.

Upon the completion of a program initialization, physical memory of the MCU or

MPU will usually be occupied with program code, program data and system stack. The

remaining physical memory is called heap. This heap memory is typically used by the kernel

for dynamic memory allocation of data space for tasks. The memory is divided into fixed size

memory blocks, which can be requested by tasks. When a task finishes using a memory block

it must return it to the pool. This process of managing the heap memory is known as Heap

management.

i).Interrupt and Event Handling :

An interrupt is a hardware mechanism used to inform the CPU that an asynchronous

event has occurred. A fundamental challenge in RTOS design is supporting interrupts and

thereby allowing asynchronous access to internal RTOS data structures. The interrupt and

event handling mechanism of an RTOS provides the following functions:

• Defining interrupt handler

• Creation and deletion of ISR

• Referencing the state of an ISR

• Enabling and disabling of an interrupt

• Changing and referencing of an interrupt mask

and help to ensure:

• Data integrity by restricting interrupts from occurring when modifying a data

structure

• Minimum interrupt latencies due to disabling of interrupts when RTOS is

performing critical operations

• Fastest possible interrupt responses that marked the preemptive performance of an

RTOS



• Shortest possible interrupt completion time with minimum overheads.

j).Device I/O Management :

An RTOS kernel is often equipped with a device I/O management service to provide a

uniform framework (application programmer’s interface-“API”) and supervision facility for

an embedded system to organize and access large numbers of diverse hardware device

drivers. However, most device driver APIs and supervisors are “standard” only within a

specific RTOS.

6. APPLICATION OF RTOS:

1. Control of TV and Washing Machine.

2. Control of automobile engines.

3. Air conditioners.

4. Control of flights.

7. CONCLUSION :

Real time Operating systems play a major role in the field of embedded systems

especially for mission critical applications are involved. Selection of a particular RTOS for an

application can be made only after a thorough study of the features provided by the RTOS.

Since IC memories are getting denser scaled down versions of general operating systems are

able to compete with traditional Real Time Operating Systems for the embedded product

market. The choice of Operating System generally comes after the selection of the processor

and development tools. Every RTOS is associated with a finite set of microprocessors and a

suite of development tools.

Hence the first step in choosing an RTOS must be to make the processor, real-time

performance and the budget requirements clear. Then look at the available RTOS to identify

the one which suits our application.

Generally an RTOS for embedded application should have the following features

i) Open Source

ii) Portable

iii) ROM able

iv) Scalable

v) Pre-emptive



vi) Multi-tasking

vii) Deterministic

viii) Efficient Memory Management

ix) Rich in Services

x) Good Interrupt Management

xi) Robust and Reliable

Within the class of real-time embedded systems, the general feature is that system and

its application are fixed for the life of a product or the system. Thus there is a real need for a

general purpose architecture which would be flexible enough to meet the varied requirements

of these systems( wide range of sensors, threats, and scenarios ), but which would still be

dedicated and matched to an application through the use of special configurations of general

modules. Even though most of the current kernels (RTOS) are successfully used in todays

real-time embedded systems, but they increase the cost and reduce flexibility. Next

generation real-time operating systems would demand new operating systems and task

designs to support predictability, and high degree of adaptability.

8. SCOPE OF FUTURE WORK :

It is believed real-time computing will continue to grow in importance and affect an

increasing number of industries as many of the reasons for the rise of its prominence will

persist for the foreseeable future. Market forces mandate increasingly greater function and

lower cost in goods and services and thus manufacturers will increasingly utilize

microprocessor-based real- time control in both their end-products and in their processes to

stay competitive.

This will bring about new and growing requirements for real-time computing. The

emergence of multimedia computing and communications is leading to a fundamental

shift in perception of personal desktop systems from being primarily computation devices

to being primarily real-time communication and/or entertainment devices. On the one

hand, real-time systems solutions will be required for ensuring that these next generation

digital systems faithfully emulate their current (logically) analog counterparts. On the

other hand, the services provided by these systems will likely be metered and realized

through a distributed network of servers and service providers.



9. REFERENCES :

Publication :

• An Embedded Software Primer (David E. Simon)

• Real-Time Concepts for Embedded Systems (Qing Li with Caroline Yeo)

Website :

• EMBEDDED.COM, http://www.embedded.com.

www.wikipedia.com.

www.thegeekstuff.com.

www.engineersgarage.com.


http://www.engineersgarage.com/

http://www.thegeekstuff.com/

http://www.wikipedia.com/

http://www.embedded.com/

IT18_RTOS

Documents

Transcript of IT18_RTOS