Real-time operating system (RTOS) for small (16-bit)

microcontroller

Su-Lim TAN

School of Computer Engineering

Nanyang Technological University

Singapore

Tran Nguyen Bao Anh

Singapore Engineering Centre

Renesas Technology Singapore

Singapore

Abstract—Real-time operating system (RTOS) is gaining

increasing use not only in 32-bit systems but also in 16-bit

systems. RTOS is different from generic OS by several unique

characteristics and the use of RTOS in embedded system

development proves to be more advantageous. In this paper, 9

RTOSes targeting smaller processors have been evaluated and

four of the RTOSes have been selected for performance

benchmarking on the same M16/62P microcontroller platform to

avoid bias. Based on the comparison, the µTKernel RTOS is

chosen for porting to the H8S/2377 16-bit microcontroller to

demonstrate the ease of RTOS platform migration. The same

version of µTKernel RTOS running on different platforms are

then compared. Lastly, an application is developed with the

RTOS to demonstrate the ease of multi-task application

development on such microcontroller platform.

Keywords-kernel; operating system; real-time system; RTOS;

RTOS benchmarking

I. INTRODUCTION

Real-time embedded systems are typically designed for various purposes such as to control or to process data. Characteristics of real-time system include meeting certain deadlines at the right time. To achieve this purpose, real-time operating system (RTOS) is often used. An RTOS is a piece of software with a set of APIs for users to develop applications. Using an RTOS does not guarantee that the system will always meet its deadlines, as it depends on how the overall system is designed and structured.

While RTOS for embedded systems are predominantly

employed in high-end microprocessors or microcontrollers

with 32-bit central processing unit (CPU), there is an

increasing trend to provide these features in the mid-range

(16-bit and 8-bit) processor systems. An operating system

(OS) is a piece of software that manages the sharing of

resources in a computer system. RTOS is often

differentiated from generic OS as it is specifically designed

for scheduling to achieve real-time responses.

There are a number of variants of RTOSes available

nowadays; they range from commercial, proprietary, to

open-source RTOSes. For small-scaled embedded systems

designed using small microcontrollers (i.e. microcontrollers

with typical ROM of 128Kbytes and RAM of 4Kbytes [1]),

it is common perception that there is no need to have an

RTOS. However, there are significant advantages to have

RTOS for this range of devices [1-2], such as:

• Optimizing software development: Even in system

development using small microcontrollers,

improving software productivity is a critical issue,

due to time-to-market pressure as well as shorten

development cycle [3]. As the code complexity

grows, an RTOS is an efficient tool to manage the

code, and to distribute the tasks among developers.

Using an RTOS will allow the entire software to be

partitioned into tasks taken care by individual

programmers.

• Better and safer synchronization: In small

embedded system development without using any

RTOS, global variables are often used for

synchronization among modules/functions. However,

especially in highly interrupt-driven system, using

global variables lead to bugs and software safety

issues [4]. These global variables are often shared

and accessed among the functions, and there is high

chance of them being corrupted any time during the

program execution. With an RTOS in place,

synchronization is safely managed and tasks can pass

messages or synchronize with each other without any

corruption problem.

• Resource management: Most RTOSes provide APIs

for developers to manage the system resources [4].

These include task management, memory pool

management, time management, interrupt

management, communication and synchronization

methods. These features provide the abstraction layer

for developers to freely structure the software to

achieve cleaner code.

• Timing management by RTOS: With time

management functions, software designers can

achieve task delay, timer handling or time-triggered

processing without resorting to understanding the

underlying hardware mechanisms. As compared with

a small system that does not use any RTOS,

achieving timing related features can be tricky, as the

software designer needs to understand the underlying

peripherals (such as timers), how to use it, and how

to link it with the top-level application code.

The 13th IEEE International Symposium on Consumer Electronics (ISCE2009)

978-1-4244-2976-9/09/$25.00 ©2009 IEEE 1007

II. STUDY AND COMPARISON OF EXISTING RTOSES FOR

SMALL MICROCONTROLLERS

The objective here is to investigate RTOSes available

(open-source, commercial, and research) and determine

those that are suitable for small microcontrollers only.

Information is mainly based on documentations and APIs

available on websites. These RTOSes are: µITRON,

µTKernel, µC-OS/II, EmbOS, FreeRTOS, Salvo, TinyOS,

SharcOS, XMK OS, Echidna, eCOS, Erika, Hartik, KeilOS,

and PortOS. Below summarized some of the criteria used

for comparison.

• Priority-based preemptive scheduling has been

adopted by majority of the RTOSes, except for two

