RT Linux - Aims

Achieve hard RT performance.

High level of timer precision in scheduling.
To provide low interrupt latency.
Customized scheduling.
Minimal changes to the Linux kernel so that the full range of
OS services are available.
How is the real-time kernel given higher priority
than Linux kernel?
Basically, an operating system is driven by interrupts, which can be considered as the heartbeats of a computer:
 All programs running in an OS are scheduled by a scheduler which is driven by timer interrupts of a clock to
reschedule at certain times.
 An executing program can block or voluntary give up the CPU in which case the scheduler is informed by means of a
software interrupt (system call).
 Hardware can generate interrupts to interrupt the normal scheduled work of the OS for fast handling of hardware.
RT Linux uses the flow of interrupts to give the real-time kernel a higher priority than the Linux kernel:
 When an interrupt arrives, it is first given to the real-time kernel, and not to the Linux kernel. But interrupts are stored
to give them later to Linux when the real-time kernel has finished.
 As first in row, the real-time kernel can run its real-time tasks driven by these interrupts.
 Only when the real-time kernel is not running anything, the interrupts which were store are passed on to the Linux
kernel.
 As second in row, Linux can schedule its own processes driven by these interrupt.
Hence, when a normal Linux program runs and a new interrupt arrives:
 it is first handled by an interrupt handler set by the real-time kernel;
 the code in the interrupt handler awakes a real-time task;
 immediately after the interrupt handler, the real-time scheduler is called ;
 the real-time scheduler observes that another real-time task is ready to
run, so it puts the Linux kernel to sleep, and awakes the real-time task.
Hence, a special way of passing of the interrupts between real-time kernel
and the Linux kernel is needed. Each flavor of RT Linux does this is in its own
way. Xenomai uses an interrupt pipeline from the Adeos project. For more
information, see also Life with Adeos.
 How Real-time Linux work

The general idea of Real-time (RT) Linux is that a small real-time kernel
runs beneath Linux, meaning that the real-time kernel has a higher
priority than the Linux kernel.
 Real-time tasks are executed by the real-time kernel, and normal Linux
programs are allowed to run when no realtime tasks have to be executed.
Linux can be considered as the idle task of the real-time scheduler.
When this idle task runs, it executes its own scheduler and schedules the
normal Linux processes. Since the real-time kernel has a higher priority, a
normal Linux process is preempted when a real-time task becomes ready
to run and the real-time task is executed immediately.
Linux architecture
Realtime Linux - Xenomai architecture
 MicroC/0S II

 Micro COS-II. For non-commercial use, RTOS Micro COS-II is also a freeware.
 Jean J. Labrosse designed it in 1992 and nowadays Micro COS-II is well developed for a
number of applications.
 It is available from Micrium Its name μCOS-II is derived from Micro-Controller Operating
System. It is also popularly known as MUCOS or MicroCOS or UCOS. Micrium describes
MUCOS as portable, ROMable, scalable, preemptive, real-time and multitasking kernel.
 MUCOS has been used in over thousands of applications, including automotive, avionics,
consumer electronics, medical devices, military, aerospace, and networking, and systems-on-a-
chip development. MUCOS has an elegant code and is said to offer best high
quality/performance ratio. Its source code has been certified by Department of Defense, USA
for use in Avionics and in medical applications.
MUCOS codes are in C and a few CPU-specific modules are in the assembly. Its code
ports on many processors that are commonly used in the designing of embedded
systems. MUCOS is real-time kernel with additional support as follows.
1. C/BuildingBlocks [an embedded system building blocks (software components) for
hardware
peripherals, e.g., clock (μC/Clk) and LCD (μC/LCD)].
2. μC/FL (an embedded flesh memory loader).
3. μC/FS (an embedded memory file system).
4. μC/GUI (an embedded GUI platform).
5. μC/Probe (a real-time monitoring tool).
6. μC/TCP-IP (an embedded TCP/IP stack).
7. μC/CAN (an embedded controller area network bus).
8. μC/MOD (an embedded modbus).
9. μC/USB device and μC/USB host (embedded USB-devices framework).
 MUCOS has 10,000 plus lines of codes. There are two types of source files. Master header file
