Commercial operating systems

Commercial operating systems

pSOS+, pSOS+ kernel, pSOS  multiprocessor kernel,   pSOS+m, pREPC+ runtime support,   pHILE+ file system, pNA+ network manager, pROBE+ system level debugger, XRAY+ source level debugger, OS-9, VXWorks,   VRTX-32, IFX, TNX, RTL, RTscope, MPV, LynxOS-POSIX conformance,  Windows NT.

pSOS⁺

pSOS⁺ is the name of a popular multitasking real-time operating system. Although the name refers to the kernel itself, it is often used in a more generic way to refer to a series of develop-ment tools and system components. The best way of looking at the products is to use the overall structure as shown in the diagram. The box on the left is concerned with the development environ-ment while that on the right are the software components that are used in the final target system. The two halves work together via communication links such as serial lines, Ethernet and TCP/IP protocol or even over the VMEbus itself.

pSOS⁺ kernel

The kernel supports a wide range of processor families like the Motorola M68000 family, the Intel 80x86 range, and the M88000 and i960 RISC processors. It is small in size and typically takes about 15–20 kbytes of RAM, although the final figure will depend on the configuration and processor type.

It supports more than 50000 system objects such as tasks, memory partitions, message queues and so on and will execute time-critical routines consistently irrespective of the application size. In other words, the time to service a message queue is the same irrespective of the size of the message. Note that this will refer to the time taken to pass the message or perform the service only and does not and cannot take into account the time taken by the user to handle messages. In other words, the consistent timing refers to the message delivery and not the actions taken as a result of the message. Worst case figures for interrupt latency and context switch for an MC68020 running at 25 MHz are 6 and 19 µs respectively. Among its 55 service calls, it provides support for:

•                                                                         Task management

•                                                                         Message queues

•                                                                         Event services

•                                                                         Semaphore services

•                                                                         Asynchronous services

•                                                                         Storage allocation services

•                                                                         Time management and timer services

•                                                                         I/O supervisor services

•                                                                         Interrupt management

•                                                                         Error handling services

pSOS  multiprocessor kernel

pSOS^+m is the multiprocessing version of the kernel. From an application or task’s perspective, it is virtually the same as the single processor version except that the kernel now has the ability to send and receive system objects from other processors within the system. The application or task does not know where other tasks actually reside or the communication method used to link them.

The communication mechanism works in this way. Each processor runs its own copy of the kernel and has a kernel interface to the media used for linking the processors, either a VMEbus backplane or a network. When a task sends a message to a local task, the local processor will handle it. If the message is for task running on another node, the local operating system will look up the recipient’s identity and location. The message is then routed across the kernel interface across to the other processor and its operating system where the message is finally delivered. Different kernel interfaces are needed for different media.

pREPC⁺ runtime support

This is a compiler independent run-time environment for C applications. It is compatible with the ANSI X3J11 technical com-mittee’s proposal for C run-time functionality and provides 88 functions that can be called from C programs. Services supported include formatted I/O, file I/O and string manipulation.

pREPC⁺ is not a standalone product because it uses pSOS⁺ or pSOS^+m for device I/O and task functions and calls pHILE⁺ for file and disk I/O. Its routines are re-entrant which allows multiple tasks to use the same routine simultaneously.

pHILE⁺ file system

This product provides file I/O and will support either the MS-DOS file structure or its own proprietary formats. The MS-DOS structure is useful for data interchange while the proprietary format is designed to support the highest data throughput across a wide range of devices. pHILE⁺ does not drive physical devices directly but provides logical data via pSOS⁺ to a device driver task that converts this information to physical data and drives the storage device.

pNA⁺ network manager

This is a networking option that provides TCP/IP commu-nication over a variety of media such as Ethernet and FDDI. It conforms to the UNIX 4.3 BSD socket syntax and approach and is compatible with other TCP/IP–based networking standards such as ftp and NFS.

As a result, pNA⁺ is used to provide efficient downloading and debugging communication between the target and a host development system. Alternatively, it can be used to provide a communication path between other systems that are also sitting on the same network.

pROBE⁺ system level debugger

This is the system level debugger which provides the sys-tem and low level debugging facilities. With this, system objects can be inspected or even used to act as breakpoints if needed. It can use either a serial port to communicate with the outside world or if pNA⁺ is installed, use an TCP/IP link instead.

XRAY⁺ source level debugger

