0% found this document useful (0 votes)
52 views

Commericial Operating Systems

POSIX stands for portability at the source code level. Uc/os-ii is one of the most popular real-time operating systems. RT-POSIX is based on a common binary language structure.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
52 views

Commericial Operating Systems

POSIX stands for portability at the source code level. Uc/os-ii is one of the most popular real-time operating systems. RT-POSIX is based on a common binary language structure.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Module Lesson

6 32
Embedded System Commercial Real-Time
Software Operating Systems
Version 2 EE IIT, Kharagpur 1 Version 2 EE IIT, Kharagpur 2
Specific Instructional Objectives Open Source: Provides portability at the source code level. To run an application on a new
platform would require only compilation and linking. ANSI and POSIX are important open
At the end of this lesson, the student would be able to: source standards.

x Get an understanding of open software Open Object: This standard provides portability of unlinked object modules across different
platforms. To run an application in a new environment, relinking of the object modules
x Know the historical background under which POSIX was developed would be required.
x Get an overview of POSIX Open Binary: This standard provides complete software portability across hardware
platforms based on a common binary language structure. An open binary product can be
x Understand the Real-Time POSIX standard
portable at the executable code level. At the moment, no open binary standards.
x Get an insight into the features of some of the popular Real-Time OS: PSOS, VRTX,
VxWorks, QNX, µC/OS-II, RT-Linux, Lynx, Windows CE The main goal of POSIX is application portability at the source code level. Before we discuss
about RT-POSIX, let us explore the historical background under which POSIX was developed.
1. Introduction
1.3. Genesis of POSIX
Many real-time operating systems are at present available commercially. In this lesson, we
analyze some of the popular real-time operating systems and investigate why these popular Before we discuss the different features of the POSIX standard in the next subsection, let us
systems cannot be used across all applications. We also examine the POSIX standards for RTOS understand the historical developments that led to the development of POSIX.
and their implications. Unix was originally developed by AT&T Bell Labs. Since AT&T was primarily a
telecommunication company, it felt that Unix was not commercially important for it. Therefore,
1.1. POSIX it distributed Unix source code free of cost to several universities. UCB (University of California
at Berkeley) was one of the earliest recipient of Unix source code.
POSIX stands for Portable Operating System Interface. “X” has been suffixed to the AT&T later got interested in computers, realized the potential of Unix and started developing
abbreviation to make it sound Unix-like. Over the last decade, POSIX has become an important Unix further and came up with Unix V. Meanwhile, UCB had incorporated TCP/IP into Unix
standard in the operating systems area including real-time operating systems. The importance of through a large DARPA (Defense Advanced Research Project Agency of USA) project and had
POSIX can be gauzed from the fact that nowadays it has become uncommon to come across a come up with BSD 4.3 and C Shell. With this, the commercial importance of Unix started to
commercial operating system that is not POSIX-compliant. POSIX started as an open software grow rapidly. As a result, many vendors implemented and extended Unix services in different
initiative. Since POSIX has now become overwhelmingly popular, we discuss the POSIX ways: IBM with its AIX, HP with its HP-UX, Sun with its Solaris, Digital with its Ultrix, and
requirements on real-time operating systems. We start with a brief introduction to open SCO with SCO-Unix. Since there were so many variants of Unix, portability of applications
software movement and then trace the historical events that have led to the emergence of across Unix platforms became a problem. It resulted in a situation where a program written on
POSIX. Subsequently, we highlight the important requirements of real-time POSIX. one Unix platform would not run on another platform.
The need for a standard Unix was recognized by all. The first effort towards standardization
of Unix was taken by AT&T in the form of its SVID (System V Interface Definition). However,
1.2. Open Software BSD and other vendors ignored this initiative. The next initiative was taken under ANSI/IEEE,
which yielded POSIX.
An open system is a vendor neutral environment, which allows users to intermix hardware,
software, and networking solutions from different vendors. Open systems are based on open
standards and are not copyrighted, saving users from expensive intellectual property right (IPR) 1.4. Overview of POSIX
law suits. The most important characteristics of open systems are: interoperability and
portability. Interoperability means systems from multiple vendors can exchange information POSIX is an off-shoot of the open software movement, and portability of applications across
among each other. A system is portable if it can be moved from one environment to another different variants of Unix operating systems was the major concern. POSIX standard defines
without modifications. As part of the open system initiative, open software movement has only interfaces to operating system services and the semantics of these services, but does not
become popular. specify how exactly the services are to be implemented. For example, the standard does not
Advantages of open software include the following: It reduces cost of development and time specify whether an operating system kernel must be single threaded or multithreaded or
to market a product. It helps increase the availability of add-on software packages. It enhances at what priority level the kernel services are to be executed.
the ease of programming. It facilitates easy integration of separately developed modules. The POSIX standard has several parts. The important parts of POSIX and the aspects that
POSIX is an off-shoot of the open software movement. they deal with, are the following:
Open Software standards can be divided into three categories:

