Supported processors

  • Motorola MC680xx-family (68K, up to MC68060), MC683xx-family
  • PowerPC (PPC) MPC7447, MPC604, MPC750, MPC8xx, MPC555, MPC56x, MPC5200, MPC509, IOP480, QorIQ (P2020), etc.

Available system components

  • Shell and an interpreter according to Bourne syntax.
  • Hard disk, floppy disk, streamer, CD-ROM.
  • Network support, distributed file system, remote login.
  • Telnet-, ftp- and mail-clients as well as http-, samba-, telnet- and ftp-server.
  • Additional network software by other providers.
  • Field busses, e.g. CAN, INTERBUS-S, PROFIBUS-DP, Profinet, Ethercat.
  • Real-time conform multi-window desktop and multi-window editor.
  • Various compilers and assemblers.
  • Comfortable cyclical, relative and absolute time and event scheduling of tasks (PEARL 90 standard, DIN 66253-2 1998:04).

Compilers and assemblers

  • A PEARL 90-compiler, C-compilers, CoDeSys, a 68K- and a PPC-assembler as well as a translator of 68K-assembler into PPC object code are available.
  • All compilers and assemblers are also available as cross systems (for Windows, Linux) with identical properties.
  • The RTOS-UH loader has an integrated link function so that no individual link-run is necessary. A separate linker is also available.

System size and scalability

  • Due to its modular structure, RTOS-UH is very well scalable in its size.
  • RTOS-UH is completely coded in a portable assembler. Besides compactness this also increases the performance:
    • Interrupt service routines only save registers that are definitely needed by the routine.
    • Registers are more efficiently used than in high-level language realizations.
    • Tasks of the operating system hold important pointers in a register even beyond procedure calls which leads to a faster addressing of all objects.


  • The number of tasks is only limited by the available memory capacity. There are no 'process tables' or similar static limitations.
  • Task management without/with FPU requires approx. 220/500 Byte (68K) or 300/750 Byte (PPC) per task.
  • RTOS-UH is able to load tasks as well as to generate them dynamically with the system's booting or the execution of commands.
  • Terminated tasks do not have to be removed from memory; thus a very fast restart is possible.
  • When a task is activated while it is already running, RTOS-UH buffers the activation. This fault tolerant behaviour guarantees even in case of a high system load a correct even though delayed handling.

Inter task communication

  • Shared variables in any quantity.
  • named pipes in any quantity.
  • Counting and binary semaphores in any quantity.
  • Extremely fast bolt variables in any quantity.
  • Message passing.

Back on top ^

I/O management

In general the I/O system is the weak point of real-time operating systems. RTOS-UH uses from the very beginning the only real-time conform method of I/O demons:

  • An I/O demon is a task which is attended to one of the computer's interfaces, e.g. hard or floppy disk, serial or parallel interface. The complete I/O is fulfilled on user level and I/O operations initiated by low priority tasks only minimally affect the real-time reactivity.
  • The window-management is likewise addressable by an I/O demon.
  • I/O requests of tasks are ranked into the queue of the appropriate I/O demon according to the priority of the requesting task.
  • The variable priority of the I/O demons prevents priority inversion.
  • The complete I/O can be swapped out on slave processors.


  • Real preemption according to priority also within system functions.
  • The internal clock for time scheduling of tasks has a resolution of 50 µs which can be increased in multiples of 50 µs for slower processors.
  • The floating-point-package for trigonometric and exponential functions is running on user level and has therefore no effect on the real-time reactivity.
  • Small reaction times (see 'Technical data') from the external event to the start of the user task.

When comparing systems please pay attention to the following: As in other systems you can add own interrupt handlers, which execute the complete real-time data processing. Though this leads to shorter reaction times, it is strongly recommended to make interrupt handlers as short as possible (e.g. for reasons of preemption, error handling etc). This can be done by activating a user task which then executes the necessary data processing. For safety-conscious users, the values given above describe the important times in which a user task is activated or continued by the interrupt handler.

Technical data

General Data68KPPC
kernel-ROM (min)23 KByte52 KByte
full development ROM318 KByte800 KByte
kernel-RAM (min)5 KByte24 KByte
RAM per task (min)218 Byte300 Byte
RAM per queue (min)90 Byte90 Byte
number of prio. levels32768
max. number of tasksrestrictedby memory size
time atom50 µs
Reaction times 68060/50MHz7455/1GHz
average reaction time8.0 µs3.0 µs
maximum reaction time20.0 µs7.2 µs
av. task switching time5.5 µs0.85 µs