This is a complementary product to pROBE⁺ as it can use the debugger information and combine it with the C source and other symbolic information on the host to provide a complete integrated debugging environment.

OS-9

OS-9 was originally developed by Microware and Motorola as a real-time operating system for the Motorola MC6809 8 bit processor and it appeared on many 6809-based systems such as the Exorset 165 and the Dragon computer. It provided a true hierarchical filing system and the ability to run multiple tasks. It has since been ported to the M68000 family and the Intel 80x86 processor families. It is best described as a complete operating system with its own user commands, interface and so on. Unlike other products which have concentrated on the central kernel and then built outwards but stopping at below the user and utility level, OS-9 goes from a multi-user multitasking interface with a range of utilities down to the low level kernel. Early on it sup ported UNIX by using and supporting the same library interface and similar system calls. So much so that one of its strengths was the ability to take UNIX source code, recompile it and then run it.

One criticism has been its poor real-time response although a new version has been released which used a smaller, compact and faster kernel to provide better performance. The full facilities are still provided by the addition of other kernel services around the inner one. It provides more sophisticated support such as multimedia extensions which other operating systems do not, and because of this and its higher level of utilities and expansion has achieved success in the marketplace.

VXWorks

VXWorks has taken another approach to the problem of providing a real-time environment as well as standard software tools and development support. Instead of creating its own or reproducing a UNIX-like environment, it actually has integrated with UNIX to provide its development and operational environ-ment. Through VXWorks’ UNIX compatible networking facilities, it can combine with UNIX to form a complete run-time solution as well. The UNIX system is responsible for software development and non-real-time debugging while the VXWorks kernel is used for testing, debugging and executing the real-time applications, either standalone or part of a network with UNIX.

How does this work? The UNIX system is used as the development host and is used to edit, compile, link and administer the building of real-time code. These modules can then be burned into ROM or loaded from disk and executed standalone under the VXWorks kernel. This is possible because VXWorks can under-stand the UNIX object module format and has a UNIX compatible software interface. By using the standard UNIX pipe and socket mechanisms to exchange data between tasks and by using UNIX signals for asynchronous events, there is no need for recompilation or any other conversion routines. Instead, the programmer can use the same interface for both UNIX and VXWorks software without having to learn different libraries or programming commands. It supports the POSIX 1003.4 real-time extensions and multiprocess-ing support for up to 20 processors is offered via another option called VxMP.

The real key to VXWorks is its ability to network with UNIX to allow a hybrid system to be developed or even allow individual modules or groups to be transferred to run in a VXWorks environ-ment. The network can be over an Ethernet or even using shared memory over a VMEbus, for example.

VRTX-32

VRTX-32 from Microtec Research has gained a reputation for being an extremely compact but high performance real-time kernel. Despite being compact — typically about 8 kbytes of code for an MC68020 system — it provides task management facilities, inter-task communication, memory control and allocation, clock and timer functions, basic character I/O and interrupt handling facilities.

Under the name of VRTXvelocity, VRTX-32 systems can be designed using cross-development platforms such as Sun workstations and IBM PCs. The systems can be integrated with the host, usually using an Ethernet, to provide an integrated approach to system design.

IFX

Its associated product IFX (input/output file executive) provides support for more complicated I/O subsystems such as disks, terminals, and serial communications using structures such as pipes, null devices, circular buffers and caches. The file system is MS-DOS compatible although if this is not required, disks can be treated as single partitions to speed up response.

TNX

This is the TCP/IP networking package that allows nodes to communicate with hosts and other applications over the Ethernet. The Ethernet device itself can either be resident on the processor board or accessible across a VMEbus. It supports both stream and datagram sockets.

RTL

This is the run-time library support for Microtec and Sun compilers and provides the library interface to allow C programs to call standard I/O functions and make VRTX-32 calls.

RTscope

This is the real-time multitasking debugger and system monitor that is used to debug VRTX tasks and applications. It operates on two levels: the board level debugger provides the standard features such as memory and register display and modify, software upload and download and so on. In the VRTX-32 system monitor mode, tasks can be interrogated, stopped, suspended and restarted.

MPV

The multiprocessor VRTX-32 extensions allow multiple processors each running their own copy of VRTX to pass messages and other task information from one processor to another and thus create a multiprocessor system. The messages are based across the VMEbus using shared memory although other links such as RS232 or Ethernet are possible.

LynxOS-POSIX conformance

