Logo   Coding Comments

Dragon Pots...
Wildstar Farm...

Embedded Systems
Web Content
Client List
Coding Comments
HTML tricks
Kyoto Photos
Soaring and Flying

Wildstar at Nason Hill...


Early Photos
Kenya 2016...
Form 990 Calculator...
Mailing lists...
Personal Page...
Photo Library...

Users & Login
Log In...

About Us

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

  • www.on-time.com 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.
  • www.devtools.com Paradigm provides similar tools to OnTime for 16 bit embedded systems. (There is some cross licensing between them.)
  • www.tern.com 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.

Coding Strategy

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.

C++ tools


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 accepted.


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

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.

Code Size

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.

Code Performance

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).

The Dragonnorth Group
We meld the skills of people with the capabilities of computers.

Images and text Copyright © 2000-2024 by The Dragonnorth Group All rights reserved.
Contact: mnewman@dragonnorth.com