eusing software, rather than developing each embedded product from scratch.
Because of these trends, embedded product vendors are tur
ning to a commercially available real-time operating system, LynxOS by Lynx Real-Time Systems. It provides a suitable operating environment for embedded applications in communications, networking, multimedia, and instrumentation. Its design emphasizes deterministic real-time performance, with desirable characteristics such as ROMability, modularity, and compact code required by such applications. With 90 percent of its code written in C, LynxOS is portable, and versions are available for the x86 family, the 680x0 family, the PowerPC line, and SPARC.
Design Goals
The LynxOS kernel design process addressed the following goals:
--Predictable response under all load conditions
ensures that applications respond to external events in a predictable fashion, regardless of what else the system is handling. It requires consistent and prompt scheduling of time-critical tasks and low system overhead.
--High-performance OS facilities must execute quickly,
with fast response to interrupts, to keep the system overhead low and predictable.
--Memory protection makes applications more reliable
by ensuring that programs don't corrupt each other's code and data, or even the OS's code and data.
--Modular architecture provides scalability
so that the OS can be tailored for a wide variety of embedded applications, without sacrificing real-time performance. Key features such as TCP/IP, NFS, demand paging, and other extensions can be added or removed as necessary for a specific target environment. The LynxOS kernel can be configured to just under 200 KB of code.
--Compatibility with existing standards
such as Unix and Posix provides well-known APIs for programmers to work with and encourages code reuse.
The basic design of LynxOS involved key decisions to achieve these goals. First, the entire kernel had to be preemptive and reentrant, so that time-critical tasks execute promptly. A time-critical task get
s high priority so it always can preempt a lower-priority task, even while the latter uses a system service. The kernel's reentrant code also lets this higher-priority task use system services, even when the preempted task has made identical system calls.
Second, the kernel supports multithreading. Not only can user programs create multiple tasks at will, but device drivers and other kernel services can create their own tasks, which are called
kernel threads
. Kernel threads allow more effective scheduling of interrupt handling. That's because certain code -- such as network or disk I/O -- that used to be part of an interrupt handler can now go in a kernel thread, scheduled so that it doesn't interfere with real-time processing. You can, therefore, schedule time-critical user tasks to execute at a higher priority than a device driver's kernel thread, so that these user tasks can respond rapidly to events. Global scheduling of all threads, user and kernel, is based solely on priority.
Third
, LynxOS uses a processor's page memory management unit (MMU) to provide each instance of a user program its own protected logical address space. The MMU also protects the kernel by placing it in a separate address space, as shown in the figure
"Thread Memory Contexts"
.
Last, instead of creating a proprietary API, the design team chose the Unix and Posix APIs, allowing a rich variety of Unix programs to be ported to LynxOS and offering a shallow learning curve for those programmers already familiar with the interface.
Real-Time Issues
In a real-time system, certain tasks must be completed within specific deadlines to respond to real-world events. For example, an embedded controller that adjusts the tension in a factory conveyor belt to compensate for a constantly changing load must respond promptly, or the belt may grind to a halt or break. A real-time OS supports the real-time application's ability to meet its timing deadlines. LynxOS makes this possible by
providing fast context switching plus low system call overhead. This helps keep short the execution time of every task.
The LynxOS interrupt system keeps short an interrupt routine's execution time and even bounds the number of interrupts that can occur during the execution of a high-priority task. This is done by having the interrupt handler disable further interrupts from the device before it completes. That device's interrupts are reenabled only by a corresponding kernel thread that actually does most of the interrupt processing. This kernel thread's priority is based on the priorities of the user threads that access the device.
LynxOS contains no system-level tasks that must run at higher priority than user tasks. This is possible because task scheduling is interrupt-driven. There is no single task responsible for scheduling other tasks. If the highest-priority task on the system is a user task and it doesn't release the processor, then nothing else runs. Of course, only tasks that
must
respond promptly or run for a short period of time should execute at very high priority.
Multithreaded Model
Although the Unix process model was used as a basis for LynxOS processes, all tasks under LynxOS are represented internally as threads. A "process" is really just one thread (or more) that has its own protected logical address space. Since a LynxOS process has its own memory context, it is completely shielded from memory corruption by address errors in other processes.
LynxOS uses the standard Unix process model for process creation, destruction, and manipulation. The key difference is that LynxOS threads execute strictly at static, user-set priorities, not at dynamic, varying priorities based on CPU execution or I/O blocking as with Unix. The reason for this is that the Unix model has a concept of "fair-share" scheduling. Processes that perform lots of I/O and consume little CPU time are given the CPU more often (that is, their priority is raised above others
by
the OS) than are CPU-bound processes. This sort of dynamic priority manipulation would be disastrous in a real-time environment where no such policy exists. In fact, scheduling in the ideal real-time environment is completely unfair. Priorities are static and based strictly on time criticality of the tasks, as shown in the figure
"Task Scheduling".
Just in Time
With real-time designs becoming more and more ambitious every year, it has become necessary to use 32-bit processors to provide the throughput required by these applications. Effective use of these processors demands rethinking the role the OS plays in a design. LynxOS has been tailored specifically to deliver everything the 32-bit world offers without sacrificing real-time predictability. It also is compatible with System V and BSD Unix, and is Posix-compliant, so that software designers can use a familiar set of APIs and development tools to create real-time solutions.
Where to Find
Lynx Real-Time Systems
San Jose, CA
Phone: (408) 879-3900
Fax: (408) 879-3920
Internet:
http://www.lynx.com/
A Real OS for Real Time