includes the ‘#include’ preprocessor commands for all the files of both types. It is referred as
‘includes.h’.
Every C file has the command, #include‘INCLUDES.H’.
1. Processor-dependent source files: Two header files at the master are the following: (i) os_cpu.h is
the processor definitions header file. (ii) The kernel building configuration file is os_cfg.h. Further,
two C files are for ISRs and RTOS timer, specifying os_tick.c and processor C codes os_cpu_c.c.
Assembly codes for the task switching functions are at os_cpu_a.s12 (for 68HC12 microcontroller).
For other microcontrollers, there are similar assembly code files, for example, os_cpu_a.s51 for 8051.
2. Processor-independent source files: Two files, MUCOS header (included in master) and C files, are
ucos_ii.h and ucos_ii.c. The files for the RTOS core, timer and task files are os_core.c, os_time.c and
os_task.c. The memory-partitioning, semaphore, queue and mailbox codes are in os_mem.c,
os_sem.c, os_q.c and os_mbox.c, respectively.
 Vx Works
 VxWorks from WindRiver® VxWorks is a high-performance, Unix-like, scalable
RTOS, and support to ARM, ColdFire, MIPS, Pentium, Intel X-Scale, Super H
and other popular processors for embedded system design.

 VxWorks is supported with powerful development tools that make it easy and
efficient to use.
 VxWorks supports many advanced processor architectures. VxWorks supports
‘Device Software Optimization’,which is said to be a new methodology that
enables the development and the running of the device software
 faster, better and more reliably. VxWorks has been found to be the most popular
