A

Seminar Report On

M Y S EMINAR R EPORT T ITLE

Submitted By
Aditya Pujari - 132P001
Ankita Wadekar - 091P039
Manali Salunke - 081P017

Under the guidance of

Prof. Sonali Suryawanshi

Department of Computer Engineering

Rizvi College of Engineering
New Rizvi Educational Complex, Off-Carter Road,
Bandra(w), Mumbai - 400050

Affiliated to
University of Mumbai
 Rizvi College of Engineering
Department of Computer Engineering
New Rizvi Educational Complex, Off-Carter Road,
Bandra(w), Mumbai - 400050

CERTIFICATE
This is certify that

Aditya Pujari
Ankita Wadekar
Manali Salunke
of Third Year Computer Engineering have completed the seminar work entitled “Real Time Oper-
ating System” under my supervision at Rizvi College of Engineering, Mumbai under the University of
Mumbai.

Prof. Sonali Suryawanshi Prof. Dinesh B. Deore

Project Guide HOD, Computer Department

Internal Examiner External Examiner

Date:
 Acknowledgements

I am profoundly grateful to Prof.Sonali Suryawansh for his expert guidance and continuous encour-
agement throughout to see that this report rights its target since its commencement to its completion.

I would like to express deepest appreciation towards Dr. Varsha Shah, Principal RCOE, Mumbai and
Prof. Dinesh B. Deore HOD Computer Department whose invaluable guidance supported me in com-
pleting this report.

At last I must express my sincere heartfelt gratitude to all the staff members of Computer Engineering
Department who helped me directly or indirectly during this course of work.

Aditya Pujari
Ankita Wadekar
Manali Salunke
 ABSTRACT

A real-time operating system (RTOS) is an operating system capable of guaranteeing timing require-
ments of the processes under its control. While a time-sharing OS like UNIX strives to provide good
average performance, for a RTOS, correct timing is the key feature. Throughput is of secondary con-
cern. In order to deliver the tight worst-case timing performance needed by hard real-time, the RTOS
needs to be simple, small, predictable, and optimized to minimize the worst-case performance. Linux
operating system which started as a student project by Linus Travaldo gained momentum.in in late 80s
is now a complete operating system meeting requirements of nearly all type of users. Further large
group of developers are adding features to the core kernel as well as KLM (kernel loadable modules).
However indefinite response time, treatment of interrupts, scheduling policy and timer granularity are
some of the features of Linux which makes it unsuitable in embedded world where a definite response
time is a must. Several techniques and patches are available to customize and modify bare Linux kernel
to be acceptable as a hard real time operating system. This article discusses these issues.
This paper attempts to throw some light on the technologies behind the embedded systems design and
concludes by the survey of some of the available real-time operating systems.
 I NDEX

1 Introduction 1

2 What is a real-time System 2

3 Real-time Operating systems 3