POSIX (IEEE standard portable operating system interface for computer environments) began in 1986 as an attempt to provide an open standard for operating system support. The ideas behind it are to provide vendor independence, protection from technical obsolescence, the availability of standard off-the-shelf applications, the preservation of software investment and to pro-vide connectivity between computers.

It is based on UNIX but has added a set of real-time extensions as defined in the POSIX 1003.4 document. These cover a more sophisticated semaphore system which uses the open() call to create them. This call is more normally associated with opening a file. The facilities include persistent semaphores which retain their binary state after their last use, and the ability to force a task to wait for a semaphore through a locking mechanism.

The extensions also provide a process or task locking mecha-nism which prevents memory pages associated with the task or process from being swapped out to memory, thus improving the real-time response for critical routines. Shared memory is better supported through the provision of the shmmap() call which will allocate a sheared memory block. Both asynchronous and syn-chronous I/O and inter-task message passing are supported along with real-time file extensions to speed up file I/O. This uses techniques such as preallocating file space before it is required.

At the time of writing LynxOS is the main real-time product that supports these standards, although many others support parts of the POSIX standard. Indeed, there is an increasing level of support for this type of standardisation.

However, it is not a complete panacea and, while any attempt for standardisation should be applauded, it does not solve all the issues. Real-time operating systems and applications are very different in their needs, design and approach, as can be seen from the diversity of products that are available today. Can all of these be met by a single standard? In addition, the main cost of developing software is not in porting but in testing and document-ing the product and this again is not addressed by the POSIX standards. POSIX conformance means that software should be portable across processors and platforms, but it does not guaran-tee it. With many of today’s operating systems available in ver-sions for the major processor families, is the POSIX portability any better? Many of these questions are yet to be answered conclu-sively by supporters or protagonists.

An alternative way of looking at this problem is: do you assume that a ported real-time product will work because it is POSIX compliant without testing it on the new target? In most cases the answer will be no and that testing will be needed. What POSIX conformance has given is a helping hand in the right direction and this should not be belittled, neither should it be seen as a miracle cure. In the end, the success of the POSIX standards will depend on the market and users seeing benefit in its approach. It is an approach that is gathering pace, and one that the real-time market should be aware of. It is possible that it may succeed where other attempts at a real-time interface standard have failed. An-other possibility for POSIX conformance is Windows NT.

Windows NT

Windows NT has been portrayed as many different things during its short lifetime. When it first appeared, it was perceived by many as the replacement for Windows 3.1, an alternative to UNIX, and finally has settled down as an operating system for workstations, servers and power users. This chameleon-like change was not due to any real changes in the product but were caused by a mixture of aspirations and misunderstandings.

Windows NT is rapidly replacing Windows 3.1 and Win-dows 95 and parts of its technology have already found them-selves incorporated into Windows 95 and Windows for Workgroups. Whether the replacement is through a merging of the operating system technologies or through a sharing of com-mon technology, only time will tell. The important message is that the Windows NT environment is becoming prevalent, especially with Microsoft’s aim of a single set of programming interfaces that will allow an application to run on any of its operating system environments. Its greater stability and reliability is another fea-ture that is behind its adoption by many business systems in preference over Windows 95. All this is fine, but how does this fit with an embedded system?

There are several reasons why Windows NT is being used in real-time environments. It may not have the speed of a dedi-cated RTOS but it has the important features and coupled with a fast processor, reasonable performance.

•                                                                        Portability

Most PC-based operating systems were written in low-level assembler language instead of a high level language such as C or C++. This decision was taken to provide smaller programs sizes and the best possible performance. The disadvantage is that the operating system and applica-tions are now dependent on the hardware platform and it is extremely difficult to move from one platform to another. MS-DOS is writen in 8086 assembler which is incompatible with the M68000 processors used in the Apple Macintosh. For a software company like Microsoft, this has an addi-tional threat of being dependent on a single processor platform. If the platform changes — who remembers the Z80 and 6502 processors which were the mainstays of the early PCs — then its software technology becomes obsolete.

With an operating system that is written in a high level language and is portable to other platforms, it allows Microsoft and other application developers to be less hard-ware dependent.

•                                                                        True multitasking

While more performant operating systems such as UNIX and VMS offer the ability to run multiple applications simultaneously, this facility is not really available from the Windows and MS-DOS environments (a full explanation of what they can do and the difference will be offered later in this chapter). This is now becoming a very important aspect for both users and developers alike so that the full perform-ance of today’s processors can be utilised.

