ions of NT. The approaches these two organizations take with their products are quite different, but both of them count on catching some of NT's wake.
NT's Coattails
The potential rewards of using Phar Lap's TNT Embedded ToolSuite, Realtime Edition, version 8.0 (ETS), and Venturcom's Real-Time Extension (RTX) are manifold. First, if you're already familiar with programming to NT's API, you don't have to go to the trouble of learning a new API to use them. All the programming knowledge that you've gained while working with NT in the desktop realm becomes applicable for real-time applications.
Second, programmers can choose from a wide range of development systems. Custom real-time OSes often require the purchase of equally custom and expensive development tools. By contrast, developers using ETS or RTX have the option of using standbys, such as Microsoft's Visual C++ and Borland C++. Along with these tried-and-true development tools com
e some substantial piles of documentation and various other educational materials that are often missing in some custom OSes.
Third -- and most important -- both the host-development and target systems can run the same OS. This means that a great deal of the software development work can be completed before the target hardware is even available to the software engineers. (Venturcom's RTX runs on any Intel hardware that supports NT. Phar Lap's ETS supports standard AT architectures, starting with the 386SX.)
The Challenge
Embedded-systems developers have a short list of "must have" features for any RTOS, whether it's a custom design or one built from a general-purpose OS. For example, a multithreaded RTOS with a moderately sophisticated memory management system must be able to safeguard against the memory-manager thread's waking up and preempting a time-critical interrupt service routine. (The memory-manager thread operates at a high priority to maintain system consistency.)
Su
ch safeguards are critical to providing
determinism
. An RTOS is said to be deterministic if a designer is able to figure out precisely how the system will behave given any set of inputs and the current state of the system at the time the inputs arrive. Most of the time, this boils down to a known and guaranteed task-scheduling protocol.
Because embedded applications usually offer limited memory resources, another important characteristic of an RTOS is the ability to tolerate small living quarters. Some embedded systems must endure size and power restrictions; both translate directly to limits on the amount of silicon a developer can throw at the application. If the real-time system won't fit, no amount of shoehorning will fix the problem. Finally, an RTOS must provide adequate development tools.
Both ETS and RTX need to solve these problems
and
work compatibly with NT, even though NT doesn't natively provide the deterministic task-scheduling necessary for RTOSes. In addition, NT typi
cally runs with applications that offer 32 to 64 MB of memory -- which is hardly a small footprint. While development tools for NT are common, developers using the Phar Lap and Venturcom products need to use those tools in a specialized way.
Inside ETS
Phar Lap's ETS owes a great deal of its heritage to the company's venerable TNT DOS Extender. TNT brings a subset of the Win32 API into a DOS extender to provide developers with access to NT-style multithreading and all the NT-synchronization objects (e.g., events, critical sections, mutexes, and semaphores). Most important, however, is the fact that TNT is a 32-bit flat-memory-model environment. It's about as close to NT without the Windows as you can get. To produce ETS, Phar Lap took the basic TNT technology and added a context-switching and memory-managing heart to produce a stand-alone kernel.
Note that ETS is a single-process, multithreaded environment. It's important to remember that ETS is not
true
NT; it's based on
a subset of the Win32 API. The context-switching component provides determinism via the following easy-to-remember principle: The highest-priority runnable thread will run. This means that a thread will run until it becomes blocked (e.g., while waiting for completion of an I/O operation) or its time slice expires and a thread of equal or higher priority is ready to run.
By contrast, task scheduling in Windows NT is not deterministic. Because ETS is basically a real-time kernel rather than a full-blown OS with its own development tools and supporting applications, it's aimed primarily at the embedded developer working in C and C++. Fortunately, ETS allows a development tool to be selected from among several of the standard NT C/C++ compilers. ETS applications can be constructed using Microsoft's Visual C++, Borland C++, or MetaWare High C/C++.
Well-Timed Interrupts
To understand Venturcom's RTX, you must first understand how NT's hardware abstraction layer (HAL) handles system tim
ing. The HAL intercepts timer interrupts produced by a system's hardware clock. NT's designers programmed these interrupts to occur once per millisecond; the HAL essentially passes the interrupts "up" to the NT kernel. This once-per-millisecond interrupt, which forms the smallest resolution of the NT system, is used to manage device drivers that request timer services.
Every 10 ms, the NT kernel nudges the NT scheduler, which performs whatever process and thread scheduling needs to be done. Hence, 10 ms represents NT's fundamental process/thread time slice. RTX's real-time extensions depend on a cleverly modified HAL that programs the hardware so that interrupts occur once every 100
microseconds
.
This modified HAL delivers interrupt notification in two directions. First, the new HAL continues to inform the NT kernel of interrupts once every 10 ms. In this respect, the NT kernel is unaware that the HAL is acting in a different manner. The second notification sequence, however, sends an interru
pt every 100 ms to Venturcom's RTX. RTX is a sort of real-time kernel that appears to the remainder of NT as a device driver, so it's simultaneously a part of and separate from NT. Tasks running in RTX run at priorities higher than those of NT interrupt handlers. Consequently, RTX tasks cannot be preempted by NT tasks.
Thus, NT's normal functions run unimpaired so that real-time software can execute on an NT system side-by-side with standard, off-the-shelf software. Also, because tasks in the real-time extension execute at a higher priority than NT processes and threads, NT tasks won't destroy the determinism of the real-time extension. Finally, developers can use RTX for SMP (symmetric multiprocessing). On a dual-processor system, one processor can run the real-time extension, and the other one can run NT with no degradation in performance.
Build Your Own Kernel
Both ETS and RTX address the resource limitations of embedded systems via associated products that let you custom-const
ruct a kernel. Phar Lap's Visual System Builder, which comes bundled with ETS, lets you identify
what pieces
you want in your kernel (e.g., keyboard driver or timer driver). Operating Visual System Builder is straightforward: You simply click on check boxes that correspond to the desired components, and the Builder automatically assembles the proper modules. When you compile and link your application's executable image, ETS pulls in the selected modules.
RTX's optional Component Integrator is more elaborate because it helps you assemble a
customized version
of a full-blown NT system. The modules that the Component Integrator must cope with are more complex than keyboard drivers and serial drivers, and these modules are also interdependent. The ultimate goal, however, is the same for both ETS and RTX. Each one allows you to construct a tuned OS core that has only the pieces your application needs.
How do the two products compare in scalability? That depends on
your perspective. Developers who measure ETS by its ability to bear the burden of increasing numbers of tasks find that the product fares well. For example, Ark Degtiarov, principal software engineer for Nova Biomedical, a Boston-based biomedical instrumentation manufacturer, says that his company's blood-analyzing system runs about 40 simultaneous tasks using ETS. He adds that he has never seen a problem with system stability.
Developers might measure scalability with Venturcom's RTX by the number of NT services that are available in conjunction with RTX. Given that, the Component Integrator provides all the scalability necessary at the upper end of the spectrum; there's no reason why a full-blown NT kernel can't be run in conjunction with RTX.
For a deeply embedded application, however, there's a lower end to the spectrum. A minimum embedded NT system with RTX requires about 8 MB of memory (5 to 6 MB for NT, and the rest for the embedded application). ETS fares much better in tight spaces; depending
on how the kernel is carved up, it can take as little as 27 KB of memory.
The Dark Side
Before you think that these products offer perfect solutions, consider some of their drawbacks. For starters, Venturcom's RTX is in an early incarnation and currently supports only soft real-time. In other words, RTX's high-performance, deterministic characteristics have not yet been implemented -- and this is not expected until later this year or early 1997. (A "hard" real-time system guarantees an immediate response to a given stimulus regardless of the system state. In contrast, a "soft" real-time system can tolerate an occasional fraction-of-a-second delay. For example, microwave ovens are soft real-time systems; you wouldn't notice if the oven responded in 2/10 second, rather than 1/10 second, after you pressed the Start button.) In defense of the product, the company claims soft real-time satisfies 95 percent of the real-time marketplace.
Then there's the aforementioned RTX footprint of
about 8 MB. On one hand, this excessive memory requirement exists because RTX runs full-blown NT, not some subset of the Win32 API. On the other hand, this is likely to eliminate RTX from consideration for many deeply embedded applications.
Phar Lap's ETS tackles the real-time embedded market at a lower level than RTS does. This means you'll need to program in C or C++ if you choose to work with it. This isn't completely a fault of ETS; it's intrinsic to hard real-time development. However, this means that the ETS environment is more primitive than what RTX offers. With ETS, you can't currently run an off-the-shelf database package alongside your real-time data-acquisition system.
Note that this primitiveness does not imply higher performance on the part of ETS. (It's often the case that the lower an application's level, the higher its raw performance.) On the contrary, one complaint about ETS is its poor latency (i.e., the time it takes the system to respond to an interrupt). Additionally, the minimu
m time slice for threads running under ETS is 10 ms (the same as for a "regular" NT thread). Compare that to RTX, which can schedule real-time threads in 100-ms time slices.
The Choices
These two products take fundamental-ly different approaches to handling NT. Therefore, you shouldn't have much trouble distinguishing when it's best to use one rather than the other.
Venturcom's RTX and Component Integrator target the high end of the embedded marketplace. These tools benefit applications that incorporate a mixture of real-time and desktop software.
Imagine, for example, a system that controls a complex manufacturing process and perhaps runs a factory's automated assembly line. The shop-floor manager -- who's already familiar with the NT interface on the desktop in the office -- can go to the shop floor and use the same graphical interface to reprogram the assembly line. If this reprogramming task requires that a set of device-control parameters be called up from a database, thi
s could be done with an Access database that communicates directly with the real-time extension tasks that control the devices on the assembly line.
Meanwhile, Phar Lap's ETS works efficiently with deeply embedded applications where resources (available memory, for example) are scarce. Small, application-specific devices that don't require graphical interfaces or a great deal of mass storage are perfect candidates for ETS applications.
In addition, both of these products face some stiff competition from Unix-based RTOSes, such as QNX and Lynx. Still, NT is one big rolling snowball. And although NT is just now entering the embedded world, developers may feel safer working behind the snowball rather than in front of it.
Where to Find
Phar Lap Software, Inc.
Cambridge, MA
Phone: (617) 661-1510
Fax: (617) 876-2972
E-Mail:
info@pharlap.com
Venturcom, Inc.
Cambridge, MA
Phone: (800) 334-8649 or (617) 661-1230
Fax: (617) 577-1607
Internet:
http://www.vci.com
NT in Real Time
