Real Time Systems
What is a real time system?
A system is "real-time" when it can under all circumstances guarantee a
particuar response time to particular events.
Real Time System does not mean fast system. If a system always needs one
second or one hour to react on some situation it can still be real-time when it can
always guarantee the same time.
Tools and Resources
On Time provides royalty-free real-time operating systems (RTOS) for 32 bit x86 embedded systems.
The OnTime mailing lists often provide coding insight and are a good forum for help.
Paradigm provides similar tools to OnTime for 16 bit
embedded systems. (There is some cross licensing between them.)
Tern makes general purpose x86 controllers and special purpose expansion boards that plug in
to the controllers for tasks like motor control, drivers and relays.
www.pjrc.com make a nice little board for simple 8051
applications. Their board comes complete with a software monitor and needs no special development
environment or ROM programming hardware. Open source compilers and tools are listed on their site.
This is a discussion of embedded coding issues collected over the years. Many of the paragraphs
have been stolen from the wise comments of others.
(Thanks in particular to Norbert Unterberg.)
According to some, real-time firmware/software should avoid using exception,
multiple inheritance and template specialization.
C++ is like a toolbox. As with any tool, the tool itself is not "good" or
"bad". The person using the tool must know the purpose and use of a tool to
be able to gain advantages from the tool or to know when a tool does not
fit. There are "good" and "bad" ways to use a tool.
The "simple" usage of classes does not generate much overhead. When
calling non-static member functions, one hidden argument is passed to the
called function ("this"-pointer). When calling virtual member functions
usually one additional function pointer lookup takes place. When this does
not happen in a tight time-critical loop this overhead can usually be
When using templates you might end up with more code.
However, this usually does not mean you get slower code; it is the other way
round: Templates enable you to write generic code that is automatically
adapted to the data types as you use it. So you might even get better
specialized code from generic templates. The cost is that a template will be
instantiated for every different class/function it needs to implement. This
can give you larger code because code with nearly the same function/task is
put multiple times into your target.
You must indeed be very careful with exceptions. You should use
exceptions to handle errors or overlooked situations in your code.
(This advice applies to
all code not just real-time code). Exceptions are situations that do
not belong to the normal operation. So in well-designed code, an exception
is something that is triggered when the "normal" or expected ways to handle error
situations have failed.
In general using exceptions (by using try/catch) does not create much
overhead to the normal operation of the code. It does, however, create large
overhead when the exception is actually thrown. So do not use execptions to
control the "normal" execution of code in your real-time tasks.
Multiple Inheritance carefully used can have no more overhead than a simple class or
structure. Unexpected overhead occurs when the classes are virtual and the inheritance
tree is not simple. The unexpected overhead can be large and can occur at run time.
Copying large blocks of data for each use is possible.
As a general practice try to use multiple inheritance only for classes that were carefully
designed for this type of inheritance.
Memory has become cheap. Most embedded platforms include far more memory than
will be used because the parts come that size. It is usually far cheaper to
add memory to the system design than to solve probles with more complex code
or a faster processor. The need to save memory is usually a warning sign that
something far more fundamental is wrong with the design or implementation. Look for
the bigger problem instead.
There are usually two parts to any real time system. The system usually contains
a small body of core real time code
and a large body of general support and environmental code. Experiance
in high capacity ATM audio streaming shows that improving anything but the core is pointless. If
the core is well designed and independent of the general code, improving the general code
will have no effect on overall performance.
The core code requires careful work. First design the system to work well.
This is akin to selecting a searching method, binary search is faster but more complex than linear search.
In real time systems the design for speed is often an issue of what can be handled by indexed
lookups rather than computation. For example decoding an 8 bit mu law encoded audio stream to a 16 bit
level can be done arithmetically. A faster way is to precompute a 256 entry table and simply look up
the answer in the table.
Using the more complex language features of C++ has issues and benefits.
You as the developer have to decide if the benefit you get from the new C++
language features justify the cost in terms of performance and code size.
Usually a real time product only contains very little true real-time code, so you
might end up mixing the best from both worlds: Using very few complex C++ features where
you need every CPU cycle, and use the C++ features in places that are not
time critical (like low priority user interface tasks).