3.1 Basic Requirements of an RTOS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Task Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 RT LINUX 7
4.1 IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 OBJECTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 CORE COMPONENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 FUNCTIONALITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5 KERNEL MODULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 THREADS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.7 RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Case Studies 12
5.1 QNX RTOS v6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 VRTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Windows CE 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4 pSOSystem/x86 2.2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5 VxWorks (Wind River Systems ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6 Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Conclusion 16

References 17

APPENDICES 17

A Project Hosting 18
List of Figures

4.1 Real Time Operating System Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1 QNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Windows CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 1 Introduction

Chapter 1

Introduction

Last few decades have seen the rise of computers to a position of prevalence in human affairs. It has
made its mark in every field ranging personal home affairs, business, process automation in industries,
communications, entertainment, defense etc.
An embedded system is a combination of hardware and software and perhaps other mechanical parts
designed to perform a specific function. Microwave oven is a good example of one such system. This
is in direct contrast to a personal computer. Though it is also comprised of hardware and software and
mechanical components it is not designed for a specific purpose. Personal computer is general purpose
and is able to do many different things.
A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time ap-
plication requests. It must be able to process data as it comes in, typically without buffering delays.
Processing time requirements (including any OS delay) are measured in tenths of seconds or shorter.
A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes
to accept and complete an application’s task; the variability is jitter. A hard real-time operating system
has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but
rather a guarantee of a soft or hard performance category. An RTOS that can usually or generally meet
a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.
An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-
system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow
set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread
switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than
for the amount of work it can perform in a given period of time.
The most common designs are:
Event-driven which switches tasks only when an event of higher priority needs servicing, called
preemptive priority, or priority scheduling. Time-sharing designs switch tasks on a regular clocked
interrupt, and on events, called round robin. Time sharing designs switch tasks more often than strictly
needed, but give smoother multitasking, giving the illusion that a process or user has sole use of a
machine.
Early CPU designs needed many cycles to switch tasks, during which the CPU could do nothing
else useful. For example, with a 20 MHz 68000 processor (typical of late 1980s), task switch times
are roughly 20 microseconds. (In contrast, a 100 MHz ARM CPU (from 2008) switches in less than
3 microseconds.)[4][5] Because of this, early OSes tried to minimize wasting CPU time by avoiding
unnecessary task switching.

Rizvi College of Engineering, Bandra, Mumbai. 1

Chapter 2 What is a real-time System

Chapter 2

What is a real-time System

A real-time system is one whose correctness involves both the logical correctness of outputs and their
timeliness. It must satisfy response-time constraints or risk severe consequences including failure. As
defined by Donald Gillies A real-time system is one in which the correctness of the computations not
only depends upon the logical correctness of the computation but also upon the time in which the result
is produced. If the timing constraints are not met, system failure is said to have occurred. These systems
respond to a series of external inputs, which arrive in an unpredictable fashion. The real-time systems
process these inputs, take appropriate decisions and also generate output necessary to control the periph-
erals connected to them. The design of a real-time system must specify the timing requirements of the
system and ensure that the system performance is both correct and timely. There are three types of time
constraints:
• Hard: A late response is incorrect and implies a system failure.
• Soft: Timeliness requirements are defined by using an average response time. If a single compu-
tation is late, it is not usually significant, although repeated late computation can result in system
failures.
• Firm: Firm real-time systems have hard deadlines, but where a certain low probability of missing
a deadline can be tolerated.
Most real-time systems interface with and control hardware directly. The software for such systems
is mostly custom-developed. Real-time Applications can be either embedded applications or non-
embedded (desktop) applications. Real-time systems often do not have standard peripherals associ-
ated with a desktop computer, namely the keyboard, mouse or conventional display monitors. In most
instances, real-time systems have a customized version of these devices.

Rizvi College of Engineering, Bandra, Mumbai. 2

Chapter 3 Real-time Operating systems

Chapter 3

Real-time Operating systems

Real-time computing is where system correctness not only depends on the correctness of logical result
but also on the result delivery time. So the operating system should have features to support this critical
requirement to render it to be termed a Real-time operating System (RTOS).
The RTOS should have predictable behavior to unpredictable external events. A good RTOS is one
that has a bounded (predictable) behavior under all system load scenario i.e. even under simultaneous
interrupts and thread execution. A true RTOS will be deterministic under all conditions. These operating
systems occupy little space from 10 KB to 100KB as compared to the General Operating systems which
take hundreds of megabytes.
We observe that the choice of an operating system is important in designing a real-time system.
Designing a real-time system involves choice of a proper language, task partitioning and merging, and
assigning priorities to manage response times. Depending upon scheduling objectives, parallelism and
communication may be balanced. Merging highly cohesive parallel tasks for sequential execution may
reduce overheads of context switches and inter-task communications.
The designer must determine critical tasks and assign them high priorities. However, care must be
taken to avoid starvation, which occurs when higher priority tasks are always ready to run, resulting in
insufficient processor time for lower priority tasks. Non-prioritized interrupts should be avoided if there
is a task that cannot be preempted without causing system failure. Ideally, the interrupt handler should
save the context, create a task that will service the interrupt, and return control to the operating system.
Using a task to perform bulk of the interrupt service allows the service to be performed based on
a priority chosen by the designer and helps preserve the priority system of the RTOS. Furthermore,
good response times may require small memory footprints in resource-impoverished systems. Clearly
the choice of an RTOS in the design process is important for support of priorities, interrupts, timers,
inter-task communication, synchronization, multiprocessing and memory management.

3.1 Basic Requirements of an RTOS:

The following are the basic requirements for an RTOS:
(i) Multi-tasking and preemptable: To support multiple tasks in real- time applications, an RTOS
must be multi-tasking and preemptable. The scheduler should be able to preempt any task in the system
and give the resource to the task that needs it most. An RTOS should also handle multiple levels of
interrupts to handle multiple priority levels.
(ii) Dynamic deadline identification: In order to achieve preemption, an RTOS should be able to
dynamically identify the task with the earliest deadline. To handle deadlines, deadline information may
be converted to priority levels that are used for resource allocation. Although such an approach is error
prone, nonetheless it is employed for lack of a better solution.

Rizvi College of Engineering, Bandra, Mumbai. 3

Chapter 3 Real-time Operating systems

(iii) Predictable synchronization: For multiple threads to communicate among themselves in a timely
fashion, predictable inter-task communication and synchronization mechanisms are required. Semantic
integrity as well as timeliness constitutes predictability. Predictable synchronization requires compro-
mises. Ability to lock/unlock resources is one of the ways to achieve data integrity.
(iv) Suficient Priority Levels: When using prioritized task scheduling, the RTOS must have a suffi-
cient number of priority levels, for effective implementation. Priority inversion occurs when a higher
priority task must wait on a lower priority task to release a resource and in turn the lower priority task
is waiting upon a medium priority task. Two workarounds in dealing with priority inversion, namely
priority inheritance and priority ceiling protocols (PCP), need sufficient priority levels. In a priority in-
heritance mechanism, a task blocking a higher priority task inherits the higher priority for the duration of
the blocked task. In PCP, a priority is associated with each resource which is one more than the priority
of its highest priority user. The scheduler makes the priority of the accessing task equal to that of the
resource. After a task releases a resource, its priority is returned to its original value. However, when a
tasks priority is increased to access a resource it should not have been waiting on another resource.
(v) Predefined latencies: The timing of system calls must be defined using the following specifica-
tions:
(a) Task switching latency or the time to save the context of a currently executing task and switch to
another.
(b)Interrupt latency or the time elapsed between the execution of the last instruction of the interrupted
task and the first instruction of the interrupt handler.
(c) Interrupt dispatch latency or the time to switch from the last instruction in the interrupt handler to
the next task scheduled to run.

3.2 Memory Management

An RTOS uses small memory size by including only the necessary functionality for an application
while discarding the rest. Below we discuss static and dynamic memory management in RTOSs. Static
memory management provides tasks with temporary data space. The systems free memory is divided
into a pool of fixed sized memory blocks, which can be requested by tasks. When a task finishes using
a memory block it must return it to the pool. Another way to provide temporary space for tasks is via
priorities. A pool of memory is dedicated to high priority tasks and another to low priority tasks. The
high-priority pool is sized to have the worst-case memory demand of the system. The low priority pool
is given the remaining free memory. If the low priority tasks exhaust the low priority memory pool, they
must wait for memory to be returned to the pool before further execution.
Dynamic memory management employs memory swapping, overlays, multiprogramming with a
fixed number of tasks (MFT), multiprogramming with a variable number of tasks (MVT) and demand
paging. Overlays allow programs larger than the available memory to be executed by partitioning the
code and swapping them from disk to memory.
In MFT, a fixed number of equalized code parts are in memory at the same time. As needed, the
parts are overlaid from disk. MVT is similar to MFT except that the size of the partition depends
on the needs of the program in MVT. Demand paging systems have fixed-size pages that reside in
non-contiguous memory, unlike those in MFT and MVT. In many embedded systems, the kernel and
application programs execute in the same space i.e., there is no memory protection.

Rizvi College of Engineering, Bandra, Mumbai. 4

Chapter 3 Real-time Operating systems

3.3 Task Scheduling

This section discusses scheduling algorithms employed in real-time operating systems. We note that
predictability requires bounded operating system primitives. A feasibility analysis of the schedule may
be possible in some instances.
Task scheduling can be either performed preemptively or nonpreemptively and either statically or
dynamically. For small applications, task execution times can be estimated prior to execution and the
preliminary task schedules statically determined. Two common constraints in scheduling are the re-
source requirements and the precedence of execution of the tasks.
Typical parameters associated with tasks are:
Average execution time
Worst case execution time
Dispatch costs
Arrival time
Period (for periodic tasks).
The objective of scheduling is to minimize or maximize certain objectives. Typical objectives mini-
mized are: schedule-length and average tardiness or laxity. Alternatively, maximizing average earliness
and number of arrivals that meet deadlines can be objectives. Scheduling approaches have been clas-
sified into: static table driven approach, static priority driven preemptive approach, dynamic planning
based approach, dynamic best effort approach, scheduling with fault tolerance and resource reclaiming.
These are briefly discussed below:

Static table driven: The feasibility and schedule are determined statically. A common example is the
cyclic executive, which is also used in many large-scale dynamic real-time systems. It assigns tasks to
periodic time slots. Within each period, tasks are dispatched according to a table that lists the order to
execute tasks. For periodic tasks, there exists a feasible schedule if and only if there is a feasible sched-
ule within the least common multiple of the periods. A disadvantage of this approach is that a-priori
knowledge of the maximum requirements of tasks in each cycle is necessary. Static priority driven pre-
emptive: The feasibility analysis is conducted statically. Tasks are dispatched dynamically based upon
priorities. The most commonly used static priority driven preemptive scheduling algorithm for periodic
tasks is the Rate Monotonic (RM) scheduling algorithm.
A periodic system must respond with an output before the next input. Therefore, the systems re-
sponse time should be shorter than the minimum time between successive inputs. RM assigns priorities
proportional to the frequency of tasks. It can schedule any set of tasks to meet deadlines if the total
resource utilization less than ln 2. If it cannot find a schedule, no other fixed-priority scheduling scheme
will. But it provides no support for dynamically changing taskpriority-inversion may occur when to en-
force rate-monotonicity, a noncritical task of higher frequency of execution is assigned a higher priority
than a critical task of lower frequency of execution.
Dynamic planning based: The feasibility analysis is conducted dynamicallyan arriving task is ac-
cepted for execution only when feasible. The feasibility analysis is also a source for schedules. The
execution of a task is guaranteed by knowing its worst-case execution time and faults in the system.
Tasks are dispatched to sites by brokering resources in a centralized fashion or via bids. A technique
using both centralized and bidding-approach performs marginally better than any one of them but is
more complex.
Dynamic best effort approach: Here no feasibility check is performed. A best effort is made to meet
deadlines and tasks may be aborted. However, the approaches of Earliest Deadline First (EDF) and
Minimum Laxity First (MLF) are often optimal when there are no overloads. Research into overloaded

Rizvi College of Engineering, Bandra, Mumbai. 5

Chapter 3 Real-time Operating systems

conditions is still in its infancy. Earliest deadline first (EDF) scheduling can schedule both static and
dynamic real-time systems. Feasibility analysis for EDF can be performed in O(n2) time, where n is the
number of tasks. Unlike EDF, MLF accounts for task execution times.
Scheduling with fault tolerance: A primary schedule will run by the deadline if there is no failure and
a secondary schedule will run by the deadline on failure. Such a technique allows graceful degradation
but incurs cost of running another schedule. In hard real-time systems, worst-case blocking must be
minimized for fault tolerance.
Scheduling with resource reclaiming: The actual task execution time may be shorter than the one
determined a-priori because of conditionals or worst-case execution assumptions. The task dispatcher
may try to reclaim such slacks, to the benefit of non real-time tasks or improved timeliness guarantees.

Rizvi College of Engineering, Bandra, Mumbai. 6

Chapter 4 RT LINUX

Chapter 4

RT LINUX

RTLinux is a hard realtime RTOS microkernel that runs the entire Linux operating system as a fully pre-
emptive process. It is one of the hard real-time variants of Linux, among several, that makes it possible
to control robots, data acquisition systems, manufacturing plants, and other time-sensitive instruments
and machines.
It was developed by Victor Yodaiken, Michael Barabanov, Cort Dougan and others at the New Mexico
Institute of Mining and Technology and then as a commercial product at FSMLabs. Wind River Systems
acquired FSMLabs embedded technology in February 2007 and made a version available as Wind River
Real-Time Core for Wind River Linux. As of August 2011, Wind River has discontinued the Wind River
Real-Time Core product line, effectively ending commercial support for the RTLinux product.
The key RTLinux design objective was to add hard real-time capabilities to a commodity operat-
ing system to facilitate the development of complex control programs with both capabilities.[1][2] For
example, one might want to develop a real-time motor controller that used a commodity database and
exported a web operator interface. Instead of attempting to build a single operating system that could
support real-time and non-real-time capabilities, RTLinux was designed to share a computing device
between a real-time and non-real-time operating system so that (1) the real-time operating system could
never be blocked from execution by the non-real-time operating system and (2) components running in
the two different environments could easily share data. As the name implies RTLinux was the first com-
puter designed to use Linux as the non-real-time system[3] but it eventually evolved so that the RTCore
real-time kernel could run with either Linux or BSD UNIX.
Multi-Environment Real-Time (MERT) was the first example of a real-time operating system coex-
isting with a UNIX system. MERT relied on traditional virtualization techniques: the real-time kernel
was the host operating system (or hypervisor) and Bell Systems UNIX was the guest. RTLinux was an
attempt to update the MERT concept to the PC era and commodity hardware. It was also an attempt to
also overcome the performance limits of MERT, particularly the overhead introduced by virtualization.
The technique used was to only virtualize the guest interrupt control. This method allowed the real-time
kernel to convert the guest operating system into a system that was completely preemptible but that could
still directly control, for example, storage devices. In particular, standard drivers for the guest worked
without source modification although they needed to be recompiled to use the virtualization ”hooks”.
See also paravirtualization. The UNIX ”pipe” was adapted to permit real-time and non-real-time pro-
grams to communicate although other methods such as shared memory were also added.
From the programmer’s point of view, RTLinux originally looked like a small threaded environment
for real-time tasks plus the standard Linux environment for everything else. The real-time operating
system was implemented as a loadable kernel module which began by virtualizing guest interrupt control
and then started a real-time scheduler. Tasks were assigned static priorities and scheduling was originally
purely priority driven. The guest operating system was incorporated as the lowest priority task and
essentially acted as the idle task for the real-time system. Real-time tasks ran in kernel mode. Later

Rizvi College of Engineering, Bandra, Mumbai. 7

Chapter 4 RT LINUX

development of RTLinux adopted the POSIX threads application programming interface (API) and then
permitted creation of threads in user mode with real-time threads running inside guest processes. In
multiprocessor environments threads were locked to processor cores and it was possible to prevent the
guest thread from running on designated core (effectively reserving cores for only real-time processing).

4.1 IMPLEMENTATION
RTLinux provides the capability of running special real-time tasks and interrupt handlers on the same
machine as standard Linux. These tasks and handlers execute when they need to execute no matter
what Linux is doing. The worst case time between the moment a hardware interrupt is detected by the
processor and the moment an interrupt handler starts to execute is under 15 microseconds on RTLinux
running on a generic x86 (circa 2000). A RTLinux periodic task runs within 25 microseconds of its
scheduled time on the same hardware. These times are hardware limited, and as hardware improves
RTLinux will also improve. Standard Linux has excellent average performance and can even provide
millisecond level scheduling precision for tasks using the POSIX soft real-time capabilities. Standard
Linux is not, however, designed to provide sub-millisecond precision and reliable timing guarantees.
RTLinux was based on a lightweight virtual machine where the Linux ”guest” was given a virtualized
interrupt controller and timer, and all other hardware access was direct. From the point of view of
the real-time ”host”, the Linux kernel is a thread. Interrupts needed for deterministic processing are
processed by the real-time core, while other interrupts are forwarded to Linux, which runs at a lower
priority than real-time threads. Linux drivers handle almost all I/O. First-In-First-Out pipes (FIFOs) or
shared memory can be used to share data between the operating system and RTLinux.

4.2 OBJECTIVE
The key RTLinux design objective is that the system should be transparent, modular, and extensible.
Transparency means that there are no unopenable black boxes and the cost of any operation should
be determinable. Modularity means that it is possible to omit functionality and the expense of that
functionality if it is not needed. The base RTLinux system supports high speed interrupt handling and no
more. And extensibility means that programmers should be able to add modules and tailor the system to
their requirements. It has simple priority scheduler that can be easily replaced by schedulers more suited
to the needs of some specific application. When developing RTLinux, it was designed to maximize the
advantage we get from having Linux and its powerful capabilities available.

4.3 CORE COMPONENTS

RTLinux is structured as a small core component and a set of optional components. The core component
permits installation of very low latency interrupt handlers that cannot be delayed or preempted by Linux
itself and some low level synchronization and interrupt control routines. This core component has been
extended to support SMP and at the same time it has been simplified by removing some functionality
that can be provided outside the core.

4.4 FUNCTIONALITY
The majority of RTLinux functionality is in a collection of loadable kernel modules that provide op-
tional services and levels of abstraction. These modules include: rtl sched a priority scheduler that

Rizvi College of Engineering, Bandra, Mumbai. 8

 Chapter 4 RT LINUX

supports both a ”lite POSIX” interface described below and the original V1 RTLinux API. rtl time
which controls the processor clocks and exports an abstract interface for connecting handlers to clocks.
rtl posixio supports POSIX style read/write/open interface to device drivers. rtl fifo connects RT tasks
and interrupt handlers to Linux processes through a device layer so that Linux processes can read/write
to RT components. semaphore is a contributed package by Jerry Epplin which gives RT tasks block-
ing semaphores. POSIX mutex support is planned to be available in the next minor version update of
RTLinux. mbuff is a contributed package written by Tomasz Motylewski for providing shared memory
between RT components and Linux processes.

4.5 KERNEL MODULES

RTLinux is in fact a Linux kernel module. It is the same type of module that Linux uses for drivers,
file systems, and so on. The main difference between RTLinux module and an ordinary Linux module
is that RTLinux module calls functions, which are offered by RTLinux kernel whereas ordinary module
uses only Linux kernel functions. The source code of a simple Linux module is given below.
1 # i n c l u d e <l i n u x / module . h>
2 # i n c l u d e <l i n u x / k e r n e l . h>
3 i n t init module ( void )
4 {
5 p r i n t k ( ” I n i t \n” ) ; / ∗ P r i n t i n g ” I n i t ” i n Kernel ∗ /
6 return 0;
7 }
8 void cleanup module ( void )
9 {
10 p r i n t k ( ” C l e a n u p \n ” ) ; / ∗ C l e a r i n g ” I n i t ” i n K e r n e l ∗ /
11 }

kernelcode.c

After you insert the module by running modprobe threads0, you should see a message Init on your
console. After running rmmod threads0, you will see a Cleanup message. If you write RTLinux appli-
cation you use these functions to initialize and deinitialize your application.

4.6 THREADS
RT-Linux implements a POSIX API for a threads manipulation. A thread is created by calling the
It is necessary to set thread priorities in RTLinux. Threads with higher priorities can preempt threads
with lower priorities. For example, we can have a thread controlling a stepper motor. In order to move
the motor fluently, it is necessary to start this thread in strictly regular intervals. This can be guaranteed
by assigning a high priority to this thread. The example threads2.c sets different thread priorities. Setting
of thread priority is done by code shown below:
1 i n t init module ( void )
2 {
3 pthread attr t attr ;
4 s t r u c t s c h e d p a r a m param ;
5 p t h r e a d a t t r i n i t (& a t t r ) ;
6 param . s c h e d p r i o r i t y = 1 ;
7 p t h r e a d a t t r s e t s c h e d p a r a m (& a t t r , &param ) ;
8 p t h r e a d c r e a t e (& t 1 , &a t t r , &t h r e a d c o d e , ” t h i s i s t h r e a d 1 ” ) ;
9 r t l p r i n t f ( ” T h r e a d 1 s t a r t e d \n ” ) ;
10 ...
11 }

threadcode.c

Rizvi College of Engineering, Bandra, Mumbai. 9

 Chapter 4 RT LINUX

Figure 4.1: Real Time Operating System Kernel

The output the program is as follows.

1 Thread 1 started
2 Thread 2 started
3 Thread 3 started
4 Message : this is thread 1
5 Message : this is thread 2
6 Message : this is thread 2
7 Message : this is thread 2
8 Message : this is thread 1
9 Message : this is thread 1
10 Message : this is thread 3
11 Message : this is thread 3
12 Message : this is thread 3

threadout.txt

The thread 2 has the highest priority and the thread 3 has the lowest priority. The first message is
printed by the middle priority thread 1 because it is started short time before the thread 2.

Rizvi College of Engineering, Bandra, Mumbai. 10

Chapter 4 RT LINUX

4.7 RTAI
RTAI stands for Real-Time Application Interface. It is a real-time extension for the Linux kernel - which
lets users write applications with strict timing constraints for Linux. Like Linux itself the RTAI software
is a community effort.
RTAI supports several architectures:
x86 (with and without FPU and TSC)
x86-64
PowerPC
ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x)
MIPS
RTAI provides deterministic response to interrupts, POSIX compliant and native RTAI real-time
tasks.
Realtime Application Interface consists mainly of two parts:
An Adeos-based patch to the Linux kernel which introduces a hardware abstraction layer
A broad variety of services which make real-time programmers’ lives easier
RTAI versions over 3.0 use an Adeos kernel patch, slightly modified in the x86 architecture case,
providing additional abstraction and much lessened dependencies on the ’patched’ operating system.
Adeos is a kernel patch comprising an Interrupt Pipeline where different Operating System Domains
register interrupt handlers. This way, RTAI can transparently take over interrupts while leaving the
processing of all others to Linux. Use of Adeos also frees RTAI from patent restrictions caused by
RTLinux project.