RTOS in a survey in 2006
VxWorks provides for the following.
1. Multitasking environment using scheduler which supports IEEE standard POSIX scheduler and which
also supports the in-house developed scheduler.
2. Supports ability to run two concurrent OSs on a single processing layer.
3. Multiple file systems (Section 8.6.2) and systems that enable advanced multimedia functionality.
4. Synchronization using a full range of IPC options (Section 7.9) that includes. (i) event-signalling
flag, (ii) mutually exclusive access using resource key (mutex), (iii) counting mechanism using three
types of semaphores in the tasks, (iv) queue, (v) socket and ISRs and includes POSIX standard
semaphore and other IPCs (Sections 7.8.3, 7.9 to 7.15 and 8.12). Also supports real-time processes
IPCs. It also support openSource TIPC (transparent inter-process-communication) protocal for network
and clustered systems environment. [PTTS 1.1 is latest release in December, 2007 for Linux and
VxWorks.]
5. Different context saving mechanism for the tasks and ISRs (tasks have separate TCBs and stacks, and
ISRs use a common stack due to nesting of the calls).
6. Watchdog timers.
7. Virtual IO devices including pipes and sockets (Sections 7.14 and 7.15).
8. Virtual memory management functions.
9. Power management functions that enhance the ability to control power consumption, and automatic
detection and reporting of common memory and other errors.
10. Interconnect functions that a support large number of protocols, including IPv4/IPv6 dual mode stack
ready APIs.
VxWorks TCB saves the following task information for each task.
1. Control information for the OS that includes priority, stack size, state and options.
2. CPU context of the task that includes PC, SP, CPU registers and task variables.
VxWorks also provides:
1. Pipe drivers for IPCs and pipe is an IO virtual device.
2. Network transparent sockets.
3. Network drivers for shared memory and Ethernet.
4. RAM ‘disk’ drivers for memory-resident files.
5. Drivers for SCSI, keyboard, VGA display, disk and parallel port of a computer system, HDD, diskette,
tapes, keyboard and displays.
6. VxWorks 6.x provisions for processor abstraction layer. It enables application system design by user
when using new versions of a processor architecture.
VxWorks IO system also includes the POSIX standard asynchronous IOs and UNIX standard buffered
IOs. It also provides for simulator (VxSim) (Section 14.2.3), software logic analyser (WindView), Code
coverage study tool, MemScope, StethoScope (Section 1.4.7 Table 1.2) network facilities between VxWorks
and TCP/IP network systems. For many other facilities, we can refer to VxWorks programmer’s guide and
VxWorks Network Programmer’s Guide provided with the product.
features of VxWorks that are essential in a sophisticated embedded system
design are as follows:
1. VxWorks is a scalable OS (only the necessary OS functions become part of the applications codes, thus having
reduced memory requirements). The run-time configurable feature gives a higher performance in VxWorks. The
functisons needed for task servicing, IPC and so on must be predefined in a configuration file included in the user
codes. Pre-emptive latency minimization is there as not all the functions are at the kernel (Section 8.1).
2. RTOS hierarchy includes timers, signals, TCP/IP sockets, queuing functions library, NFS, RPCs, Berkeley Port
and sockets (Section 7.15), pipes (Section 7.14), Unix-compatible loader, language interpreter, shell, debugging tools
and linking loader for Unix. (These are similar to system tasks. The scheduler runs these, as it runs the ISRs.)
3. For multitasking, like MUCOS, VxWorks employs a preemptive scheduler (Section 8.10.3). VxWorks is a
preemptive priority based scheduler. It provisions for 256 priority levels within 0 to 255. A task context saves fast
when the CPU access changes to a higher priority. However, VxWorks offers a flexibility that there can be a set of
tasks (different tasks of the same priority), which run in time-slice (round robin) mode (Section 8.10.2). Each task in
a set of tasks executing round robin runs for a given number of system-clock ticks and after timeout becomes the last
in a queue of the set. We can use
preemptive priority and time-slicing scheduling simultaneously. (Note: The preemption priority and POSIX FIFO
scheduling are identical).
4. Refer to Examples 9.19 and 9.20. The ISR interrupt flag was checked and reset for new interrupt in ISR_CharIntr
and the ISR passed a semaphore (message) to run the waiting task Task_ReadPortA. VxWorks RTOS schedules the
ISRs separately and has special functions for interrupt handling [Refer to Section 9.3.3 Table 9.10].
5. VxWorks has system-level functions for RTOS initiation and start, system clock ticks (interrupts) initiation
and the ISR functions, ISR connecting to interrupt vector and masking functions. Recall Sections and 8.10.3.
For the critical section (section of codes which access the shared resources or variables) in the ISRs, VxWorks
has the interrupts disabling and enabling functions that execute at entering and exiting the section,
respectively (semaphore pending functions as event-signalling flag, and counting should not be invoked in the
ISRs).
6. If a task is expecting a message from another task, which is being deleted by using the task delete function,
then RTOS inhibits the deletion when an option called ‘Deletion Safe’ is used.
7. VxWorks has task service functions (Table 9.8). VxWorks task creation (initiation) by itself does not make a
task in a list of active tasks. Active task means that it is in one of the three states; ready, running, or waiting
(blocking or pending). VxWorks not only has the task creating, running, waiting (blocking or pending till a time
out or till resource available), suspending (inhibiting task execution) and resuming, but also the functions for
task spawning (creating followed by activating). VxWorks also includes the task-pending cum suspending and
pending cum suspension with timeout functions. VxWorks also has the tasks, which have a state and an
inherited priority (Section 7.8.5).
8. VxWorks has task delay functions and task delaying cum suspending function (Section 9.3.2).
9. VxWorks has the shared memory allocation functions and bounded ring buffer allocation for sharing the
memory and buffers between the tasks and ISRs. To improve the performance of RTOS, VxWorks provides a
shared address in memory to all the tasks. This helps in fast access through the pointers. A pipe need not be
allocated a separate memory space. Of course, there is an attendant risk due to a possible illegal access.
10. VxWorks has IPC functions that are more sophisticated than MUCOS functions. Recall that MUCOS has
identical semaphore functions for event-signalling flags, resource-acquiring keys and counting semaphores.
Recall the use of the semaphore SemKey with OSSemPend and OSSemPost functions on SemKey. SemKey
was used as a resource-acquiring key by the various tasks in Examples 9.17 to 9.20. VxWorks provides for three
types of semaphores separately (POSIX-IPCs and TIPCs are additional).
11. VxWorks has special features for mutual exclusiveness in a critical region. We use a mutex semaphore for
the resource key when using VxWorks. [Only the task that takes the resource key through a mutex semaphore
can release (give or post) the key. No other task can release it. This provides mutual exclusiveness.] One type of
semaphore used as mutex has the following special features: (i) One task can be protected from being deleted
by any other task. Thus, unprotected deletion cannot occur when using a mutex semaphore function with the
deletion safe option. At mutex creation the option is selected to include the deletion protection. (ii) When a task
acquires the key using the mutex priority inversion can be prevented with the priority inversion safe option. The
priority assignment of high-priority task can now inherit (during execution of critical section) so that in case of
pre-emption by an intermediate priority task, the high-priority task does not get blocked (Section 7.4). This
prevents priority inversion situations during execution of the critical section.
12. The unlock ( ) and lock ( ) functions are available for the tasks and interrupts, for disabling other task but
not interrupts or enabling pre-emption (task switching) as alternative to resource locking by mutex semaphore.
13. The lock and unlock functions in VxWorks do not cause the priority inversion problem
(Sections 7.8.5 and 8.10.3). The priority first inherits and then returns to the original ones.
14. Let us recall Figure 7.4(a) in Section 7.7.6 to understand P and V mutex semaphores used for locking
the resources. VxWorks provides for P and V semaphore functions also.
15. Unlike MUCOS, VxWorks has no separate functions for the mailbox that distinguish the
mailbox from the message queue. VxWorks messages can be queued. It provides for sending
messages of variable length into the queues. (MUCOS queue functions permit a pointer only for a message and a
queue is an array of message pointers.) MUCOS messages can insert such that these
retrieve in the FIFO method or in the LIFO if message pointer is posted in the front instead of at the back
when a message is of higher priority. VxWorks also supports this post and post-front feature as in MUCOS.
There are additional special features with the message queues in VxWorks.
16. In addition to queues, VxWorks provides the IPCs through the pipe (Section 7.14) into which an ISR
or task can write by invoking functions for pipe open ( ). Task can read from a pipe by using open ( )
and read ( ) functions. A VxWorks pipe is a virtual IO device functions (Refer to Section 9.3.4).
17. The features of scheduler design compatible with POSIX 1003.1b can also be used. The POSIX
library can be included in VxWorks.
18. The timings taken by the various RTOS functions are similar to the ones given in Table 8.12.
The following subsections describe the specific VxWorks functions.
 What is Embedded Linux

 Linux itself is a kernel, but ‘Linux’ in day to day terms rarely means so. Embedded