Version 2 EE IIT, Kharagpur 3 Version 2 EE IIT, Kharagpur 4


Open Source: Provides portability at the source code level. To run an application on a new several commercial embedded products. An example application of PSOS is in the base stations
platform would require only compilation and linking. ANSI and POSIX are important open of the cellular systems.
source standards.
Legend:
x POSIX 1 : system interfaces and system call parameters
XRAY+: Source level
x POSIX 2 : shells and utilities Debgguer
x POSIX 3 : test methods for verifying conformance to POSIX PROBE: Target Debgger
x POSIX 4 : real-time extensions Editor
Cross-
compiler
1.5. Real-Time POSIX Standard XRAY+
Libraries Application
POSIX.4 deals with real-time extensions to POSIX and is also known as POSIX-RT. For an P
operating system to be POSIX-RT compliant, it must meet the different requirements specified in Host Computer N PSOS+
the POSIX-RT standard. The main requirements of the POSIX-RT are the following: A PHILE
TCP/IP +
x Execution scheduling: An operating system to be POSIX-RT compliant must provide PROBE
support for real-time (static) priorities.
x Performance requirements on system calls: It specifies the worst case execution times
Target
required for most real-time operating services.
x Priority levels: The number of priority levels supported should be at least 32. Fig. 32.1 PSOS-based Development of Embedded Software
x Timers: Periodic and one shot timers (also called watch dog timer) should be supported. PSOS-based application development has schematically been shown in Fig. 32.1. The host
The system clock is called CLOCK REALTIME when the system supports real-time computer is typically a desktop. Both Unix and Windows hosts are supported. The target board
POSIX. contains the embedded processor, ROM, RAM, etc. The host computer runs the editor, cross-
x Real-time files: Real-time file system should be supported. A real-time file system can compiler, source-level debugger, and library routines. On the target board PSOS+, and other
pre-allocate storage for files and should be able to store file blocks contiguously on the optional modules such as PNA+, PHILE, and PROBE are installed on a RAM. PNA+ is the
disk. This enables to have predictable delay in file access in virtual memory system. network manager. It provides TCP/IP communication over Ethernet and FDDI. It conforms to
Unix 4.3 (BSD) socket syntax and is compatible with other TCP/IP-based networking standards
x Memory locking: Memory locking should be supported. POSIX-RT defines the
such as ftp and NFS. Using these, PNA+ provides efficient downloading and debugging
operating system services: mlockall() to lock all pages of a process, mlock() to lock a
communication between the target and the host. PROBE+ is the target debugger and XRAY+ is
range of pages, and mlockpage() to lock only the current page. The unlock services are
the source-level debugger. The application development is done on the host machine and is
munlockall(), munlock(), and munlockpage. Memory locking services have been
downloaded to the target board. The application is debugged using the source debugger
introduced to support deterministic memory access.
(XRAY+). Once the application runs satisfactorily, it is fused on a ROM and installed on the
x Multithreading support: Real-time threading support is mandated. Real-time threads target board.
are schedulable entities of a real-time application that have individual timeliness We now highlight some important features of PSOS. PSOS consists of 32 priority levels. In
constraints and may have collective timeliness constraints when belonging to a runnable the minimal configuration, the foot print of the operating system is only 12KBytes. For sharing
set of threads. critical resources among real-time tasks, it supports priority inheritance and priority ceiling
protocols. It support segmented memory management. It allocates tasks to memory regions. A
1.6. A Survey of Contemporary Real-Time Operating Systems memory region is a physically contiguous block of memory. A memory region is created by the
operating system in response to a call from an application.
In this section, we briefly survey the important feature of some of the popular real-time In most modern operating systems, the control jumps to the kernel when an interrupt
operating systems that are being used in commercial applications. occurs. PSOS takes a different approach. The device drivers are outside the kernel and can be
loaded and removed at the run time. When an interrupt occurs, the processor jumps directly to
the ISR (interrupt service routine) pointed to by the vector table.
1.6.1. PSOS The intention is not only to gain speed, but also to give the application developer complete
control over interrupt handling.
PSOS is a popular real-time operating system that is being primarily used in embedded
applications. It is available from Wind River Systems, a large player in the real-time operating
system arena. It is a host-target type of real- time operating system. PSOS is being used in
Version 2 EE IIT, Kharagpur 5 Version 2 EE IIT, Kharagpur 6
1.6.2. VRTX File Device
System Driver
VRTX is a POSIX-RT compliant operating system from Mentor Graphics. VRTX has been
certified by the US FAA (Federal Aviation Agency) for use in mission and life critical Message Passing
Micro
applications such as avionics. VRTX has two multitasking kernels: VRTXsa and VRTXmc. Kernel
VRTXsa is used for large and medium applications. It supports virtual memory. It has a
POSIX-compliant library and supports priority inheritance. Its system calls are deterministic and
fully preemptable. VRTXmc is optimized for power consumption and ROM and RAM sizes. It Appli- TCP/IP
has therefore a very small foot print. The kernel typically requires only 4 to 8 Kbytes of ROM cation Manager
and 1KBytes of RAM. It does not support virtual memory. This version is targeted for cell
phones and other small hand-held devices. Fig. 32.2 Microkernel Architecture of QNX

