Professional Documents
Culture Documents
Seminar Report - Embedded OS For Real Time Applications
Seminar Report - Embedded OS For Real Time Applications
ON
Bachelor of Technology
IN
Electronics & Communication Engineering
Submitted By
ANKIT MAKOL
EC 3rd YEAR
0802831016
(2010-2011)
Page
ABSTRACT
Embedded systems are the computing devices hidden inside a vast array of everyday
products and appliances such as cell phones, toys, handheld PDAs, cameras, etc. An
embedded system is various type of computer system or computing device that
performs a dedicated function and/or is designed for use with a specific embedded
software application. Embedded systems may use a combination of ‘Read-only’ as
well as with ‘Read-Write’ based operating system. But an embedded system is not
usable as a commercially viable substitute for general-purpose computers or devices.
As applications grow increasingly complex, so do the complexities of the embedded
computing devices.
An embedded real-time operating system is the software program that manages all the
programs in an embedded device after initial load of programs by a boot loader. It
normally guarantees a certain capability within a specified storage size and time
constraint as well as with application programs. It also normally has small foot print
including initial boot loader, OS kernel, required device drivers, file systems for the
user data and so forth. It has very-likely structure of a normal operating system
however mainly differentiated by some factors such as type of pre-installed device,
functional limits, taking designed job only.
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.
2
Page
CONTENTS
1. Introduction.................................................................................................. 1
2. Embedded Systems...................................................................................... 1
2.1. What are embedded Systems?.............................................................. 1
2.2. What is inside an embedded system?................................................... 2
2.3. Features of embedded systems............................................................ 3
3. Operating Systems....................................................................................... 4
6. Case Studies............................................................................................... 20
6.1. RQS RTOS v6.1................................................................................ 20
6.2. VRTX................................................................................................ 20
6.3. Windows CE 3.0............................................................................... 21
6.4. pSOSystem/x86 2.2.6....................................................................... 21
6.5. VxWorks (Wind River System)........................................................ 21
6.6. Windows NT..................................................................................... 22
7. Conclusions................................................................................................ 22
3
8. References................................................................................................. 24
Page
I. 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, defence
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.
2. EMBEDDED SYSTEMS
2.1. WHAT ARE EMBEDDED SYSTEMS?
In the 1980s, embedded systems brought microprocessors into every part of our
personal and professional lives. Presently there are numerous gadgets coming out to
make our life easier and comfortable because of advances in embedded systems.
Mobile phones, personal digital assistants and digital cameras are only a small
segment of this emerging field.
All embedded systems contain a processor and software. The processor may be
8051 micro-controller or a Pentium-IV processor (having a clock speed of 2.4 GHz).
Certainly, in order to have software there must be a place to store the executable code
and temporary storage for run-time data manipulations. These take the form of ROM
and RAM respectively. If memory requirement is small, it may be contained in the
same chip as the processor. Otherwise one or both types of memory will reside in
external memory chips. All embedded systems also contain some type of inputs and
outputs (Fig. 2.2.a). For example in a microwave oven the inputs are the buttons on
the front panel and a temperature probe and the outputs are the human readable
5
display and the microwave radiation. Inputs to the system generally take the form of
Page
sensors and probes, communication signals, or control knobs and buttons. Outputs are
generally displays, communication signals, or changes to the physical world.
Within the exception of these few common features, rest of the embedded
hardware is usually unique and varies from application to application. Each system
must meet a completely different set of requirements. The common critical features
and design requirements of an embedded hardware include:
• Memory: Hardware designer must make his best estimate of the memory
requirement and must make provision for expansion.
• Number of units: The no. of units expected to be produced and sold will
dictate the Trade-off between production cost and development cost.
3. OPERATING SYSTEMS
The operating system organizes and controls the hardware and it is that piece of
software that turns the collection of hardware blocks into a powerful computing tool.
Broadly the tasks of the Operating system are:
7
ensuring that each process and application receives enough of the processor's
time to function properly, using maximum processor cycles for real work as is
possible and switch between processes in a multi-tasking environment.
c. Device Management: The operating system manages all hardware not on the
computer's motherboard through driver programs. Drivers provide a way for
applications to make use of hardware subsystems without having to know
every detail of the hardware's operation. The driver's function is to be the
translator between the electrical signals of the hardware subsystems and the
high-level programming languages of the operating system and application
programs. One reason that drivers are separate from the operating system is
for upgradability of devices.
Four types of Operating systems, based on the kind of applications they support are:
However, the two systems are not mutually exclusive, and the area in which
they overlap creates the combination of systems known as real-time embedded
systems.
The environment of the real-time system creates the external events. These
events are received by one or more components of the real-time system. The response
of the real-time system is then injected into its environment through one or more of
its components. Decomposition of the real-time system, as shown in Figure 4.a, leads
to the general structure of real-time systems.
•
10
The radar system scans and searches for potential targets. Coordinates of a
potential target are sent to the C&D system periodically with high frequency
Page
In this weapons defence system example, the communication between the radar
system and the C&D system is aperiodic, because the occurrence of a potential target
is unpredictable and the potential target can appear at any time. The communication
between the C&D system and the weapons firing control system is, however, periodic
because the C&D system feeds the firing coordinates into the weapons control system
periodically (with an extremely high frequency).Initial firing coordinates are based on
a pre-computed flight path but are updated in real-time according to the actual
location of the incoming missile.
In this example, the controlling system is the navigation system. The controlled
systems are the radar system and the divert-and-altitude-control system. We can
observe both periodic and aperiodic communications in this example. The
communication between the radars and the navigation system is aperiodic. The
communication between the navigation system and the diver and-altitude-control
system is periodic.
11
Real-time systems are defined as those systems in which the overall correctness
of the system depends on both the functional correctness and the timing correctness.
The timing correctness is at least as important as the functional correctness.
For hard real-time systems, the level of tolerance for a missed deadline is
extremely small or zero tolerance. The computed results after the missed deadline are
likely useless for many of these systems. The penalty incurred for a missed deadline
is catastrophe. For soft real-time systems, however, the level of tolerance is non-zero.
The computed results after the missed deadline have a rate of depreciation. The
usefulness of the results does not reach zero immediately passing the deadline, as in
the case of many hard real-time systems. The physical impact of a missed deadline is
non-catastrophic.
A hard real-time system is a real-time system that must meet its deadlines with
a near-zero degree of flexibility. The deadlines must be met, or catastrophes occur.
The cost of such catastrophe is extremely high and can involve human lives. The
computation results obtained after the deadline have either a zero-level of usefulness
or have a high rate of depreciation as time moves further from the missed deadline
before the system produces a response.
A soft real-time system is a real-time system that must meet its deadlines but
with a degree of flexibility. The deadlines can contain varying levels of tolerance,
average timing deadlines, and even statistical distribution of response times with
different degrees of acceptability. In a soft real-time system, a missed deadline does
not result in system failure, but costs can rise in proportion to the delay, depending on
the application.
One thing worth noting is that the length of the deadline does not make a real-
time system hard or soft, but it is the requirement for meeting it within that time.
The weapons defence and the missile guidance systems are hard real-time
systems. Using the missile guidance system for an example, if the navigation system
13
This system has zero tolerance for a missed deadline. The new coordinates obtained
after the deadline are no longer useful because at subsonic speed the distance is too
short for the altitude control system to navigate the missile into the new flight path in
time. The penalty is a catastrophic event in which the missile collides with the
mountain. Similarly, the weapons defence system is also a zero-tolerance system. The
missed deadline results in the missile sinking the destroyer, and human lives
potentially being lost. Again, the penalty incurred is catastrophic.
On the other hand, the DVD player is a soft real-time system. The DVD player
decodes the video and the audio streams while responding to user commands in real
time. The user might send a series of commands to the DVD player rapidly causing
the decoder to miss its deadline or deadlines. The result or penalty is momentary but
visible video distortion or audible audio distortion. The DVD player has a high level
of tolerance because it continues to function. The decoded data obtained after the
deadline is still useful.
Because one or a few missed deadlines do not have a detrimental impact on the
operations of soft real-time systems, a soft real-time system might not need to predict
if a pending deadline might be missed. Instead, the soft real-time system can begin a
recovery process after a missed deadline is detected.
For example, using the real-time DVD player, after a missed deadline is
detected, the decoders in the DVD player use the computed results obtained after the
deadline and use the data to make a decision on what future video frames and audio
data must be discarded to re-synchronize the two streams. In other words, the
decoders find ways to catch up.
14
So far, we have focused on meeting the deadline or the finish time of some
work or job, e.g., a computation. At times, meeting the start time of the job is just as
Page
important. The lack of required resources for the job, such as CPU or memory, can
prevent a job from starting and can lead to missing the job completion deadline.
Ultimately this problem becomes a resource-scheduling problem. The scheduling
algorithms of a real-time system must schedule system resources so that jobs created
in response to both periodic and aperiodic events can obtain the resources at the
appropriate time. This process affords each job the ability to meet its specific timing
constraints.
The more modules there are, and the more interconnections there
are between modules, the more chaotic the software becomes due to
the multiple interconnections. This is sometimes referred to as
“spaghetti software”. With this design, it is almost impossible to
distribute the OS in one or other way on multiple processors.
15
RTOSs have basically been designed this way for a long time.
This way of doing things makes it a lot easier for the OS vendor
to sell a scalable OS (with a greater or lesser number of functions). It
is easier to debug (each “object” remains small). Distribution over
multiple processors is simple. Replacing one module does not have a
“bug snowball effect”. One module crash does not necessarily crash
the whole system, meaning it is an investment in a more robust
environment. Using this method to implement redundancy in the OS is
also more conceivable. Dynamic loading and unloading of modules
becomes a possibility.
The first RTOS was produced more than 20 years ago by DEC for the PDP
family of machines. A multitasking concept is essential if you want to develop a good
real-time application. Indeed, an application has to be capable of responding in a
17
In the UNIX (or POSIX) world, from the outset people have talked about the
different processes in the system. In these complex systems, the context or
environment for each process is very heavy, (Processor, I/O, MMU, FPP, etc.) and
therefore switching from one process to another is time-consuming. Two reasons
changed this approach. Firstly, producing complex, distributed software requires a
multitasking approach which is too heavy to implement with the process concept.
Secondly, there was the POSIX effort, aimed at bringing the RT and non RT world
together. The concept of a “thread” was therefore invented. It is a “sub process” or a
“light-weight process”. It inherits the context of a process but uses only a subset of it
so that switching between threads can be done more rapidly. Also between threads,
there are no security aspects because they really belong to the same environment or
process.
The net result today is that it can be said that in an RT environment, a process is
an application subdivided into tasks or threads.
In a multitasking environment, you have to “schedule” from one task (or thread)
to another. If more than one thread wants to use the processor simultaneously, an
algorithm is needed to decide which thread will run first. A deadline-driven
scheduling mechanism would be ideal. However, the current state of technology does
not allow this. Pre-emptive priority scheduling offers a substitute, taking into account
the existence of theories like RMS to give you a decision rule concerning which
priority level to assign to each thread. Pre-emption should be used all the time to
ensure that a high priority event can be dealt with before any other lower priority
event. For this we not only need a pre-emptive priority scheduling mechanism: but in
addition interrupt handling following different simultaneous interrupts should be
handled in a pre-emptive way.
There are different reasons to have a lot of priority levels provided in the
RTOS. The first one stems from what was discussed in sections 5.1 and 5.2. In a
client-server OS environment, the system itself can be viewed as one or more server
applications subdivided into threads. Therefore a number of high priority levels have
to be dedicated to system processes and threads.
18
with a large number of threads, it is essential to be able to place all the real-time
threads on a different priority level. The non real-time threads can be placed on one
level (lower than the real-time ones) and may run in a round-robin fashion. A level 0
priority or lowest level is necessary to implement the idle monitor required to
measure the available processor power.
5.3.1. SCHEDULER
The heart and soul of any operating system is its scheduler. This piece of
the operating system decides which of the ready tasks has the right to use the
processor (go into running state) at a given time. Some of the common
scheduling algorithms used in mainstream operating systems are first-in-first-
out (FIFO), shortest job first and round robin. First-in-first-out [FIFO]
scheduling is used in DOS, which is not a multitasking operating system. Here
each task runs until it is finished and only after that next task is started. In
shortest job first scheduler each time a running task completes or blocks itself,
next task selected is one that will require the least amount of processor time to
complete. Round robin is the only scheduling algorithm of the three in which
the running task can be pre-empted, that is, interrupted while it is running. In
this case, each task runs for some predetermined amount of time. After that
interval has elapsed, the running task is pre-empted by the operating system and
the next task in line gets its chance to run.
A good embedded RTOS should have provision for lot of priority levels.
A number of high priority levels have to be dedicated to the system processes
and threads. And in a complex application with large number of threads, it is
essential to be able to place all the real-time threads on a different priority level
above the non real-time threads.
5.3.2 INTERRUPTS
Task is the basic building block of software written under an RTOS. Each task
in RTOS is in one of the following three states Fig 5.4a.
For example a task that handles data coming from a network will have nothing
to do when there is no data.
using an RRS. Most RTOSs implement this when you put more than one task on the
same priority level. Other RTOSs have an RRS explicitly defined for certain priority
Page
ranges.
Fig 5.4a Process States and Transitions
Each task has its own private data [includes register values, Program Counter and stack].
All other data like global, static, initialized, un-initialised…etc is shared among the tasks.
A situation like this can lead to many of shared data problems. If task1 calls a function
Read X for reading a shared data that is being modified by task2, there is a chance that
data read by task1 is erroneous (Fig. 5.5a).
Semaphore can also act as a signalling device for synchronisation. For example,
a task that formats printed reports builds those reports into a fixed memory
buffer. After formatting one report into the buffer the task must wait until
interrupt routine has finished printing. Here the task can wait for a semaphore
after it has formatted a report. The interrupt routine on feeding the report to
printer can release the semaphore. The task on receiving the semaphore formats
the next report. When using Semaphores, one should ensure that it does not lead
to Priority inversion or deadly embrace. Some RTOS have a method called
priority inheritance to tackle this problem.
Message Mailboxes: Messages are sent to a task using kernel services called
message mailbox. Mailbox is basically a pointer size variable. Tasks or ISRs
can deposit and receive messages (the pointer) through the mailbox. A task
looking for a message from an empty mailbox is blocked and placed on waiting
list for a time(time out specified by the task) or until a message is received.
When a message is sent to the mail box, the highest priority task waiting for the
message is given the message in priority-based mailbox or the first task to
request the message is given the message in FIFO based mailbox.
Event Flags: basically these are Boolean flags which tasks can set or reset that
other tasks can wait for. Event flags are used in cases where a task has to
synchronise with occurrence of multiple events. A task can be synchronized
22
conjunctive synchronisation (logical AND) [3]. More than one task can wait for
same event. RTOS can form groups of events and tasks can wait for any subset
of events in a group.
6. CASE STUDIES
Some of the popular RTOSs are reviewed here to identify their salient features
which make them suitable 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.
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 Strong ARM. Documentation is extensive except for the details on the
APIs. QNX has successfully been used in tiny ROM-based embedded systems and in
several-hundred node distributed systems
6.2. VRTX
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
Page
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.
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.
processes. There is no privilege protection between system and application and also
the support for communication between processes on different processors is poor.
Page
6.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 & 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.
7. CONCLUSIONS
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
25
26
Page
8. References
27
Page