Linux generally refers to a complete Linux distribution targeted at embedded devices.
There is no Linux kernel specifically targeted at embedded devices, the same Linux
kernel source code can be built for a wide range of devices, workstations, embedded
systems, and desktops though it allows the configuration of a variety of optional
features in the kernel itself.
 In the embedded development context, there can be an embedded Linux system
which uses the Linux kernel and other software or an embedded Linux distribution
which is a prepackaged set of applications meant for embedded systems and is
accompanied by development tools to build the system.
Types of embedded Linux systems
Embedded Linux systems are generally classified by criteria that would provide information about the
structure of the system. Thus it may be classified primarily on the basis of size and timing constraints.
Size:
Linux features a micro-kernel architecture which actually consumes very little memory of about 100 KB
which combined with the networking stack and a few basic utilities can fit in quite nicely in 500 K of
memory and can be adapted to work with very little RAM and ROM (as low as 256KB ROM and 512KB
RAM). A few examples of small footprint Embedded Linux are ETLinux, LEM, uClinux, uLinux,
ThinLinux etc. The physical size of an embedded system determines the capabilities offered by the
hardware. There are three broad categories of the embedded LINUX on the basis of size: small,
medium and large.
Small Systems:
· Low powered CPU
· > 4 MB of ROM (Normally NOR Flash-based)
· 8 to 16 MB RAM
Medium-Size Systems:
· Medium powered CPU
· > 32 MB RAM (NOR Flash-based mainly, sometimes NAND Flash based)
· 64-128 MB RAM
· (optional) NAND Flash -based secondary memory
· removable memory cards
Large-Size systems:
· powerful CPU/multiple CPUs
permanent storage
· large RAM
TinyOS
 It is an embedded, component-based operating system and platform for low-power wireless
devices, such as those used in wireless sensor networks (WSNs), smartdust, ubiquitous
computing, personal area networks, building automation, and smart meters. It is written in the
programming language nesC, as a set of cooperating tasks and processes.
 It began as a collaboration between the University of California, Berkeley, Intel Research, and
Crossbow Technology, was released as free and open-source software under a BSD license,
and has since grown into an international consortium, the TinyOS Alliance. TinyOS has been
used in space, being implemented in ESTCube-1.

 TinyOS code is statically linked with program code and compiled into a small binary, using a