Rizvi College of Engineering, Bandra, Mumbai. 11

Chapter 5 Case Studies

Chapter 5

Case Studies

Some of the popular RTOSs are reviewed here to identify their salient features which make them suit-
able for different embedded real-time applications. One of the General Purpose Operating Systems is
also discussed here to highlight why a General Purpose Operating System is not suitable for real-time
applications.

5.1 QNX RTOS v6.1

The QNX RTOS v6.1 has a client-server based architecture. QNX adopts the approach of implementing
an OS with a 10 Kbytes micro-kernel surrounded by a team of optional processes that provide higher-
level OS services .Every process including the device driver has its own virtual memory space. The
system can be distributed over several nodes, and is network transparent. The system performance
is fast and predictable and is robust. It supports Intel x86family of processors, MIPS, PowerPC, and
StrongARM. Documentation is extensive except for the details on the APIs [10]. QNX has successfully
been used in tiny ROM-based embedded systems and in several-hundred node distributed systems.

5.2 VRTX
VRTX has multitasking facility to solve the real-time performance requirements found in embedded
systems. Pre-emptive scheduling is followed ensuring the best response for critical applications. Inter-
task communication is by use of mailboxes and queues. Mailbox is equivalent to an event signal and
events can pass data along with the event. Queues can hold multiple messages and this buffering facility
is useful when sending task produces messages faster than the receiving task can handle them. Dynamic
memory allocation is supported and allocation and release is in fixed size blocs to ensure predictable
response times. VRTX has been designed for development and target system independence as well as
real-time clock independence. VRTX provides core services which every microprocessor can use to its
advantage.

