Embedded Operating Systems

Real-Time and Embedded
Operating Systems
Embedded Systems Engineering
0.9.2
Ren Schwaiger sanssecours@f-m.fm
Vienna
January 23, 2011
Contents
1 Introduction 4
2 Overview 4
2.1 Operating System 4
2.2 Embedded Operating Systems 5
2.3 Real-Time Operating Systems 6
2.3.1 Scheduler 7
2.3.2 Timing Requirements 8
3 History 8
4 Categorization of Real-Time Operating Systems 10
4.1 Small, Fast, and Proprietary Kernels 10
4.2 Component-Based Kernels 11
4.3 Real-Time Extension to Existing Operating Systems 11
4.3.1 Core-Modication 12
4.3.2 Combining a General Purpose OS with a RTOS 13
4.4 Comparison 13
5 Portability 13
5.1 Realtime-POSIX 15
5.1.1 Minimal Realtime System Prole (PSE51) 16
5.1.2 Realtime Controller System Prole (PSE52) 17
5.1.3 Dedicated Realtime System Prole (PSE53) 17
5.1.4 Multi-Purpose Realtime System Prole (PSE54) 17
6 Examples of Real-Time Operating Systems 18
6.1 VxWorks 18
6.2 Windows CE 19
6.3 Linux 21
6.3.1 CLinux 22
6.3.2 Real-Time Patch Set 24
6.3.3 Xenomai 25
7 Summary 28
List of Figures
1 Layer model showing the role of an operating system 5
2 Overview Realtime-POSIX 16
3 Functionality offered by the POSIX real-time proles 17
4 Different approaches to real-time under Linux 21
5 Logical Layers and available skins in Xenomai 26
6 Adeos domains in Xenomai 27
1 Introduction
1 Introduction
This text describes the basic concepts of operating systems in the domain of
embedded systems. It starts by dening the term operating system (OS) and
gives insight about the features that distinguish embedded and real-time operating
systems (RTOS) from general purpose OSes. After that, a short summary about
the history of real-time operating systems shows their development over the last
decades. POSIX and other portability standards are explained in the following
section. Furthermore this text gives an overview of popular embedded- and
real-time operating systems and shows their key differences.
2 Overview
Many application are still developed to run as a single task on an embedded
system. This might still be the preferred way to design solutions for simple
applications. However, constant advantages in hardware development and the
use of micro-controllers in systems with growing complexity have increased
the potential benet gathered by the use of an operating system on embedded
platforms. The features an OS provides to ease the development of applications
are the topic of this section.
2.1 Operating System
The basic purpose of an operating system, illustrated in Figure 1, is to provide an
interface to the underlying hardware. A program which is written for a certain OS
therefore should not need any changes at the source code level, as long as the same
operating system or a compatible version of it will be used. This is a big advantage
over the often fundamental modications needed, when moving to a different
platform if the features of the hardware are accessed directly. Applications which
only accesses hardware in the form of an API (Application Programming Inter-
face) provided by the OS, can be easily ported between architectures, for example
from x86 to ARM by compiling the code for the new platform.
An operating system does not only provide the interface to the hardware but also
manages resources. The typical managing capabilities include [Sch07]:
Process management: Creating, starting, stopping, and terminating tasks
Memory management: Allocation and deallocation of memory, memory
protection, virtual memory
Real-Time & Embedded Operating Systems 4/34
2 Overview
Figure 1: Layer model showing the role of an operating system
!"#$%"#&
!"#$%"#&
'(()*+",*-.
'(()*+",*-.
/0&#
/0&#
1(&#",*.2345,&6
1(&#",*.2345,&6
Hardware
Hardware
Application
Application
User/Controlled Object
User/Controlled Object
Operating Sytem
Operating Sytem
!"#$%&"'%
()&"''*+&%
,-%&"./0122%
,$#)12%
()+*&/3"4$5"%
6*&+*&/3"4$5"%
'(()*+",*-.
'(()*+",*-.
/0&#
/0&#
!"#$%"#&
!"#$%"#&
/0&#34("+&
777777777777777777777777
1(&#",*.2345,&6
777777777777777777777777
8&#.&)34("+&
/0&#34("+&
777777777777777777777777
1(&#",*.2345,&6
777777777777777777777777
8&#.&)34("+&
Processor management: Scheduling, Dispatching
File management
Device management
All of these services and other features such as lesystems, networking facilities,
security measures, and multiuser support are provided by every major desktop
and server operating system today. The market for these systems, sometimes
also called universal or general purpose operating systems, is mainly shared between
Windows, Mac OS X, GNU/Linux, and other Unix derivates. While technically
not an operating system feature, a graphical user interface is usually also provided
by the operating systems mentioned before [Wik09b].
2.2 Embedded Operating Systems
As the name suggests, embedded operating systems are OSes that run on embed-
ded systems. They usually differ from an operating system used in the desktop
or server market by their smaller kernels and lower resource usage. These prop-
erties are a direct consequence of the resource limitations of typical embedded
platforms.
2 Overview
These limitations also lead to a modular design of this type of operating systems.
Features like a le system, or support for some special kind of bus, if provided at
all, are typically encapsulated in modules and can be turned off to reduce the OS
memory footprint.
The result of this approach is often the need to congure and compile an OS for
the used platform. This is rarely needed and often not possible when installing
a universal operating system. Since the conguration is usually done by the
company which is developing a new embedded product, embedded operating
systems are often available to the customer in source code form.
The market for these operating systems is much more diverse than the one for
universal OSes. There are many vendors which offer one or even more embedded
operating systems. Some of them are proprietary while others are provided under
the terms of e.g., the GPL- or BSD-License. For example, the company Wind
River offers their proprietary OS VxWorks as well as their own embedded Linux
version.
It is not uncommon for companies to develop their own embedded OS in house.
These systems are usually called home grown operating systems. In the last
years the number of these systems have declined and a shift to commercial offer-
ings could be observed [Tur05].
Examples of popular embedded operating systems roughly sorted descending
according to their popularity include Linux based operating systems, VxWorks,
Windows CE, Windows Embedded, DSP/BIOS (real-time OS from Texas Instru-
ments for their DSPs), and QNX [Tur05, Dev07]. Other popular choices among
embedded system developers include eCos, OS-9, the OSE real-time operating
system family, Nucleus OS, and RTEMS.
2.3 Real-Time Operating Systems
Realtime in operating systems: the ability of the operating system
to provide a required level of service in a bounded response time.
POSIX Standard [IEE04a]
Generally embedded operating systems have certain timing constraints. These
constraints can be either soft, rm or hard. Although not every embedded system
needs precise timing in the form of deadlines, e.g., web terminals or phones
usually do not, the need to execute a task within a certain time is usually a
requirement in embedded development. Control systems, for example are a large
2 Overview
group of systems where exact timing is necessary. The consequence of this is,
that most embedded operating systems are also real-time operating systems and
vice versa [Rom05]. In the next sections these two terms will therefore be used
interchangeable unless noted otherwise.
A control system is a device or set of devices to manage, command, direct or
regulate the behavior of other devices or systems [Wik10].
To provide reasonable deadlines a real-time operating system needs to be deter-
ministic and therefore provide predictable behaviour. This results in the following
services which should be provided in real-time operating systems [Con05]:
Scheduler with constant- or given maximum execution time
Fast context switch time
Guaranteed execution time of system calls
Known maximum time for interrupt latency and interrupt masking
These features will be further described in the next two sections. The rst section
deals with scheduling in real time systems while the second section combines the
other services under the topic of timing requirements.
2.3.1 Scheduler
There are two approaches for predictable scheduling, which both need informa-
tion on the execution time of a task:
Static Scheduling
Dynamic Scheduling
If a system uses static scheduling the number of real-time tasks needs to be known.
The decisions regarding which task should be scheduled at which instant are cal-
culated ofine. At run time this information is read and tasks will be activated
periodically according to the calculated schedule. This approach has the disadvan-
tage that the worst case execution time of a task needs to be considered, while
the average time needed to nish a task might be shorter. The result is a less than
optimal usage of the available processing capacity. Advantages of static scheduling
are small overhead and the ability to model mutual exclusion of tasks without
using additional data structures like semaphores. This form of scheduling is
usually used in time-triggered system like for example
TTP
OS [TTP05].
3 History
Dynamic scheduling means that the decision which task should be executed
next is calculated at run-time. Usually the tasks are selected based on priorities
which are either static or dynamic. This approach has the advantage of more
exibility compared to static scheduling at the expense of a higher overhead since
the scheduler needs to dynamically determine the next task to execute. Examples
of dynamic scheduling algorithms are Rate Monotonic Scheduling and the Earliest
Deadline First-Algorithm [AB90].
Further explanation on the topic scheduling in real-time systems can be found
in the book Real-Time Systems: Design Principles for Distributed Embed-
ded Applications [Kop97] and in an article about the topic by Audsley and
Burns [AB90].
2.3.2 Timing Requirements
The most important characteristic of an RTOS lies in its predictability in the time
domain and therefore in the ability to tell how long it approximately takes to
nish a certain task. The demanded timing requirements of a task are determined
by the object under control. The required reaction time of an application might
be in the area of a fews. While a solution for this extreme conditions is generally
realized without the assistance of an operating system, a control loop with timing
in the area of about 10 ms (100 Hz) is a very common task for an application
running on a real-time OS.
To serve such a requirement, the time to switch between two tasks needs to
be bound by a reasonable small interval. An other requirement is, that the
preemption of system tasks must be possible within an interval small enough for
the demanded timing requirements. If the kernel code for example includes non-
preemptive sections which have worst case execution times of several hundred
milliseconds the execution of the control loop described before would not be
possible without the violation of deadlines. Other timing information that
is needed to construct a predictable system are interrupt latency (time from
the raise of an interrupt until the corresponding interrupt service routine is
invoked), interrupt masking time (latency incurring on activation or deactivation
of interrupt lines), and the execution time of system calls.
3 History
UNIX: An operating system similar to OS-9, but with less function-
ality and special features designed to soak up excess memory, disk
3 History
space and CPU time on large, expensive computers.
OS-9 Version 2.4 Manual [Mic99]
While the history of operating systems dates back to the fties, it took about 20
years until the rst real-time operating systems started to appear [Wik09c]. With
RDOS, an abbreviation for Real-time Disk Operating System, one of the rst
systems with guaranteed timing entered the market in 1972. It was released as
an OS for the Nova and Eclipse minicomputers from Data General. While the
term minicomputer might give the impression of a rather small system, these
computers had a size ranking somewhere between a mainframe and todays mi-
crocomputers.
The RSX-11-family of real-time computer operating systems from DEC was
released about the same time as RDOS. One popular version of this OS was
RSX-11M. Dave Cutler, the project manager responsible for this product later
also had a leading role in developing VMS and Windows NT. RSX-11 already
featured a set of modern technologies like application swapping, a hierarchical
lesystem, and multitasking [Cus93]. The main platform for running this OS
was the widely used minicomputer PDP-11 in its various incarnations.
While the operating systems mentioned before already had real-time capabilities
their use in the area of embedded systems was limited by the size of the machines
they were running on. The history of embedded operating systems therefore
started around the early eighties, when microprocessors in this eld became
powerful enough to run a small OS together with the application code.
OS-9, was one of the rst systems considered an embedded OS. Originally devel-
oped in 1979 in assembler for the Motorola 6809 processor, it was also used as
a general operating system and already featured a GUI in early versions. While
the use as an universal operating system faded over the years the newer portable
version of OS-9, which was rewritten using the C language, is still in use and
under active development today.
An other embedded operating system developed in the early eighties is VxWorks
from the company WindRiver [Mil09]. First started only as an addition for the
VRTX kernel from the company Hunter & Ready, it was later equipped with
a kernel developed by the company itself [VxW94]. VxWorks is today one of
the most popular OSes in the embedded market and can be found in popular
products ranging from ethernet switches to planes [Wik09a].
Linux, rst only devised as a hobby project for running a universal Unix like
4 Categorization of Real-Time Operating Systems
operating system on x86-compatible hardware has taken its rst step into the
embedded/real-time world in 1995 [SL06] when Michael Barabanov and others
at the New Mexico Institute of Mining and Technology started researching the
use of the OS in a real-time environment [Bar97]. This research centered around
the use of Linux as a process in a microkernel and goes by the name of Real-
Time Linux or RTLinux. In 1998 and 2001 two other projects named RTAI and
Xenomai were started to create their own real time version of Linux. While all
three mentioned projects use a second kernel besides Linux to schedule real-time
task other work focused on bringing better real-time support directly to Linux.
One of these efforts is the Real-Time Patch Set, a collection of patches which
helps to improve the responsiveness of the kernel. In 2009 Dario Faggioli and
Michael Trimarchi started to work on a new real-time scheduler class based on
the earliest deadline rst algorithm. The project aims to provide an alternative to
the priority based POSIX real-time schedulers already offered by Linux.
4 Categorization of Real-Time Operating Sys-
tems
The market for embedded operating systems is split between many different ven-
dors and systems. Despite their differences, certain aspects might be used to show
their commonalities and categorize them. One approach is to categorize them ac-
cording to their design. The following classication is a slightly modied version
of the one listed in an article by John A. Stankovic and R. Rajkumar [SR04]:
Small, fast, and proprietary kernels
Real-Time extension to existing operating systems
Component-based kernels
4.1 Small, Fast, and Proprietary Kernels
Operating systems belonging to this group are specically developed for the use in
real-time environments. Their small kernels and low resource usage let them run
even on platforms with low processing capabilities like 8-bit micro-controllers.
C/OS is a real-time operating system tting in this category. First created to
show the inner workings of an embedded operating system and published in
source code formin two books [Lab92,Sim99] it is, in its second and third version,
C/OS-II and C/OS-III available as commercial RTOS from the company
Micrim. The memory footprint of both operating systems, which lies between
6 and 24 KBytes [uC/09], shows the small amount of resources needed to run
C/OS. Other examples of operating systems specically built from the ground
for real-time purposes include VxWorks, QNX, and RTEMS.
4.2 Component-Based Kernels
Another method to construct real-time systems is to base them on components.
Specic functions are encapsulated in modules which communicate via interfaces.
While for example Windows CE and VxWorks provide a mechanism to customize
the OS based on specic units of functionality, they are not considered to be
component-based since their modules rely on a basic kernel and are therefore
not designed to be used in other environments [FSH
+
01]. The operating system
eCos (Embedded Congurable Operating System) on the other hand ts in this
category. The royalty-free highly customizable OS is designed for use in smaller
embedded systems. The kernel module which provides
thread creation and controlling facilities,
different choices of schedulers,
a range of synchronization primitives,
and integration with the systems support for interrupts and exceptions
is optional [Fre08]. This means that a small system with only one thread can be
built without this basic component as long as none of the kernel functionality is
needed. Other more advanced packages in eCos depend on this basic module.
4.3 Real-Time Extension to Existing Operating Systems
One popular approach to build soft or even hard real-time operating systems
is to take an existing general purpose OS and modify it to satisfy real-time
requirements. Usual practice to reach this goal is either to
apply modications directly to the kernel or to
run the non-realtime OS in combination with a basic real-time operating
system layer (dual kernels, nested OS).
Since modifying an OS is a task hard to achieve without access to the source code,
Linux and other open source operating systems are particularly well suited to be
extended for real-time purposes. Examples of adapted operating systems include
TimeSys Linux, CLinux, RTCore (RTLinux and RTCoreBSD) [YDBI], RTAI,
and Xenomai, which are all based on free operating systems.
One obvious advantage gained by modifying a general purpose OS to t real-time
requirements, is the possibility to execute the same applications that are available
for the non-modied OS. These programs come in handy since not all tasks
in an embedded system need timing guarantees. A logging facility or an e-mail
notication system are examples for such applications.
4.3.1 Core-Modication
General purpose operating systems are usually optimized for fast average reaction
to human input (desktop OS) or high throughput (server OS). Both properties,
while advantageous also in real-time systems are not of highest priority when
determinism is demanded. The main problems in universal operating considering
the domain of real-time include:
Long non-preemptible kernel code
No scheduler with real-time policy available
Insufcient number of available priorities
Slow task switching
High resource usage and hardware requirements (MMU)
No ne grained timers available
A Memory Management Unit (MMU) is a hardware device, usually a part
of the CPU, translating virtual memory addresses to physical addresses. One
of its responsibilities is memory protection, allowing processes only to access
memory that has been allocated for them.
The non-preemptible sections mentioned rst in the list above are a result of the
approach to keep the overall design of an OS simple. Kernel code for example does
not have to be reentrant if it cannot be preempted. The problem with this method
is that the latency of the system rises if higher priority tasks need to wait for the
execution of kernel code to nish. While in many systems with microkernels
this is less of a problem, because of the smaller size of the OS nucleus, in systems
with monolithic kernels this might be quite an issue. In Linux, which is a typical
macrokernel based OS, the option CONFIG_PREEMPT [McK05] allows large areas
of the kernel code to be preempted. This enables a response of the system fast
5 Portability
enough for soft real-time applications. Even better responsiveness is achievable
by using the real-time patch, which allows for preemption of even more sections
in the kernel code. The real-time patch and solutions for some of the problems
mentioned in the list above will be discussed in more depth in the section about
Linux later in this text.
4.3.2 Combining a General Purpose OS with a RTOS
Changing the inner workings of an universal operating system to be more pre-
dictable and responsive is, considering the size of modern kernels, a difcult
and time consuming task. The adaptions to the kernel might also need constant
maintenance to keep up with the development of the other parts of the general
purpose OS. A different approach is to use a real-time kernel and combine it with
only a slightly modied version of an universal operating system. This method
minimizes the dependencies to the general purpose OS while also providing a
small and predictable real-time facility to the developer. The usual approach to
construct such a system is to run the universal operating system as a low priority
task on the real-time OS. Interrupts are handled by the real-time layer and only
emulated in the universal operating system. This approach is used in RTLinux,
RTAI, Xenomai, and RTCoreBSD. While the rst three solutions incorporate
Linux as general purpose OS, RTCoreBSD uses, as the name indicates, either
NetBSD or FreeBSD.
4.4 Comparison
Table 1 shows the typical properties of the systems discussed before. These are
rough estimated values and they can differ signicantly between systems in one
group. While Windows CE for example needs an MMU and only supports 32 Bit
CPUs, C/OS is typically used in much smaller platforms without a memory
management unit.
5 Portability
To establish compatibility of applications not only between the same operating
system on different hardware platforms but also between different operating
systems, OS compatibility standards were introduced. These specications dene
portability at the source code level.
5 Portability
Table 1: Comparison of the typical properties of the different groups of real-time
operating systems
Specically devel-
oped RTOS
Component
based kernel
Extension to existing OS
Core modication Dual kernel
provided real-
time service
SoftHard SoftHard Soft SoftHard
Size KBytesMBytes KBytesMByte MBytesGBytes MBytesGBytes
Customizability High Very High Small Medium
OS Complexity SmallHigh SmallMedium High High
Self hosting
possible
*
No No Yes Yes
MMU support possible possible usually needed needed
Hardware 864 Bit CPU 864 Bit CPU 3264 Bit CPU 3264 Bit CPU
Examples VxWorks, Win-
dows CE, C/OS
eCos CLinux,
TimeSys Linux
RTAI, Xenomai,
RTCore
*
Self hosting means that the same operating system might be used on the development system
and the target.
One of the most important compatibility standards is POSIX
1
[IEE08]. Since
the specication is rather extensive and primarily addresses the needed interfaces
in an interactive general purpose operating systems, proles for embedded sys-
tems which cover a certain subsets of POSIX were introduced in IEEE Standard
1003.13 [IEE04b]. Later in this section this specication will be described in
greater detail.
TRON, which is an abbreviation for The Real-time Operating system Nucleus
is a family of specications for real-time operating systems mainly used in Japan.
It includes architectural descriptions for many different computer platforms like
e.g., personal computers (Business TRON), mainframes (Central and Communi-
cations TRON), and embedded systems (Industrial TRON). ITRON (Micro
ITRON), a specication intended for the construction of small embedded sys-
tems, is one of the most popular sub-standards. While popular in Japan the
standard has not gathered the same support outside the country. A newer project
based heavily on the insights gathered by TRON is the T-engine. Under the hood
of the T-engine forum various companies develop specications for real-time
systems which are open to the public. Implementations of the kernels specied by
1
The standard is also known under the names POSIX.1, Single Unix Specication, Open
Group Technical Standard Base Specications, ISO/IEC 9945 and IEEE Standard 1003.1
5 Portability
the organization can be found on the ofcial website [T-E10]. They are available
as download for member organizations.
Other OS portability layers apart from POSIX and TRON include APEX and
OSEK/VDX. Both specications were designed for a special class of embedded
systems, APEX for the avionic industry and OSEK/VDX for the use in motor
vehicles. More information on this standards can be found, for example, in the
book Embedded System Design [Con05].
5.1 Realtime-POSIX
The Portable Operating System Interface (for UNIX) (IEEE Standard 1003.1) is
maintained by the Austin Group, a joint venture between the IEEE, the Open
Group, and the ISO/IEC. POSIX is grouped into four parts:
Base Denition Common denitions found in the standard
System Interfaces Programming interface functions which should be offered
by a POSIX compatible system (C language API)
Shell and Utilities Commands and utilities provided by a conforming OS
Rationale (Informative) History and explanatory description of the standard
Most real-time systems do not offer all of the services mentioned in the POSIX
standard, therefore four proles were dened in IEEE Std. 1003.13. These specify
embedded systems of varying degree of complexity and the parts of the POSIX
standard needed to implement a compatible operating system. All of them also
reference the implementation of IEEE 1003.26, which denes a unied API for
the access of devices, as mandatory, if the C language API is used. For Ada bind-
ings IEEE standard 1003.5 [IEE99] is referenced. Figure 2 shows the dependencies
between the standards. It should be mentioned that the last update of POSIX
was in 2008 and that the real-time proles still reference the ISO/IEC revision
of POSIX from 2003 since this was also the year the IEEE 1003.13 standard was
updated the last time. The last revision of the POSIX interface bindings for Ada
was in 1999.
Like already mentioned before, the real-time proles in IEEE 1003.13 dene dif-
ferent levels of functionality needed in a compatible OS. Each of them demands
that certain options and units of functionality have to be implemented. Both
options and units of functionality specify POSIX APIs which should be available
in a compatible system. Units of functionality were introduced where the POSIX
5 Portability
Figure 2: Overview Realtime-POSIX
!""#$%&'#())*'+,
!"#$%&
'()*+(&,-./0-1&2331*+4/*-.&
!0-5046&$./(074+(
!""#$%&'#())*'(
!"#$%
!""#$%&'#())*'(*
!"#$%&8(41/*6(&4.9
:6;(99(9&2331*+4/*-.&#<33-0/
!""#$%&'#())*'-
!"#$%&
294&=4.5<45(&$./(074+(>
+
etenos
oenes Aoa
lntertaces tor
baseo on
(C Language)
baseo on
(Aoa Language)
./01%23/#$45%/3#67891/5
?&@*.*641&8(41/*6(&#A>/(6&!0-B1(&C!#:DEF
?&8(41/*6(&,-./0-11(0&#A>/(6&!0-B1(&C!#:DGF
?&'(9*+4/(9&8(41/*6(&#A>/(6&!0-B1(&C!#:DHF
?&@<1/*I!<03->(&8(41/*6(&#A>/(6&!0-B1(&C!#:DJF
oeneo ln
Core
Core
Controller
Mlnlmal
Deolcateo
Multl-Purpose
Traclng
Traclng
Slmple
Flle System
Slmple
Flle System
Message
Queues
Message
Queues
Networklng
Networklng
Asyncbronous
|/O
Asyncbronous
|/O
Multlple
Processes
Multlple
Processes
Sbell &
Utllltles
Sbell &
Utllltles
Multlple
Users
Multlple
Users
Full
Flle System
Full
Flle System
Otbers
Otbers
standard did not offer enough options to dene subsets with just the required
functional extent suitable for real-time systems [IEE04b]. Figure 3 shows that
proles add features by extending the requirements of the lower level prole.
Therefore an application that is written assuming that only the minimal realtime
prole is provided should also run on an operating system implementing a higher
level prole.
5.1.1 Minimal Realtime System Prole (PSE51)
The basic features provide by the minimal prole include functions for:
Device I/O
Signaling
Threads
Real-time clocks
Semaphores
5 Portability
Figure 3: Functionality offered by the POSIX real-time proles
!""#$%&'#())*'+,
!"#$%&
'()*+(&,-./0-1&2331*+4/*-.&
!0-5046&$./(074+(
!""#$%&'#())*'(
POS|X
!""#$%&'#())*'(*
!"#$%&8(41/*6(&4.9
:6;(99(9&2331*+4/*-.&#<33-0/
!""#$%&'#())*'-
!"#$%&
294&=4.5<45(&$./(074+(>
+
etenos
oenes Aoa
lntertaces tor
baseo on
(C Language)
baseo on
(Aoa Language)
./01%23/#$45%/3#67891/5
?&@*.*641&8(41/*6(&#A>/(6&!0-B1(&C!#:DEF
?&8(41/*6(&,-./0-11(0&#A>/(6&!0-B1(&C!#:DGF
?&'(9*+4/(9&8(41/*6(&#A>/(6&!0-B1(&C!#:DHF
?&@<1/*I!<03->(&8(41/*6(&#A>/(6&!0-B1(&C!#:DJF
oeneo ln
Core
Core
Controller
Mlnlmal
Deolcateo
Multl-Purpose
Traclng
Traclng
Slmple
Flle System
Slmple
Flle System
Message
Queues
Message
Queues
Networklng
Networklng
Asyncbronous
|/O
Asyncbronous
|/O
Multlple
Processes
Multlple
Processes
Sbell &
Utllltles
Sbell &
Utllltles
Multlple
Users
Multlple
Users
Full
Flle System
Full
Flle System
Otbers
Otbers
It covers the requirements of a small systems with no user interface dedicated
for the control of unattended systems. A le system is not provided by devices
implementing the prole. Since PSE51 provides only one address space that every
thread can access, no memory management unit (MMU) is needed.
5.1.2 Realtime Controller System Prole (PSE52)
This prole extends PSE51 by providing a le system where regular les can be
created and read or written [Con05]. Like the minimal system prole there is
only one POSIX process with threads which access the same unied memory
space.
5.1.3 Dedicated Realtime System Prole (PSE53)
The dedicated realtime system prole has to provide the functionality to create
and execute more than one process. Since every process has its own space in
memory an MMU is mandatory. Unlike PSE51 and PSE52, which assume a
single processor this prole is dedicated for the use in larger systems with more
processor cores.
5.1.4 Multi-Purpose Realtime System Prole (PSE54)
Operating system which run conventional and real-time tasks side by side might
implement this prole. It covers most of the features of POSIX and is also the
only prole where the implementation of the shell and utilities part of POSIX
is mandatory. A system with high-speed storage devices, network support, and
display devices is assumed to be the hardware running an operating system
offering this prole.
6 Examples of Real-Time Operating Systems
6.1 VxWorks
Wind River began as a customer of Ready Systems, selling its VxWorks
development tools around Readys VRTX OS. VxWorks is short
for VRTX Works, suggests Ready.
Jim Ready [Dev04]
With more than 300 million devices powered by Wind Rivers VxWorks [VxW09],
it is one of the most popular operating systems in the domain of embedded
devices. Formerly built around the VRTX kernel from Ready Systems, it is
since 1987 based on WindRivers own proprietary OS core written by an in-
tern [VxW94].
VxWorks is certied to be compliant to the POSIX PSE52 real-time prole and
also supports some features of PSE53, PSE54, and the POSIX.1 standard [Win08b].
Since the OS is like many other embedded operating systems highly customizable,
the support for real-time POSIX has to be activated by including the appropriate
components. The default minimal build of the system does not fully conform to
the standard and therefore differs in some of the provided facilities. For exam-
ple, instead of scheduling pthreads the unit of execution is the task, a slightly
lighter version of POSIX threads [Win08a]. Memory protection is provided for
processes which might contain multiple threads or tasks. It is recommended not
to mix POSIX functions with their classic VxWorks API counterparts.
Allocation of CPU time in VxWorks is based on a preemptive priority based
scheduler, meaning that the task with the highest priority is executed until a
higher priority task enters its ready state or the original task leaves its ready state.
This means that in a scenario with two tasks, which share the same priority,
one of them might block the other from executing. To solve this problem the
scheduler might be extended with a round robin based strategy, which partitions
CPU time between tasks with the same priority. VxWork provides 256 priority
levels, with 0 being the highest and 255 the one with the lowest priority. This
descending number scheme is inverted if support for POSIX is enabled since the
standard demands that a higher number also represents a higher priority [IEE08].
A common function of universal operating systems is the use of two different
modes for processes. A privileged mode, which allows direct access to hardware,
also known as kernel mode and the user mode which allows hardware access only
trough operating system APIs. In early versions of VxWorks only kernel mode
applications were supported. Although this approach has performance advan-
tages and seems therefore predestinated for real-time processes an error in a kernel
mode application might have a negative effect on the error free continuation of
the OS operation. Support for user mode applications is available since version 6
of VxWorks.
Newer versions of the OS have gained support for symmetrical multiprocessing
(SMP). The API for systems with multiple CPUs is basically the same as for
uniprocessor systems, differing only in support for some additional functions
and synchronization mechanisms. Functionality that is not applicable in systems
with real concurrent tasks is either translated in the corresponding function for
multiprocessor systems or not supported at all. CPU afnity, which describes
the possibility to assign tasks and interrupts to specic CPUs provides a facility
to give the developer additional control in VxWorks [Win08b]. The usually less
common feature of asymmetrical multiprocessing (AMP) is also provided by
running multiple instance of the OS on different CPUs.
Since VxWorks is designed to run on a large range of different devices a memory
management unit is not needed to execute the OS. However, advanced features
like for example SMP support and obviously memory protection are not available
on platforms without MMU [Win08b]. Another feature missing without a
memory management unit is the overlapped virtual memory model. Only the
at virtual memory model which assigns a specic portion of the memory to
each process is provided. This concept is better suited for hard real-time tasks
since it provides faster task switching and higher predictability. The overlapped
memory model allows processes to share space in the virtual memory. It can
be compared to the design used in universal operating systems like Linux or
Windows. It provides greater control and a more efcient use of the memory
since it reduces fragmentation.
6.2 Windows CE
Windows CE
2
is a real-time OS from the company Microsoft. Unlike other
Windows Embedded products it is not an architecture based on their desktop and
server line of operating systems but rather a distinctive OS built for the use in
small devices. It also serves as a base for other real-time operating systems from
the company, like for example, Windows Mobile. It supports the x86, MIPS, and
ARM processor architectures. Most of the OS is available under the condition of
a shared resource license, which gives developers the possibility to optimize and
2
sometimes also called Windows Embedded CE
modify the system to t their needs.
The OS uses a priority based scheduler with 256 priority levels and offers support
for up to 32000 processes with up to 2GB virtual memory available for each of
them
3
. Processes can be preempted, allowing the system run multiple applica-
tions concurrently. Scheduling is based on threads, meaning that the OS allocates
processing time to each thread according to its given priority. All priorities
between 0 and 247 are reserved for real-time use, while the remaining eight are
intended to be used by threads without specic deadlines. Threads with the same
priority are scheduled in round robin style [Cor10b]. To gather more control
over the scheduling, the length of the allocated processing time for each thread
can be changed individually.
Windows CE supports priority inheritance [Kop97], when using mutexes and
critical sections in conjunction with differently ranked threads to address the
problem of priority inversion [Cor10a]. However, since priority inheritance
might lead to missed deadlines because of the unbounded delay an inverted thread
causes, it is recommended to ensure that no priority inversion condition occurs.
The way interrupts are processed distinguishes Windows CE from other real-time
operating systems [Exp09]. Rather than incorporating them directly via a service
routine they are usually handled by an interrupt servicing thread (IST) written by
the driver developer. This thread is, if the corresponding interrupt occurs, sched-
uled according to its priority. This method has certain advantages, one being that
all system calls are available for the development of the IST. The disadvantage of
this approach is that a task with critical timing might miss its deadline, if a higher
priority task blocks the execution of the interrupt servicing thread. For time
critical cases, it is also possible to treat interrupts at the OEM Adaption Layer
(OAL), which is a thin software layer specic for a certain hardware platform
that resides between the hardware and the kernel. It deals with device specic
functions, like timers, interrupts, and I/O devices.
Device drivers in Windows CE are either executed in user or kernel space to
optimize them either for speed or safety. Applications on the other hand are
executed exclusively in user mode making the OS less prone to be inuenced by
errors in them. This behaviour is different compared to other (hard) real-time
systems like VxWorks where real-time processes are usually executed in kernel
mode to shorten the response time of the system.
3
as of Windows CE 6.0 [Cor10c, Cor09]
6.3 Linux
Section 3 is an explanation of why real-time computing is so hard to
integrate with non-realtime computing and why obvious methods
like making the standard kernel directly support realtime are
doomed to failure.
Victor Yodaiken [Yod99]
Like the desktop and server landscape which is lled with different distributions
of GNU/Linux for different purposes, there is not only one but many different
versions of Linux based real-time operating systems.
Figure 4 shows that there are two basic approaches to construct a real-time en-
abled Linux system. Both methods apply to other general purpose operating
systems too and were mentioned before in section 4.3.
Figure 4: Different approaches to real-time under Linux
Linux Kernel
Core Modication Dual Kernel
Kernel
Preemption
RTLinux Xeomai RTAI
Preemtible
CONFIG_PREEMPT
Realtime
CONFIG_PREEMPT_RT
High
Resolution
Timers
Voluntary
CONFIG_PREEMPT_
VOLUNTARY
CLinux
No MMU
POSIX
Support
Deadline
Scheduling
RT Patches
Earliest
Deadline
First
RT POSIX
Scheduling
Priority
Inheritance
IRQ
Threading
Since the Linux kernel is a rather large piece of softwarekernel version 2.34
consists of over 10 million lines of code [Lee10]the rst attempt to bring real-
time support to the OS was focused on a dual kernel approach [Bar97]. This
means basically that a real-time OS runs Linux as its lowest priority task. The
changes to the Linux kernel to achieve this are relatively small
4
and the real-time
core helps to provide the means to guarantee the timely execution of task even
with hard deadlines.
4
e.g., for RTAI 3.8 on the x86 architecture and kernel version 2.32.2 about 8000 lines of code
need to be changed
This approach has of course some drawbacks. The loose coupling of the real-
time executive and Linux means usually that drivers have to be adapted or even
rewritten from scratch to t the requested real-time characteristics and also the
driver model of the real-time OS. The real-time OS itself is usually implemented
as Linux kernel module and provides services typical for this kind of operating
systems, which include for example, periodic execution of tasks and interprocess
communication.
An other strategy to bring better real-time support to Linux is to modify the
kernel directly. Efforts in this area have been made to
support CPUs without a memory management unit (CLinux),
to make kernel code preemptible (real-time preemption patch),
offer high resolution timers,
and implement deadline scheduling (Earliest Deadline First) [FTS09].
The improvements in this regions have brought soft real-time support to Linux.
The company MontaVista, which is also largely involved in bringing the support
for the features mentioned before to the kernel, even claims that native hard
real-time tasks are possible in their Linux distribution [Dev05].
The next sections we will further explain the core modications examining
CLinux and the real-time preemption patch. Then a section will describe
Xenomai, as an example of a dual kernel system.
6.3.1 CLinux
The CLinux project was founded in 1998 to bring Linux support to the Mo-
torola Dragonball CPUs. This processor family is based on the 68k processor
core but did, unlike its predecessor, not contain an MMU. The standard Linux
kernel relies on the address translation provided by this hardware unit. To adapt
the kernel to run on systems without memory management unit CLinux differs
in certain areas from a standard Linux kernel. Table 2 lists some of the most
important differences [Opd09].
CLinux has over the years gained support for other architectures beside the
Dragonball CPUs and was successfully ported to digital audio players, VoIP
telephones, and many other devices. As of today, most of the code is part of the
mainline Linux kernel sources [Ung05].
Table 2: Differences between the standard Linux kernel and CLinux
Standard Linux Kernel CLinux
Memory Protection Yes No
Memory Space virtual memory space for
every application
single address space shared
by all applications
Application Stack auto growing xed size (congured at
compile time)
Process Creation fork(), vfork() only vfork()
Binary Application
Format
ELF (Executable and Link-
able Format)
BFLT (Binary Flat For-
mat)
For real-time applications CLinux offers some advantages over a standard kernel.
One of it is the faster context switch time on certain processor architectures. For
example, if the standard kernel is used on an ARM9 processor the whole cache
has to be ushed and invalidated on a context switch between user processes
since it is based on virtual memory addresses [CY04]. In CLinux, where all
applications share the same address space, this is not the case since the content of
the cache is valid for all processes.
The absent virtual memory management does of course imply certain disadvan-
tages, the most apparent being the restriction to be only able to use the physical
memory available, which has to be shared between all running applications. This
can lead to memory fragmentation, resulting in the inability to allocate enough
contiguous memory. To keep memory consumption down CLinux features
kmalloc2, a memory allocator which has a slightly different behaviour compared
to the standard one. It allocates only blocks of size 2
n
Bytes till the page size of
4KB and then increases the size of allocated memory only by the size of a single
page. This means that for a program which has a size of 85KB only 88KB would
be reserved instead of 128KB which kmalloc would allocate.
Since CLinux is designed to run on embedded system, which do not support
an MMU and usually are very limited in terms of storage, a C standard library
specically designed to t this two properties was created. Under the name
CLibC it began rst as a side project and is now developed independent of
CLinux. Another offspring of the CLinux kernel patches is the corresponding
distribution under the name Clinux-dist. With BusyBox it features, like many
other small Linux distributions, a single shell utility combining tiny versions of
many standard unix tools adapted for the use in embedded systems.
While CLinux is designed with small resource usage in mind, predictability is not
an explicit goal of the project. Therefore the OS is best used in embedded systems
which only rely on soft deadlines, like for example multimedia appliances.
6.3.2 Real-Time Patch Set
In the course of an heated debate one of the participants stated: Its
impossible to turn a General Purpose Operating System into a Real-
Time Operating System. Period. I was smiling then as I had already
proven, together with Doug Niehaus from Kansas University, that it
can be done even if it violates all or at least most of the rules of
the academic OS research universe.
Thomas Gleixner [Gle10]
One disadvantage of a monolithic kernel compared to a microkernel, considering
real-time performance, is the long time the operating system might spend exe-
cuting uninterruptible kernel code. Consequently an application with stringent
timing might miss deadlines waiting for a CPU to nish the execution of such an
uninterruptible section.
The Linux kernel was, in its infancy, designed to run on computers with a single
CPU. To prevent other programs from intercepting a critical section interrupts
were disabled before code sections which should be protected and reenabled
afterwards. On systems with multiple CPUs this strategy alone is not feasible.
Therefore the big kernel lock (BKL) [Cor04] was introduced. This lock takes care
that the kernel executes only on one CPU at the same time.
Today many ne grained locks are responsible for the protection of certain areas
in the Linux kernel, although the two methods for locking lock_kernel respec-
tive unlock_kernel for unlocking the BKL can still be found in some parts of
the Linux sources [And10].
Some of the current kernel locking primitives use busy waiting for accessing
resources [Lov02]. This means that they try to acquire a lock by continuously
checking for its availability. Although this primitives, called spinning locks,
should be used only for relatively small code sections, where a fast access of the
lock is probable, they nevertheless add latency and therefore impact the real-time
performance of the kernel.
To modify these spinning locks many approaches were developed over time. One
of the latest is the Real-time preemption patch [Mol04, LF10]. It auto-detects
the type of lock and converts spin locks and reader/writer locks (two forms of
spinning locks) to preemptible real-time mutexes (rt_mutex). These locks also
use priority inheritance to protect against the problem of lower priority processes
blocking the execution of higher priority tasks.
Some sections in the kernel, like for example the scheduler code, still need
atomic execution. Therefore the locks in this areas are explicitly marked for
non-conversion in the patch. To still create non-preemptible locks manually, the
new arch_spinlock_t (formerly raw_spinlock_t) [Gle09] type is introduced
which can be used instead of spinlock_t and rw_lock.
Another feature of the real-time patch is the conversion of interrupt service rou-
tines to threads [Edg08, Gle08]. Locking functions, which normally rely on dis-
abling of interrupts, for example spin_lock_irq() and spin_lock_irqsave()
are afterwards also preemptible. This helps further increasing the responsiveness
of the system.
The changes described above are quite fundamental. Their development is there-
fore maintained in a repository outside the mainline kernel known as realtime
tree or -rt branch. Other, less intrusive, features developed under this tree have
already found their way into the mainline kernel. These changes include options
for voluntary preemption of the kernel and also an overhaul of the timing system,
to allow the use of ne grained timers (high resolution timers).
6.3.3 Xenomai
Thanks to the Linux kernel developers for such a useful idle task and
thanks to the RTLinux users for being so enthusiastic and brave and
for contributing code, ideas, and interesting stories.
Victor Yodaiken [Yod99]
The rst steps to bring real-time support to Linux were taken in 1995. Researchers
at the New Mexico Institute of Technology modied the general purpose OS
to run as the lowest priority task of a small real-time executive. An interrupt
emulation layer protects the real-time nucleus from interference by Linux. To
keep the system predictable, Linux is not allowed to disable interrupts and can be
preempted anytime [Yod99]. The commands to disable and enable interrupts are,
for this purpose, replaced by macros which notify the emulation layer. The layer
stores if interrupts in Linux are enabled or disabled in a variable. In the case of
an interrupt this variable is checked and according to its state the interrupt han-
dler is either called directly or marked for later execution if interrupts are disabled.
The RealTime Application Interface for Linux (RTAI) is a fork of RTLinux
started at the polytechnic university of Milan [Yod02]. It added support for a
periodic conguration of timers. This helps to reduce overhead for timer repro-
gramming in real-time systems where actions in the time domain share a common
period. Software which is dependent on periods not a multiple of each other can
still use the one-shot timing mode already offered by RTLinux. RTAI also added
functionality found in PCDOS-DIAPM-RTOS, the operating system previously
used at the university of Milan [Man99].
In 2001 Xenomai was introduced. Under the name Xenodaptor, it started as an
effort to ease the porting of applications from classic real-time operating systems,
such as pSoS+, VxWorks, and VRTX to Linux. To support this goal Xenomai
provides services of the mentioned operating systems under Linux. The emula-
tion layer offering the application programming interface of a certain real-time
operating system or a portability standard such as ITRON is called skin. Skins
rely on the API of a small real-time nucleus. The idea behind this design is that
the services provided by real-time operating systems are very similar and only
differ in details. While for example nearly every RTOS offers priority based
scheduling, the number of priorities and the order of them(increasing, decreasing)
differs between the implementations. Figure 5 shows the skins implemented by
Xenomai. Besides the APIs of classic real-time operating systems and portability
standards Xenomai also offers the native and the RTDM skin (real-time driver
model) [Kis05]. The rst API provides services specically designed for new
applications taking use of the special capabilities provided by Xenomai, while the
latter offers a way to implement real-time drivers offering better predictability
than the standard drivers provided by the Linux kernel.
Figure 5: Logical Layers and available skins in Xenomai
Adeos
Hardware Abstraction Layer (HAL)
Real-time nucleus
Native ITRon POSIX VxWorks RTDM RTAI pSOS+
The rst version of Xenomai was intended to provide their real-time services on
top of one of the two other real-time solutions for Linux (RTLinux, RTAI). Soon
after the start of the project however, Xenomai was built on top of Adeos (Adap-
tive Domain Environment for Operating Systems) to gain predictable interrupt
latency [Xen10].
Adeos [Yag01, Lif09] is a nanokernel which allows to share hardware resources
between software entities. Each entity, usually an operating system, is called
a domain. Adeos uses the concept of an event pipeline to share interrupts
between these domains. According a static priority Adeos distributes them down
the pipeline to the entities. Instead of disabling interrupts each domain is able to
stall the pipeline, effectively delaying interrupt distribution to the domains after
itself in the pipeline. Figure 6.3.3 shows the available domains in Xenomai.
Figure 6: Adeos domains in Xenomai
Xenomai
(Primary Domain)
Interrupt Shield
Linux
(Secondary Domain)
Interrupts
The design of Adeos is OS independent. However, since the following paragraphs
will explain Xenomai more extensively the design of the adaptive domain envi-
ronment under Linux is assumed. The kernel patch bringing Adeos support to
Linux is also known as I-pipe (Interrupt Pipe). Linux has, as root domain, the
special role of loading other domains, which are implemented as kernel modules.
I-pipe does not only distribute interrupts but also system events down the pipeline.
System events are synchronous notication of traps, exceptions or actions per-
formed by Linux. In contrast to interrupts they cannot be stalled since system
events need immediate response by their handler.
Figure 6.3.3 already showed that besides Linux usually also two other domains
are active in a Xenomai based system: Xenomai (the real-time nucleus) itself
and the optional interrupt shield. The role of the primary domain implies that
Xenomai is always in control of the system. This means that interrupts arrive
without delay and that the real-time nucleus is always able to preempt any regular
Linux activity [Xen06].
The Xenomai nucleus is responsible for scheduling the real-time tasks in the
system. This tasks can be located in either user space (user context) or kernel
space (system context). The skins provide an API that, independent of the con-
7 Summary
text of an application, offers the same set of real-time services. Which path a
developer chooses depends on the attributes of the real-time task. While kernel
space application provide faster response, user space applications allow the use of
regular Linux APIs and offer memory protection. Since real-time task in kernel
space are always in the control of the Xenomai nucleus they offer hard real-time
performance. On the other hand user space real-time tasks, also commonly called
Xenomai threads, can also call regular Linux services. For that purpose they are
switched to the secondary domain, the task is then added to the active Linux task
list and Linux inherits the priority of the real-time task. Xenomai then schedules
the whole Linux kernel according to that priority. Priorities of the native API
are consistent across domains. A high priority Linux application can therefore
preempt a lower priority real-time application in the secondary domain. After a
call of a real-time service a Xenomai thread switches back to the primary domain,
if the invoked system call requires this [Xen06].
Tasks in the secondary domain might be preempted by interrupt activity in
the Linux domain. To alter this behaviour the optional interrupt shield can be
enabled. It acts as an intermediate domain and stalls interrupts if a real-time task
is active inside Linux. Therefore it allows tasks that call Linux services to run
without preemption until a kernel service waits for an I/O event.
A goal of Xenomai is to keep the changes to the mainline kernel as unintrusive as
possible. The developers have taken care that Xenomai works with a real-time
patched kernel, which improves the response times in the secondary domain.
With the real-time preemption patches and other improvements considering
real-time performance of the kernel in mind the project also aims to provide their
APIs on a single Linux kernel system. This effort is developed under the name
Xenomai/Solo and will be merged with the mainline project in the next major
release, Xenomai 3. However, since a regular Linux system without Adeos does
not provide hard real-time performance, the developers will also continue their
work on the current dual kernel solution.
7 Summary
The beginning of this text showed that general purpose operating system and real-
time operating systems differ in certain areas. While the rst group is optimized
for average performance the latter has to be predictable and is therefore optimized
for worst case performance. A direct consequence of this design approach is the
scheduling policy. Many RTOSes assign processor time solely based on priorities,
meaning that they always execute the runnable task with the highest priority
References
even if this means that a lower priority process never gets any CPU time. The
developer has to either choose the priorities of tasks directly, or in system which
support deadline based scheduling, indirectly by choosing periods and deadlines
for applications.
After the introduction and a short section about the history of real-time oper-
ating and embedded operating systems another section showed that the design
approach of an RTOS can be used to categorize it into one of three groups. The
two most popular approaches are to either start from scratch to implement an OS
specically built for real-time purpose or to modify a general purpose operating
system.
In the next section portability standards were introduced. They dene certain
functionality usually provided in real-time operating systems and help thereby to
port applications from one OS to another. One of the most prominent standards,
supported by many operating systems, is the real-time part of POSIX. It denes
four proles for devices ranging from basic machines with only one CPU and no
MMU to computers with multiple cores.
Finally some example showed howsome typical real-time operating systems work.
Windows CE and VxWork were taken as examples of OSes specically built for
the use in embedded systems while Linux was chosen as a general purpose OS,
which needs some modications to serve real-time tasks.
7 References
[AB90] N. Audsley and A. Burns. Real-Time System Scheduling. 1990.
[And10] Jeremy Andrews. Linux: Removing The Big Kernel Lock. http://
kerneltrap.org/Linux/Removing_The_Big_Kernel_Lock2, April
2010.
[Bar97] Michael Barabanov. A Linux-based Real-Time Operating System.
Masters thesis, New Mexico Institute of Mining and Technology,
Socorro, New Mexico, June 1997.
[Con05] Artist FP5 Consortium. Real-Time Operating Systems. In Bruno
Bouyssounouse and Joseph Sifakis, editors, Embedded Systems Design,
volume 3436 of Lecture Notes in Computer Science, pages 258286.
Springer Berlin / Heidelberg, 2005.
References
[Cor04] Jonathan Corbet. The Big Kernel Lock lives on. http://lwn.net/
Articles/86859/, May 20004.
[Cor09] Microsoft Corporation. The History of Microsoft Windows CE
- Windows CE 6.0 - HPC Factor. http://www.hpcfactor.com/
support/windowsce/wce6.asp, October 2009.
[Cor10a] Microsoft Corporation. Priority Inversion. http://msdn.
microsoft.com/en-us/library/ee482778.aspx, January 2010.
[Cor10b] Microsoft Corporation. Scheduling a Thread. http://msdn.
microsoft.com/en-us/library/ee482789.aspx, January 2010.
[Cor10c] Microsoft Corporation. Windows CE Priority Levels. http://msdn.
microsoft.com/en-us/library/bb22761.aspx, February 2010.
[Cus93] Helen Custer. Inside Windows NT. Microcomputer Applications,
Suisun City, CA, USA, 1993.
[CY04] Hyok-Sung Choi and Hee-Chul Yun. Context Switching and IPC
Performance Comparison between uClinux and Linux on the ARM9
based Processor. November 2004.
[Dev04] Linux Devices. MontaVista boasts banner year, claims embedded
Linux leadership. http://www.linuxfordevices.com/c/a/News/
MontaVista-boasts-banner-year-claims-embedded-Linux-
leadership/, September 2004.
[Dev05] Linux Devices. MontaVista touts native hard real-time Linux.
http://www.linuxfordevices.com/c/a/News/MontaVista-
touts-native-hard-realtime-Linux/, August 2005.
[Dev07] Linux Devices. Snapshot of the embedded Linux market.
http://www.linuxfordevices.com/c/a/Linux-For-Devices-
Articles/Snapshot-of-the-embedded-Linux-market-April-
27/, April 2007.
[Edg08] Jake Edge. Moving interrupts to threads. http://lwn.net/
Articles/3243/, October 2008.
[Exp09] Dedicated System Experts. Windows Embedded CE6.0 R2 on an x86
Platform, March 2009.
[Fre08] Free Software Foundation, Inc. eCos Reference Manual, 2008.
References
[FSH
+
01] L. Fernando Friedrich, John Stankovic, Marty Humphrey, Michael
Marley, and John Haskins. A Survey of Congurable, Component-
Based Operating Systems for Embedded Applications. IEEE Micro,
21(3):5468, 2001.
[FTS09] Dario Faggioli, Michael Trimarchi, and Claudio Scordino.
SCHED_EDF scheduling class. http://lwn.net/Articles/
353797/, September 2009.
[Gle08] Thomas Gleixner. [RFC patch 0/5] genirq: add infrastructure for
threaded interrupt handlers. http://lwn.net/Articles/3189/,
October 2008.
[Gle09] Thomas Gleixner. Linux Kernel Commit: Convert
raw_spinlock to arch_spinlock. http://git.kernel.org/
?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=
445c89514be242b1b856d5bdc1b72adeb5c, December 2009.
[Gle10] Thomas Gleixner. Realtime Linux: academia v. reality. http://lwn.
net/Articles/397422/, July 2010.
[IEE99] IEEE Standard for Information Technology - POSIX(R) Ada Lan-
guage Interfaces - Part 1: Binding for System Application Program
Interface (API) - Amendment 2: Protocol-Independent Interfaces.
IEEE Std 1003.5, 1999 Edition, pages 1890, 1999.
[IEE04a] IEEE Standard for Information Technology - Portable Operating
System Interface (POSIX) - Part 26: Device Control Application
Program Interface (API) [C Language]. IEEE Std 1003.26-2003, 2004.
[IEE04b] IEEE Standard for Information Technology - Standardized Applica-
tion Environment Prole (AEP)-POSIX Realtime and Embedded
Application Support. IEEE Std 1003.13-2003 (Revision of IEEE Std
1003.13-1998), pages i164, 2004.
[IEE08] IEEE Standard for Information Technology - Portable Operating
System Interface (POSIX) Base Specications, Issue 7. IEEE Std
1003.1-2008 (Revision of IEEE Std 1003.1-2004), pages c13826, 1 2008.
[Kis05] Jan Kiszka. The Real-Time Driver Model and First Applications. In
7th Real-Time Linux Workshop, Lille, France, 2005.
[Kop97] Hermann Kopetz. Real-Time Systems: Design Principles for Distributed
Embedded Applications. Kluwer Academic Publishers, Norwell, MA,
USA, 1997.
References
[Lab92] Jean J. Labrosse. C/OS: The Real-time Kernel. R & D Publications,
Inc., Lawrence, KS, USA, 1992.
[Lee10] Thorsten Leemhuis. Whats new in Linux 2.6.34. http://www.h-
online.com/open/features/What-s-new-in-Linux-2-6-34-
1122.html?page=4, May 2010.
[LF10] Robert Schwebel Luotao Fu. RT PREEMPT Howto. https://rt.
wiki.kernel.org/index.php/RT_PREEMPT_HOWTO, March 2010.
[Lif09] Life With Adeos. http://www.xenomai.org/documentation/
branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf, October
2009.
[Lov02] Robert Love. Kernel Locking Techniques. http://www.
linuxjournal.com/article/5833, August 2002.
[Man99] Paolo Mantegazza. DIAPM RTAI for Linux: WHYs, WHATs and
HOWs. Real Time Linux Workshop, December 1999.
[McK05] Paul E. McKenney. Attempted summary of "RT patch acceptance"
thread, take 2. http://lkml.org/lkml/25/7/11/118, July 2005.
[Mic99] Microware. OS-9 Version 2.4 Manual, 199*.
[Mil09] Milestones in embedded systems design. http://www.embedded.
com/timeline/, November 2009.
[Mol04] Ingo Molnar. Linux Kernel Mailing List: CON-
FIG_PREEMPT_REALTIME, Fully Preemptible Kernel,
VP-2.6.9-rc4-mm1-T4. http://lkml.org/lkml/24/1/11/121,
October 2004.
[Opd09] Michael Opdenacker. Introduction to uClinux. http://free-
electrons.com/docs/uclinux/, September 2009.
[Rom05] Dieter Rombach. Software-Engineering eingebetteter Systeme, chap-
ter 14. Spektrum-Akademischer Vlg, May 2005.
[Sch07] Peter Scholz. Softwareentwicklung eingebetteter Systeme: Grundlagen,
Modellierung, Qualittssicherung (Xpert.press), chapter 3. Springer-
Verlag New York, Inc., Secaucus, NJ, USA, 2007.
[Sim99] David E. Simon. An Embedded Software Primer. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 1999.
References
[SL06] Claudio Scordino and Giuseppe Lipari. Linux and Real-Time: Cur-
rent Approaches and Future Opportunities. October 2006.
[SR04] John A. Stankovic and R. Rajkumar. Real-Time Operating Systems.
Real-Time Systems, 28(2):237253, November 2004.
[T-E10] T-Engine Forum. http://www.t-engine.org/, March 2010.
[TTP05] TTP OS Time-Triggered Operating System with TTP Sup-
port. http://www.tttech.com/fileadmin/content/white/1-3-
5-2/TTTech-TTP-OS.pdf, 2005.
[Tur05] Jim Turley. Embedded systems survey: Operating systems up for
grabs. http://www.embedded.com/columns/surveys/163759?
_requestid=387451, May 2005.
[uC/09] C/OS-III Real-Time Operating Systems, May 2009.
[Ung05] Greg Ungerer. uClinux merged into main line Linux ker-
nel sources. http://www.ucdot.org/article.pl?sid=2/11/5/
32427, November 2005.
[VxW94] Lord of the Toasters. http://www.wired.com/wired/archive/6.
9/wind_pr.html, September 1994.
[VxW09] Wind River VxWorks 6.x. http://www.windriver.com/products/
run-time_technologies/Real-Time_Operating_Systems/
VxWorks_6x/, 2009.
[Wik09a] The Free Encyclopedia Wikipedia. Notable products using
VxWorks. http://en.wikipedia.org/wiki/Vxworks#Notable_
products_using_VxWorks, November 2009.
[Wik09b] The Free Encyclopedia Wikipedia. Operating Systems. http://en.
wikipedia.org/wiki/Operating_systems, July 2009.
[Wik09c] The Free Encyclopedia Wikipedia. Timeline of Operat-
ing Systems. http://en.wikipedia.org/wiki/Timeline_of_
operating_systems, October 2009.
[Wik10] The Free Encyclopedia Wikipedia. Control system. http://en.
wikipedia.org/wiki/Control_systems, October 2010.
[Win08a] Wind River Systems, Inc., 500 Wind River Way, Alameda, CA 94501,
USA. VxWorks Applications Programmers Guide 6.7, 2008.
References
[Win08b] Wind River Systems, Inc., 500 Wind River Way, Alameda, CA 94501,
USA. VxWorks Kernel Programmers Guide 6.7, 2008.
[Xen06] A Tour of the Native API. http://www.xenomai.org/
documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-
C.pdf, March 2006.
[Xen10] Xenomai:History. http://www.xenomai.org/index.php/
Xenomai:History, July 2010.
[Yag01] Karim Yaghmour. Adaptive Domain Environment for Operating
Systems. February 2001.
[YDBI] Victor Yodaiken, Cort Dougan, Michael Barabanov, and Fsmlabs Inc.
RTLinux/RTCore dual kernel real-time operating system.
[Yod99] Victor Yodaiken. The RTLinux Manifesto. 1999.
[Yod02] Victor Yodaiken. A reply on the RTLinux discussion. http://lkml.
indiana.edu/hypermail/linux/kernel/25.3/865.html, May
2002.

Embedded Operating Systems

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Embedded Operating Systems

Enviado por

Direitos autorais:

Formatos disponíveis

Real-Time and Embedded

Você também pode gostar