RTOSes in the list (Salvo and TinyOS) using

cooperative scheduling.

• Majority of RTOSes support C language, which is

the popular choice for embedded system

programming, especially in small system design.

• Only a few RTOSes have OS-awareness support in

IDE: µC-OS/II and EmbOS have plug-in modules for

IAR compiler; KeilOS is supported by Keil compiler;

µITRON and µTkernel are supported by Renesas

HEW compiler.

• In the case of eCOS [5], it requires a bootloader

(known as Redboot) of at least 64Kbytes ROM.

Redboot will boot up first and load programs into

RAM via user terminal. Hence, eCOS requires much

more ROM and RAM spaces.

• As far as documentation is concerned, some RTOSes

(KeilOS, PortOS and XMK) do not have details of

APIs available. SharcOS is based on µC-OS/II, so it

follows the same APIs of µC-OS/II. For the above

reasons, these RTOSes will not be considered for the

following APIs comparison.

Figure 1 shows a comparison of the number of system

APIs available for each RTOS. Based on the RTOSes’

common definitions, the APIs shown in Figure 1 are

categorized into:

• System management: initialize OS, start/shutdown

OS, lock/unlock CPU, etc.

• Interrupt management: entry/exit function,

begin/end critical section, etc.

• Task management: create task, delete task, start

task, terminate task, etc.

• Task-dependent synchronization: sleep task,

wakeup task, resume task, etc.

• Communication and synchronization: semaphore,

data queue, event flag, mailbox, mutex, etc.

• Memory management: fixed size memory pool,

variable-size memory pool, etc.

• Time management: get system operating time, OS

timer, etc.

• Trace API: hook routine into certain RTOS

functions such as scheduler, etc.

Figure 1: Number of system APIs for various RTOSes

µITRON, µTKernel, µC-OS/II and EmbOS support

comprehensive APIs for all the categories above. Most

commercial RTOSes are well-implemented, with µITRON

supporting all the categories except for trace functions.

EmbOS also supports most of the categories, except for

trace, system time management, system management and

message buffer.

As far as open-source RTOSes (FreeRTOS, Echidna,

Erika and Hartik) are concerned, most have only minimal

implementation. These RTOSes are more suitable for very

small system development. However, µC-OS/II stands out

to have more APIs available. Among the open-source

RTOSes surveyed, µC-OS/II and µTKernel have the most

number of APIs available. µTKernel supports all of the

categories, except for data queue. It also has almost the

same APIs as the commercial RTOS µITRON, as it is

backed by T-Engine Forum [6] led by Professor Ken

Sakamura who is also the designer of µITRON architecture.

Number of system APIs

1008

For the above reasons, these 4 RTOSes: µITRON,

µTKernel, µC-OS/II and EmbOS will be focused for the

subsequent comparison and benchmarking.

Besides those functions mentioned in Figure 1, the

following are also supported by some RTOSes:

• Timeout: timeout is supported in some system APIs.

For example, a task can wait for a semaphore for a

maximum number of n milliseconds. RTOSes such

as µITRON and µTKernel have mechanisms to allow

users to specify the timeout in absolute values.

Others such as µC-OS/II, FreeRTOS, Salvo and

EmbOS can only allow user to specify timeout

values in terms of the number of clock ticks.

• Debug API: these are the APIs that allows user’s

application to retrieve information managed by the

kernel. Currently, only µTKernel supports these APIs

(e.g. get task register, set task register).

• Cyclic handler, alarm handler: cyclic handler a

mechanism to indicate to the RTOS to execute a

function at a periodic interval while alarm handler

allows RTOS to execute a function after certain

amount of time. These APIs are currently available in

µITRON and µTKernel.

• Rendezvous: µITRON and µTKernel also support

rendezvous mechanism for synchronization and

communication between tasks.

For µC-OS/II and EmbOS, tasks are queued in a FIFO

(first in first out) buffer when waiting for a semaphore, and

developers cannot change this order. On the other hand, in

µITRON and µTKernel, developers can specify whether

tasks are queued in FIFO order or in priority order. This

flexibility applies not only to semaphore, but also to other

APIs, including mailbox, message queue, memory pool and

event flag. To achieve such features in µITRON and

µTKernel, there are tradeoffs in memory footprint as well as

performance.

III. PERFORMANCE BENCHMARKING OF RTOSES

Four RTOSes (µITRON, µTKernel, µC-OS/II and

EmbOS) have been selected for performance benchmarking

on the Renesas M16C/62P 16-bit microcontroller platform,

