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.