08-01-2013, 01:53 PM
REAL TIME SYSTEM WITH LINUX
1REAL TIME.doc (Size: 320 KB / Downloads: 26)
History and Functionality of Linux
Linux is a Unix-like operating system. The first version of Unix, called UNICS (Uniplexed Operating and Computing System) was developed by Ken Thompson for the then new Digital Equipment Corporation PDP 11 family of minicomputers. UNICS (later shortened to Unix) was designed to be a simpler alternative to the MULTICS (Multiplexed Operating and Computing System) project. The MULTICS project was a joint effort by General Electric, Massachusetts Institute of Technology and Bell Laboratories and was begun in the mid 1960's. The MULTICS operating system was in turn inspired by MIT's Project MAC.
A new system implementation language, called C, was written by Ken Thompson and Dennis Ritchie. They rewrote the UNIX kernel using the C compiler in 1973. C has evolved into a standard in its own right and has become a general purpose programming language commonly used for both low-level device drivers and high-level application programs.
Unix was clean and efficient, and since it provided economical access to a multi-user environment it soon gained great popularity in the technical community. AT&T gave universities royalty free licenses, which created a growing pool of advocates as students graduated and went into industry. The workstation and server markets have been dominated by Unix and Unix-like operating systems since they were created in the 1980's.
Despite the fact that licenses were royalty free, UNIX was not an ideal teaching tool since licenses restricted source code distribution and modification. Several simplified Unix-like operating systems were created for teaching. One of the more popular in the late 1980's was Andrew Tannenbaum's operating system MINIX.
In the early 1980's, Richard Stallman initiated a project to develop freely-available software. Freely-available software is characterized by not having any restrictions, nor requiring any royalty payments, on the distribution of the software source code. One of the first projects for the Free Software Foundation (FSF) was to develop a C compiler which was essential to the major goal of developing an operating system. Since contributors to the FSF had come from a UNIX background, the project was titled GNU (Gnu is Not Unix, which is read as New, is Not Unix). The C compiler was named gcc (GNU C compiler) to differentiate it from the proprietary cc compiler that was supplied with UNIX systems.
Nomenclature
Throughout this report the phrase \standard Linux" or \standard kernel" shall refer to the kernel.org distribution, or non-real-time Linux kernel. The phrase \real-time Linux" or \real-time kernel" shall refer to all implementations, discussed in Section 2.2, that bring low-latency and low-jitter real-time performance to the Linux kernel.
Standard Linux for Soft Real-Time Applications
It is possible to use standard Linux for soft real-time control applications where the sample time is relatively long, say 100s of milliseconds, and the application can tolerate missed timing schedules. One example is displaying video, where missed schedules mean that a small number of frames are lost but the video continues. Another example is for streaming audio where missed schedules mean loss of audio generally heard as clicks or pops. A third example is data acquisition and display where a missed schedule means that a small set of data points never gets displayed. If loss of data can be tolerated, then standard Linux, especially the latest kernels (version > 2.5.4) that include the bottom-half preemption logic, described in Section 2, can be used. If that is not the case, then the hard real-time implementations are required.
Embedded Applications
Real-time systems may also be embedded systems. Embedded applications typically run in small physical and computing footprints, often without keyboards, mice or monitors, and usually without rotating media such as hard drives or CD-ROMs that could not withstand harsh environments. Programmers can configure Linux to run without any of these devices, and there are several popular embedded Linux distributions that come pre-configured and include useful tools for customization. Common customizations include adding flash memory storage to replace rotating media hard disks, and replacing the memory- and disk-consuming X Windows graphics component with stripped-down versions. Indeed, many commercial products run Linux internally and do not resemble desktop computers at all; examples include set-top boxes, television video recorders, personal digital assistants (PDAs), and game consoles. Many Linux distributions streamline the system considerably, both reducing the time to boot and resource consumption; a web list is maintained at .
Modifications that make Linux Real Time
Interrupt processing in the standard kernel is divided into two halves. The two sections are referred to as top-half and bottom-half tasks. The bottom-half task is the interrupt handler and reads data from the physical device into a memory buffer. The top-half task reads from the memory buffer and passes the data to a kernel accessible buffer. In the standard kernel, without the preemption patches, all interrupts are disabled when the bottom-half task is running. This means that there can be an arbitrary delay, the latency, before a second interrupt can be serviced.
The standard Linux kernel provides a default timer resolution of ten milliseconds. The timer resolution can be improved by recompiling the standard kernel using a different timer divisor, but even with the improved latency of one millisecond in version 2.5.4 there is not much point in much higher timer resolution.
All variants of real-time Linux have introduced modifications at the kernel level. The result of these modification at the kernel level. The result of these modifications is to reduce both the interrupt latency and jitter between periodic interrupts to the microsecond range, allowing for faster response to external events and higher resolution timing.
Standards-Kernel Preemption
This methodology is to modify the standard Linux kernel to ensure that higher priority kernel processes can preempt lower priority processes and gain access to needed resources. This involves changing the standard device-driver interrupt-handler so that higher-priority interrupts are not blocked for arbitrary amounts of time while a lower-priority interrupt handler completes
its task.
Starting with Linux version 2.5.4, the standard kernel incorporates preemption logic as
shown in Figure 2. The resultant latency and jitter is around 1 millisecond on Pentium processors with CPU clocks running at 100s of MHz. This performance improvement is satisfactory for supporting user-space audio and video applications, but is clearly inadequate for running periodic interrupts at sub-millisecond sample times. These sub-millisecond sample times are possible with the implementations discussed in Section 2.2.
Note that in Figure 2 the real-time task is one of many tasks being controlled by the kernel scheduler. This task is the kernel's reference to the real-time user-space process. The scheduler is able to run this higher-priority real-time task by preempting any lower priority non-real-time tasks in kernel space and thus the user-space process can achieve the one millisecond scale latency that version 2.5.4 made possible.
Resource Kernel Extension
As shown in Figure 5 the resource kernel is a compact code module that provides a gateway to resources such as file systems, serial and parallel ports, and network interfaces for both the normal kernel and also for user processes. Not only does the resource kernel control the interrupt preemption issues for the standard kernel, it provides mechanisms where user-space programs can request, reserve, and be guaranteed a finite percentage of machine resources such as memory, CPU cycles, network and file-system-transfer bandwidth.
The resource kernel architecture was developed at Carnegie Mellon University starting in 1996 and was distributed for several years by TimeSys. The resource kernel as originally developed never reached latencies required for hard real-time applications, but it provided the base for the TimeSys Linux May 2002 release described in Section 2.2.2.