•                                                                         Multi-threaded

Multi-threading refers to a way of creating software that can be reused without having to have multiple copies of the code or memory spaces. This leads to more efficient use of both memory and code.

•                                                                         Processor independent

Unlike Windows and MS-DOS which are completely linked to the Intel 80x86 architecture, Windows NT through its portability is processor independent and has been ported to other processor architectures such as Motorola’s PowerPC, DEC’s Alpha architecture and MIPS RISC processor sys-tems.

•                                                                         Multiprocessor support

Windows NT uses a special interface to the processor hardware which makes it independent of the processor architecture that it is running on. As a result, this not only gives processor independence but also allows the operating system to run on multiprocessor systems.

•                                                                         Security and POSIX support

Windows NT offers several levels of security through its use of a multi-part access token. This token is created and verified when a user logs onto the system and contains IDs for the user, the group he is assigned to, privileges and other information. In addition, an audit trail is also provided to allow an administrator to check who has used the system, when they used it and what they did. While an overkill for a single user, this is invaluable with a system that is either used by many or connected to a network.

The POSIX standard defines a set of interfaces that allow POSIX compliant applications to easily be ported between POSIX compliant computer systems.

Both security and POSIX support are commercially essen-tial to satisfy purchasing requirements from government departments, both in the US and the rest of the world.

Windows NT characteristics

Windows NT is a pre-emptive multitasking environment that will run multiple applications simultaneously and uses a priority based mechanism to determine the running order. It is capable of providing real-time support in that it has a priority mechanism and fast response times for interrupts and so on, but it is less deterministic — there is a wider range of response times

— when compared to a real-time operating system such as pSOS or OS-9 used in industrial applications. It can be suitable for many real-time applications with less critical timing characteristics and this is a big advantage over the Windows 3.1 and Windows 95 environments. It is interesting to note that this technology now forms the backbone of all the Windows software environments.

Process priorities

Windows NT calls all applications, device drivers, software tasks and so on processes and this nomenclature will be used from now on. Each process can be assigned one of 32 priority levels which determines its scheduling priority. The 32 levels are di-vided into two groups called the real-time and dynamic classes.

The real-time classes comprise priority levels 16 through to 31 and the dynamic classes use priority levels 15 to 0. Within these two groups, certain priorities are defined as base classes and processes are allocated a base process. Independent parts of a process — these are called threads — can be assigned their own priority levels which are derived from the base class priority and can be ±2 levels different. In addition, a process cannot move from a real-time class to a dynamic one.

The diagram shows how the base classes are organised. The first point is that within a given dynamic base class, it is possible for a lot of overlap. Although a process may have a lower base class compared to another process, it may be at a higher priority than the other one depending on the actual priority level that has been assigned to it. The real-time class is a little simpler although again there is some possibility for overlap.

User applications like word processors, spread sheets and so on run in the dynamic class and their priority will change depending on the application status. Bring an application from the background to the foreground by expanding the shrunk icon or by switching to that application will change its priority appropriately so that it gets allocated a higher priority and therefore more processing. Real-time processes include device drivers handling the keyboard, cursor, file system and other similar activities.

Interrupt priorities

The concept of priorities is not solely restricted to the pre-emption priority previously described. Those priorities come into play when an event or series of events occur. The events them-selves are also controlled by 32 priority levels defined by the hardware abstraction layer (HAL).

The interrupt priorities work in a similar way to those found on a microprocessor: if an interrupt of a higher priority than the current interrupt priority mask is generated, the current processing will stop and be replaced by the associated routines for the new higher priority level. In addition, the mask will be raised to match that of the higher priority. When the higher priority processing has been completed, the previous processing will be restored and allowed to continue. The interrupt priority mask will also be restored to its previous value.

Within Windows NT, the interrupt processing is also sub-ject to the multitasking priority levels. Depending on how these are assigned to the interrupt priority levels, the processing of a high priority interrupt may be delayed until a higher priority process has completed. It makes sense therefore to have high priority interrupts processed by processes with high priority scheduling levels. Comparing the interrupts and the priority levels shows that this maxim has been followed. Software inter-rupts used to communicate between processes are allocated both low interrupt and scheduling priorities. Time critical interrupts such as the clock and inter-processor interrupts are handled as real-time processes and are allocated the higher real-time sched-uling priorities.

The combination of both priority schemes provides a fairly complex and flexible method of structuring how external and internal events and messages are handled.