5.3 Windows CE 3.0

Windows CE 3.0 is an Operating system rich in features and is available for a variety of hardware
platforms. It exhibits true real-time behavior most of the times. But the thread creation and deletion
has periodic delays of more than 1 millisecond occurring every second. The system is complex and
highly configurable. The configuration of CE 3.0 is a complicated process. The documentation does
not give in depth knowledge about inner workings of the system though the APIs are well documented.

Rizvi College of Engineering, Bandra, Mumbai. 12

Chapter 5 Case Studies

The system is robust and no memory leak occurs even under stressed conditions. CE 3.0 uses virtual
memory protection to protect itself against faulty applications.

5.4 pSOSystem/x86 2.2.6

pSOS+ is a small kernel suitable for embedded applications. This uses the software bus to communicate
between different modules. The choice of module to be used can be done at compile time making
it suitable for embedded applications. System has a flat memory space. All threads share the same
memory space and also share all objects such as semaphores. So it has more chances of crashing.
Around 239 usable thread priority levels available making it suitable for Rate monotonic scheduling.
pSOS has a multiprocessor version pSOS+m which can have one node as master and a number of nodes
as slaves. Failure in master will however lead to system crash. The Integrated Development Environment
is comprehensive and is available for both Windows and UNIX systems. The drawback of this RTOS is
that it is available only for selected processors and that lack of mutexes in some versions leads to priority
inversion.