custom GNU toolchain. Associated utilities are provided to complete a development platform for
working with TinyOS.
 Implementation

 TinyOS applications are written in the programming language nesC, a dialect of the C language optimized
for the memory limits of sensor networks. Its supplementary tools are mainly in the form of Java and shell
script front-ends. Associated libraries and tools, such as the nesC compiler and Atmel AVR binutils
toolchains, are mostly written in C.
 TinyOS programs are built of software components, some of which present hardware abstractions.
Components are connected to each other using interfaces. TinyOS provides interfaces and components for
common abstractions such as packet communication, routing, sensing, actuation and storage. TinyOS is fully
non blocking: it has one call stack. Thus, all input/output (I/O) operations that last longer than a few hundred
microseconds are asynchronous and have a callback. To enable the native compiler to better optimize across
call boundaries, TinyOS uses nesC's features to link these callbacks, called events, statically.
 While being non-blocking enables TinyOS to maintain high concurrency with one stack, it forces
programmers to write complex logic by stitching together many small event handlers. To support larger
computations, TinyOS provides tasks, which are similar to a Deferred Procedure Call and interrupt handler
bottom halves. A TinyOS component can post a task, which the OS will schedule to run later. Tasks are non-
preemptive and run in first in, first out order. This simple concurrencymodel is typically sufficient for I/O
centric applications, but its difficulty with CPU-heavy applications has led to developing a thread library for
the OS, named TOSThreads.
Android - Architecture

Android operating system is a stack of software components which is roughly

divided into five sections and four main layers as shown below in the
architecture diagram.
 Linux kernel

At the bottom of the layers is Linux - Linux 3.6 with approximately 115
patches. This provides a level of abstraction between the device hardware
and it contains all the essential hardware drivers like camera, keypad, display
etc. Also, the kernel handles all the things that Linux is really good at such as
networking and a vast array of device drivers, which take the pain out of
interfacing to peripheral hardware.
 Libraries

On top of Linux kernel there is a set of libraries including open-source

Web browser engine WebKit, well known library libc, SQLite database
which is a useful repository for storage and sharing of application data,
libraries to play and record audio and video, SSL libraries responsible for
Internet security etc.
 Android Libraries

This category encompasses those Java-based libraries that are specific to Android development.
Examples of libraries in this category include the application framework libraries in addition to
those that facilitate user interface building, graphics drawing and database access. A summary of
some key core Android libraries available to the Android developer is as
follows −
android.app − Provides access to the application model and is the cornerstone of all Android applications.
android.content − Facilitates content access, publishing and messaging between applications and application components.
android.database − Used to access data published by content providers and includes SQLite database management
classes.
android.opengl − A Java interface to the OpenGL ES 3D graphics rendering API.
android.os − Provides applications with access to standard operating system services including messages, system services
and inter-process communication.
android.text − Used to render and manipulate text on a device display.
android.view − The fundamental building blocks of application user interfaces.
android.widget − A rich collection of pre-built user interface components such as buttons, labels, list views, layout
managers, radio buttons etc.
android.webkit − A set of classes intended to allow web-browsing capabilities to be built into applications. Having
covered the Java-based core libraries in the Android runtime, it is now time to turn our attention to the C/C++ based
libraries contained in this layer of the Android software stack.
 Android Runtime

This is the third section of the architecture and available on the second layer
from the bottom. This section provides a key component called Dalvik
Virtual Machine which is a kind of Java Virtual Machine specially
designed and optimized for Android.
The Dalvik VM makes use of Linux core features like memory management
and multithreading, which is intrinsic in the Java language. The Dalvik VM
enables every Android application to run in its own process, with its own
instance of the Dalvik virtual machine.
The Android runtime also provides a set of core libraries which enable
Android application developers to write Android applications using standard
Java programming language.
 Application Framework

 The Application Framework layer provides many higher-level services to applications in the
form of Java classes. Application developers are allowed to make use of these services in their
applications.
The Android framework includes the following key services −

 Activity Manager − Controls all aspects of the application lifecycle and activity stack.
 Content Providers − Allows applications to publish and share data with other applications.
 Resource Manager − Provides access to non-code embedded resources such as
 strings, color settings and user interface layouts.
 Notifications Manager − Allows applications to display alerts and notifications to the user.
 View System − An extensible set of views used to create application user interfaces.
Applications

Contacts Books, Browser, Games