the main reasons these RTOSes were selected are:

• Comprehensive and mature APIs.

• Footprint and design concepts are suitable for small

microcontrollers.

• These four RTOSes are ported onto the Renesas

M16C/62P platform with the HEW IDE together

with the NC30 toolchain [7]. An in-depth evaluation

is made to compare the performance of these four

RTOSes running on the same platform.

For each criterion, the benchmarking code is compiled,

and ROM and RAM usage will be obtained from the

toolchain report. By averaging the ROM information across

all the test criteria, the average ROM sizes can be obtained.

Figure 2 shows the code size and data size for the 4 RTOSes

when running the 7 benchmarks listed in the legend.

Figure 2: Code and data size comparison for 4 RTOSes

µTKernel can be observed to require a larger code space.

This is due to the flexibility and comprehensiveness support

in the APIs. On the other hand, µITRON and EmbOS,

which are commercial RTOSes, offer relatively compact

code sizes. Nevertheless, all these RTOSes can fit well in

small microcontroller of limited ROM sizes.

As for RAM usage, µTKernel and µITRON lower

requirements, while µC-OS/II and EmbOS are slightly

higher. In summary, the ROM and RAM usage of all these

RTOSes are well suited for small microcontrollers.

µC-OS/II µTKernel EmbOS µITRON

Code size (ROM) Data size (RAM)

Byte

s

B

yte

s

µC-OS/II µTKernel EmbOS µITRON

Task switch time Get & release Semaphore (one task) Pass semaphore (from one task to another) Pass & retrieve message to queue Pass message (from one task to another) Acquire & release fixed-size memory block Task activation from interrupt

1009

Figure 3 shows the measurements of execution times of

the RTOSes for different benchmark criteria. µTKernel is

shown to have the lowest task switching time, followed by

µITRON, µC-OS/II and EmbOS. On the other hand, µC-

OS/II semaphore acquire and release time are the fastest.

However, the fastest inter-task semaphore passing is

achieved by µITRON. µC-OS/II and µTKernel have better

message passing and message retrieval time as compared to

µITRON and EmbOS. As far as fixed-size memory

allocation is concerned, µC-OS/II has the best execution

time, followed by EmbOS, µITRON and µTKernel. Finally,

µTKernel has the best performance time for task activation

from interrupt handler, followed by µC-OS/II, µITRON and

EmbOS.

Figure 3: Execution time benchmark for 4 RTOSes

IV. µTKERNEL IMPLEMENTATION ON RENESAS H8S/2377

With the benchmarking results shown previously, each

RTOS stands out to have its own strengths and weaknesses.

As far as open-source RTOS is concerned, for a very small

and compact ROM size RTOS, µC-OS/II can be used.

However, to have a more comprehensive APIs support,

µTKernel is recommended with a slightly higher ROM

footprint. Taking into considerations all the above, and most

importantly the need for an open and freely available RTOS

for both educational and commercial used with OS

awareness support, the µTKernel is eventually selected.

µTKernel specifications [8] govern the basic design

policies of µTKernel. These specifications include system

calls that have to be supported, system call prototypes (C

language), naming conventions, return values conventions,

as well as the licenses for distribution of reference source

code and object code. The reference source code comes with

implementation for ATmel AT91 microcontroller is based

on the free GNU toolchain. To preserve the original source

tree structure, a new version of the port for H8S/2377 is

added.

µTKernel implementation includes both hardware-

dependent and hardware-independent parts. Those

hardware-independent portion of the code are written in ‘C’

and hence do not requires any changes. It is important to

study the source code in details to understand how the

hardware-dependent parts work and how they are linked to

the hardware-independent parts. These portions are usually

related to the microcontroller’s hardware architecture that

requires specific in-depth knowledge, especially those

related to CPU operating modes and interrupt controls.

Detail of the porting is beyond the scope of this paper but is

available here [9]. Below shows some of the primary

characterization results of the µTKernel after it is

successfully ported over to the H8S/2377 microcontroller.

ROM (min) ROM (typ.) RAM (min) RAM (typ.)

5.94 % 9.64 % 33.76 % 47.26 %

Table 1: Minimum and typical ROM and RAM ultisation

Table 1 shows the ROM and RAM sizes (in bytes), with

minimal and typical µTKernel’s configurations. These

percentage values indicate how much memory is used from

the maximum on-chip memory of H8S/2377, i.e. ROM

(384KB) and RAM (24KB).

Figure 4: Execution time comparison of µTKernel

implementation on H8S/2377 and M16C/62P.

A similar performance benchmark is conducted to evaluate