5.5 VxWorks (Wind River Systems )

VxWorks is the premier development and execution environment for complex real-time and embedded
applications on a wide variety of target processors. Three highly integrated components are included
with VxWorks: a high performance scalable real-time operating system which executes on a target pro-
cessor; a set of powerful cross-development tools; and a full range of communications software options
such as Ethernet or serial line for the target connection to the host. The heart of the OS is the Wind
microkernel which supports multitasking, scheduling, intertask management and memory management.
All other functionalities are through processes. There is no privilege protection between system and
application and also the support for communication between processes on different processors is poor.

5.6 Windows NT
The overall architecture is good and may be a suitable RTOS for control systems that need a good user
interface and can tolerate the heavy recourse requirements demanded for installation. It needs hard disk
and a powerful processor. Configuration and user interaction requires a dedicated screen and keyboard.
The choice of selecting components for installation is limited and it is not possible to load and unload
major components dynamically. Because of all these limitations Windows NT not suitable for embedded
applications. It is neither suitable for other real time applications because of the following factors: a)
There are only 7 priority levels and there is no mechanism to avoid priority inversion b) The Queue of
threads waiting on a semaphore is held in a FIFO order. Here there is no regard for priority, hampering
the response times of highest priority tasks. c) Though ISR responses are fast, the Deferred Procedure
Calls (DPC) handling is a problem since they are managed in a FIFO order. d) The thread switch latency
is high ( 1.2 ms), which is not acceptable in many real-time applications.

