[Engineering Essentials]
The RTOS Motto: On Time And On Budget
Scheduling and resource allocation are the dominant factors in determining what real-time operating system fits best.
The move to multicore with larger cores will likely retain the RTOS or an OS. However, smaller cores obviate or limit the possibility of an RTOS. Intellasys’ SEAforth 40C18 chip contains 40 small 18-bit cores that run Forth (see “Are You Migrating To Massive Multicore Yet?” at www.electronicdesign.com, ED Online 19976). The instructions are compact, so each word holds four instructions.
Each core has 64 words of ROM and RAM, and the chip has space for only 10,000 instructions. That’s barely enough to fit a program, let alone an RTOS. Still, enough space exists to place dedicated parts of an operating environment throughout the chip. Likewise, the applications for this platform are often dedicated. Thus, RTOS-style support isn’t required since the hardware is handling core-to-core communication and task dispatch.
MANAGING RESOURCES What distinguishes an RTOS is its ability to manage resources, including time and memory. Timing issues are associated with interrupt response time, but resource-management timing issues occur, too. Though interrupts address a number of timing issues, applications must still utilize resources.
Consider memory allocation. Many real-time applications forego dynamic memory allocation to make sure it doesn’t become an issue because of the variance that can occur due to allocation and deallocation. Applications that need dynamic memory allocation often split them into real-time and non-real-time portions. The latter handles dynamic memory allocation. Typically, the real-time portion must have enough memory allocated before it’s used.
C and C++ are used in real-time embedded applications because memory and other resource usage is explicit. Real-time tasks need to avoid C and C++. In particular, it’s more difficult with C++, where allocation and deallocation are more easily hidden but the process is still manageable.
The challenge is greater with languages such as Java and C#, which inherently use dynamic memory allocation. The programmer can control memory allocation and deallocation. In some instances, the programming environment can enforce memory allocation and deallocation.
The Real Time Specification for Java (RTSJ) defines ways to create Java applications that do not need garbage collection. RTSJ does so within the Java framework, enabling programmers to gain the advantages of Java without the memory-allocation limitations.
Both Sun an DDC-I have implementations of RTSJ. DDC-I’s supports x86 and PowerPC platforms. Aonix has a similar real-time platform called PERC. These platforms feature real-time, concurrent garbage collectors that make it possible to write real-time applications in Java without the memory-allocation limitations.
However, the real-time requirements aren’t as tight because the system must allow thread switches for the garbage collector. On the other hand, the garbage collector will consume timing resources, though only when real-time tasks can guarantee that certain deadlines are met. Fast is good, but on time is the RTOS credo.
One consideration when looking at realtime platforms is the overall impact memory allocation will have on a system. Many systems can operate with a static allocation that never changes, but more dynamic systems could benefit from real-time garbage collection instead. Studies show that efficiency of garbage collection versus explicit memory allocation is comparable.
Another issue surrounding virtualmachine- style platforms such as Java and C# is the use of a just-in-time (JIT) compiler. Real-time systems based on these types of systems must employ ahead-oftime (AOT) compilers like C and C++.
Designers may choose Java or C# for their improved productivity, lower susceptibility to bugs, and safety. It should come as no surprise, then, that a safety-critical Java specification dubbed JSR-302 is in the works (see “Critical Java,” ED Online 8116).
SECURING AN RTOS An RTOS is limited by the hardware it runs on. Hardware that lacks memory protection can be secured, but the level of security will be limited. Memory and virtual- machine support usher in a higher level of security, though. Security policies like those in SE Linux, Green Hills Integrity, and LynuxWorks LynxSecure Embedded Hypervisor and LynxOS-SE RTOS offer much more security than a typical RTOS. Cost is higher, however, so developers need to weigh the tradeoff.
Real-time developers will have to contend with policy implementation and boundaries. Security support can take lots of time, depending on where information is coming from and going. This is where partitioned systems step in, so security can be applied at the boundaries and with non-real-time portions of the application in that space.
OS AWARE DEBUGGERS Debugger support is a key factor to consider when looking at any operating system. This support shows up in two areas: kernel and device driver debugging, and OS awareness.
Kernel debugging is critical to the creation and support of device drivers and kernel enhancements. In many cases, a special debugger is required to handle an RTOS’s kernel. In others, the debugging understands the kernel environment as well as the application environment.
OS awareness provides insights into the operating system. Support can vary from providing information about OS service state to the ability to adjust task scheduling. Likewise, an OS-aware debugger typically lets other applications or threads run while the debugger stops another.
Reprints