1.6.5. µC/OS-II
1.6.3. VxWorks
µC/OS-II is a free RTOS, easily available on Internet. It is written in ANSI C and contains
VxWorks is a product from Wind River Systems. It is host-target system. The host can be small portion of assembly code. The assembly language portion has been kept to a minimum to
either a Windows or a Unix machine. It supports most POSIX-RT functionalities. VxWorks make it easy to port it to different processors. To date, µC/OS-II has been ported to over 100
comes with an integrated development environment (IDE) called Tornado. In addition to the different processor architectures ranging from 8-bit to 64-bit microprocessors, microcontrollers,
standard support for program development tools such as editor, cross-compiler, cross-debugger, and DSPs. Some important features of µC/OS-II are highlighted in the following.
etc. Tornado contains VxSim and WindView. VxSim simulates a VxWorks target for use as a
prototyping and testing environment. WindView provides debugging tools for the simulator x µC/OS-II was designed so that the programmer can use just a few of the offered services
environment. VxMP is the multiprocessor version of VxWorks. or select the entire range of services. This allows the programmer to minimize the
VxWorks was deployed in the Mars Pathfinder which was sent to Mars in 1997. Pathfinder amount of memory needed by µC/OS-II on a per-product basis.
landed in Mars, responded to ground commands, and started to send science and engineering x µC/OS-II has a fully preemptive kernel. This means that µC/OS-II always ensures that
data. However, there was a hitch: it repeatedly reset itself. Remotely using trace generation, the highest priority task that is ready would be taken up for execution.
logging, and debugging tools of VxWorks, it was found that the cause was unbounded priority
x µC/OS-II allows up to 64 tasks to be created. Each task operates at a unique priority
inversion. The unbounded priority inversion caused real-time tasks to miss their deadlines, and
as a result, the exception handler reset the system each time. Although VxWorks supports level. There are 64 priority levels. This means that round-robin scheduling is not
priority inheritance, using the remote debugging tool, it was found to have been disabled in the supported. The priority levels are used as the PID (Process Identifier) for the tasks.
configuration file. The problem was fixed by enabling it. x µC/OS-II uses a partitioned memory management. Each memory partition consists of
several fixed sized blocks. A task obtains memory blocks from the memory partition and
1.6.4. QNX the task must create a memory partition before it can be used. Allocation and
deallocation of fixed-sized memory blocks is done in constant time and is deterministic.
QNX is a product from QNX Software System Ltd. QNX Neutrino offers POSIX-compliant A task can create and use multiple memory partitions, so that it can use memory blocks
APIs and is implemented using microkernel architecture. of different sizes.
The microkernel architecture of QNX is shown in Fig. 32.2. Because of the fine grained x µC/OS-II has been certified by Federal Aviation Administration (FAA) for use in
scalability of the micro- kernel architecture, it can be configured to a very small size – a critical commercial aircraft by meeting the demanding requirements of its standard for software
advantage in high volume devices, where even a 1% reduction in memory costs can return used in avionics. To meet the requirements of this standard it was demonstrated through
millions of dollars in profit. documentation and testing that it is robust and safe.