Rizvi College of Engineering, Bandra, Mumbai. 13

Chapter 5 Case Studies

Figure 5.1: QNX

Rizvi College of Engineering, Bandra, Mumbai. 14

Chapter 5 Case Studies

Figure 5.2: Windows CE

Rizvi College of Engineering, Bandra, Mumbai. 15

Chapter 6 Conclusion

Chapter 6

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 Op-
erating 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 Open Source, Portable, ROM able, Scalable, Pre-emptive, Multi-
tasking, Deterministic, Efficient Memory Management, Rich in Services, Good Interrupt Management,
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 cur-
rent 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.

Rizvi College of Engineering, Bandra, Mumbai. 16

 References

References

[1] Dedicated Systems Experts; What makes a good RTOS. Brussels, Belgium: Dedicated Systems
Experts,2001
[2] VRTX: A Real-Time Operating System for embedded Microprocessor Applications,; James F.
Ready, IEEE Micro. 6(4),Aug.1986, pp.8-17
[3] Dedicated Systems Experts; RTOS Evaluation Project. Brussels, Belgium: Dedicated Systems Ex-
perts, 2001.
[4] A survey of contemporary Real-Time Operating Systems,,S. Baskiyar ad N. Meghanathan, Infor-
matica 29(2005), pp. 233-240.
[5] Real-Time Systems Design and Analysis: An Engineers Handbook, P.A. Laplante,Second edition,
IEEE Press, 1997.
[6] RTOS for Microcontroller Applications, C. Walls, Electronic Engineering, vol. 68, no. 831, pp.
57-61, 1996.
[7] Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment, C.L. Liu and J.W.
Layland,Journal of the ACM, v. 20, no. 1, pp. 46-61, 1973.
[8] Scheduling Algorithms and Operating Systems Support for Real-time Systems, K. Ramamritham
and J. A. Stancovic, Proceedings of the IEEE, pp. 55-67, Jan 1994.

Rizvi College of Engineering, Bandra, Mumbai. 17

 Project Hosting

Appendix A

Project Hosting

The report is shared at Academia.edu. The complete report about the seminar is uploaded here for future
reference.

Report Link : http://www.academia.edu/attachments/6516122/download_file

QR CODE:

Rizvi College of Engineering, Bandra, Mumbai. 18