the newly ported µTKernel RTOS on the H8S/2377

microcontroller. Figure 4 shows the results of those critical

parameters when compared to the µTKernel implementation

on the M16C/62P microcontroller running at 24 MHz for

both microcontrollers. It is noted that most parameters are

on par except a few where the advantages are related to

microcontroller’s unique architecture. Although both

microcontrollers are 16-bit and running at 24 MHz,

M16/62P has a higher performance CPU of 16 MIPS

compared to H8S/2377 with only 11 MIPS. In addition, the

following could potentially explain the performance

disparity between the same RTOS running on different

µTKernel on H8S/2377 µTKernel on M16C/62P

µC-OS/II µTKernel EmbOS µITRON

Mic

ro-s

econd

s

Mic

ro-s

econd

s

Task switch time

Get semaphore

Release semaphore

Pass semaphore (from one task to another)

Pass message to queue

Retrieve message from queue

Pass message (from one task to another)

Acquire fixe3d-size memory block

Release fixed-size memory block

Task activation from interrupt

Average execution time

1010

microcontrollers. Firstly, µTKernel implementation for

M16C/62P has two instructions for the system call interface

instead of five in H8S/2377. Also, the commonly used

instruction (MOV.W) takes 4 clock cycles to execute in

M16/62P but 5 cycles in H8S/2377. Moreover, M16/62P

has a wider range of addressing modes (e.g. SP relative) and

instructions (91 instructions in M16/62P compared to 65 in

H8S/2377) which speed up execution for stack pointer

related operations. Lastly, M16/62P CPU has a 4-stage

instruction queue buffer (similar to simplified pipeline) that

will help to reduce the execution time.

Figure 5 shows the screen capture of a simple application

that has been developed to showcase the deployment of the

µTKernel RTOS on H8S/2377. There are 9 different tasks

running concurrently to demonstrate the ease towards

creating multi-tasking applications on a small

microcontroller using an RTOS. Each task has been

allocated a different task priority and numerous inter-tasks

communication mechanisms have been used to pass

information between tasks. Details of this application can

also be found here [9].

Figure 5: Demonstration of µTKernel RTOS deployment.

V. CONCLUSION

RTOS is increasingly popular for deployment with

microcontroller-based embedded systems design. It can

helps to improve the development cycles, code reusability,

easy of coding as well as maintenance, better resource and

timing management even for small microcontrollers. RTOS

can be differentiated from generic OS in terms of scheduling

(priority-based), predictability in inter-task synchronization,

and deterministic behaviors. In this paper, a list of RTOSes

have been evaluated based on various selection criteria

targeting small microcontrollers with about 128Kbytes of

ROM and 4Kbytes of RAM. Subsequently, µC-OS/II,

µTKernel, EmbOS and µITRON were selected and

benchmarked on the same microcontroller platform. A list

of benchmarking criteria which is aimed to be simple, easy

to be ported to different RTOS platforms and representative

typical RTOS usages were used. The results show that each

RTOS has different strengths and weaknesses without any

clear emerging winner. With these detailed performance

benchmarks, potential adopters of these RTOSes can

simplify their selection by examining their specific

application requirements. Lastly, the µTKernel was ported

to the H8S/2377 microcontroller and the two systems

compared.

REFERENCES

[1] K. Sakamura, H. Takada, “µITRON for small scale embedded

systems”, IEEE Micro, vol. 15, pp. 46–54, Dec. 1995.

[2] J. Ganssle, “The challenges of real-time programming”, Embedded

System Programming magazine, vol. 11, pp. 20–26, Jul. 1997.

[3] CMP Media, “State of embedded market survey”, Embedded System

Design Magazine, 2004.

[4] CMP Media, “State of embedded market survey”, Embedded System

Design Magazine, 2006.

[5] A. J. Massa, “Embedded software development with ECOS?” Prentice

Hall, Nov. 2002.

[6] T-Engine, “T-Engine forum”, http://www.t-engine.org/, Nov. 2007.

[7] Renesas Technology Corp., “Renesas high-performance embedded

workshop (HEW)”, http://www.renesas.com/fmwk.jsp?cnt=ide_hew

_tools_product_landing.jsp&fp=/products/tools/ide/ide_hew/, 2007.

[8] D. Kalinsky, “Basic concepts of real-time operating systems”,

LinuxDevices magazine, Nov. 2003.

[9] Tran Nguyen Bao Anh, A real-time operating system for 16-bit

microcontroller, MSc dissertation, School of Computer Engineering,

Nanyang Technological University, Singapore, May 2008.

1011