1.6.6. RT Linux
Linux is by large a free operating system. It is robust, feature rich, and efficient. Several real-
time implementations of Linux (RT-Linux) are available. It is a self-host operating system (see
Fig. 32.3). RT-Linux runs along with a Linux system. The real-time kernel sits between the
hardware and the Linux system. The RT kernel intercepts all interrupts generated by the
hardware. Fig. 32.12 schematically shows this aspect. If an interrupt is to cause a real-time task

Version 2 EE IIT, Kharagpur 7 Version 2 EE IIT, Kharagpur 8


to run, the real-time kernel preempts Linux, if Linux is running at that time, and lets the real-time 1.6.7. Lynx
task run. Thus, in effect Linux runs as a task of RT-Linux.
Lynx is a self host system. The currently available version of Lynx (Lynx 3.0) is a
Linux microkernel-based real-time operating system, though the earlier versions were based on
monolithic design. Lynx is fully compatible with Linux. With Lynx’s binary compatibility, a
RT Linux Linux program’s binary image can be run directly on Lynx. On the other hand, for other Linux
compatible operating systems such as QNX, Linux applications need to be recompiled in order to
Hardware run on them. The Lynx microkernel is 28KBytes in size and provides the essential services in
scheduling, interrupt dispatch, and synchronization. The other services are provided as kernel
plug-ins (KPIs). By adding KPIs to the microkernel, the system can be configured to support I/O,
file systems, sockets, and so on. With full configuration, it can function as a multipurpose Unix
machine on which both hard and soft real-time tasks can run. Unlike many embedded real-time
operating systems, Lynx supports memory protection.
Fig. 32.3 Structure of RT Linux
The real-time applications are written as loadable kernel modules. In essence, real-time 1.6.8. Windows CE
applications run in the kernel space.
In the approach taken by RT Linux, there are effectively two independent kernels: real-time Windows CE is a stripped down version of Windows, and has a minimum footprint of
kernel and Linux kernel. Therefore, this approach is also known as the dual kernel approach as 400KBytes only. It provides 256 priority levels. To optimize performance, all threads are run in
the real-time kernel is implemented outside the Linux kernel. Any task that requires deterministic the kernel mode. The timer accuracy is 1 msec for sleep and wait related APIs. The different
scheduling is run as a real-time task. These tasks preempt Linux whenever they need to execute functionalities of the kernel are broken down into small non-preemptive sections. So, during
and yield the CPU to Linux only when no real-time task is ready to run. system call preemption is turned off for only short periods of time. Also, interrupt servicing is
Compared to the microkernel approach, the following are the shortcomings of the dual-kernel preemptable. That is, it supports nested interrupts. It uses memory management unit (MMU) for
approach. virtual memory management.
Windows CE uses a priority inheritance scheme to avoid priority inversion problem present
x Duplicated Coding Efforts: Tasks running in the real-time kernel can not make full use in Windows NT. Normally, the kernel thread handling the page fault (i.e. DPC) runs at priority
of the Linux system services – file systems, networking, and so on. In fact, if a real-time level higher than NORMAL (refer Sec. 4.5.2). When a thread with priority level NORMAL
task invokes a Linux service, it will be subject to the same preemption problems that suffers a page fault, the priority of the corresponding kernel thread handling this page fault is
prohibit Linux processes from behaving deterministically. As a result, new drivers and raised to the priority of the thread causing the page fault. This ensures that a thread is not
system services must be created specifically for the real-time kernel – even when blocked by another lower priority thread even when it suffers a page fault.
equivalent services already exist for Linux.
x Fragile Execution Environment: Tasks running in the real-time kernel do not benefit 1.6.9. Exercises
from the MMU-protected environment that Linux provides to the regular non-real-time
processes. Instead, they run unprotected in the kernel space. Consequently, any real-time 1. State whether the following statements are True or False. Justify your answer in each case.
task that contains a coding error such as a corrupt C pointer can easily cause a fatal kernel a. In real-time Linux (RT-Linux), real-time processes are scheduled at priorities
fault. This is serious problem since many embedded applications are safety-critical in higher than the kernel processes.
nature. b. EDF scheduling of tasks is commonly supported in commercial real-time operating
x Limited Portability: In the dual kernel approach, the real-time tasks are not Linux systems such as PSOS and VRTX.
processes at all; but programs written using a small subset of POSIX APIs. To aggravate c. POSIX 1003.4 (real-time standard) requires that real-time processes be scheduled at
the matter, different implementations of dual kernels use different APIs. As a result, real- priorities higher than kernel processes.
time programs written using one vendor’s RT-Linux version may not run on another’s. d. POSIX is an attempt by ANSI/IEEE to enable executable files to be portable
across different Unix machines.
x Programming Difficulty: RT-Linux kernels support only a limited subset of POSIX 2. What is the difference between block I/O and character I/O? Give examples of each.
APIs. Therefore, application development takes more effort and time. Which type of I/O is accorded higher priority by Unix? Why?
3. List four important features that a POSIX 1003.4 (Real-Time standard) compliant
operating system must support. Is preemptability of kernel processes required by POSIX
1003.4? Can a Unix-based operating system using the preemption-point technique claim to
be POSIX 1003.4 compliant? Explain your answers.

Version 2 EE IIT, Kharagpur 9 Version 2 EE IIT, Kharagpur 10


4. Suppose you are the manufacturer of small embedded components used mainly in
consumer electronics goods such as automobiles, MP3 players, and computer-based toys.
Would you prefer to use PSOS, WinCE, or RT-Linux in your embedded component?
Explain the reasons behind your answer.
5. What is the difference between a system call and a function call? What problems, if any,
might arise if the system calls are invoked as procedure calls?
6. Explain how a real-time operating system differs from a traditional operating system.
Name a few real-time operating systems that are commercially available.
7. What is open software? Does an open software mandate portability of the executable files
across different platforms? Name an open software standard for real-time operating
systems. What is the advantage of using an open software operating system for real-time
application development? What are the pros and cons of using an open software product in
program development compared to a proprietary product?
8. Identify at least four important advantages of using VxWorks as the operating system for
real-time applications compared to using Unix V.3.
9. What is an open source standard? How is it different from open object and open binary
standards? Give some examples of popular open source software products.
10. Can multithreading result in faster response times (compared to single threaded tasks) even
in uniprocessor systems? Explain your answer and identify the reasons to support your
answer.

References (Lessons 24 - 28)


1. C.M. Krishna and Shin K.G., Real-Time Systems, Tata McGraw-Hill, 1999.
2. Philip A. Laplante, Real-Time System Design and Analysis, Prentice Hall of India, 1996.
3. Jane W.S. Liu, Real-Time Systems, Pearson Press, 2000.
4. Alan C. Shaw, Real-Time Systems and Software, John Wiley and Sons, 2001.
5. C. SivaRam Murthy and G. Manimaran, Resource Management in Real-Time Systems and
Networks, MIT Press, 2001.
6. B. Dasarathy, Timing Constraints of Real-Time Systems: Constructs for Expressing Them,
Methods for Validating Them, IEEE Transactions on Software Engineering, January 1985,
Vol. 11, No. 1, pages 80-86.
7. Lui Sha, Ragunathan Rajkumar, John P. Lehoczky, Priority inheritance protocols: An
approach to real-time synchronization,, IEEE Transactions on Computers, 1990, Vol. 39,
pages 1175-1185.

Version 2 EE IIT, Kharagpur 11

You might also like