The 13th IEEE International Symposium on Consumer Electronics (ISCE2009)
Real-time operating system (RTOS) for small (16-bit)
microcontroller
Su-Lim TAN
School of Computer Engineering
Nanyang Technological University
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
978-1-4244-2976-9/09/$25.00 ©2009 IEEE
Authorized licensed use limited to: Gheorghe Asachi Technical University of Ia¿i. Downloaded on June 03,2021 at 20:21:02 UTC from IEEE Xplore. Restrictions apply.
Tran Nguyen Bao Anh
Singapore Engineering Centre
Renesas Technology Singapore
Singapore
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.
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
Number of system APIs
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
1008
Authorized licensed use limited to: Gheorghe Asachi Technical University of Ia¿i. Downloaded on June 03,2021 at 20:21:02 UTC from IEEE Xplore. Restrictions apply.
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.
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.
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
Code size (ROM)
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
Bytes
fixed-size memory block
Bytes
Task activation from
interrupt
µC-OS/II µTKernel EmbOS µITRON
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
1009
Authorized licensed use limited to: Gheorghe Asachi Technical University of Ia¿i. Downloaded on June 03,2021 at 20:21:02 UTC from IEEE Xplore. Restrictions apply.
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.
Data size (RAM)
µC-OS/II µTKernel EmbOS µITRON
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.
 Figure 3 shows the measurements of execution times of dependent and hardware-independent parts. Those
the RTOSes for different benchmark criteria. µTKernel is hardware-independent portion of the code are written in ‘C’
shown to have the lowest task switching time, followed by and hence do not requires any changes. It is important to
µITRON, µC-OS/II and EmbOS. On the other hand, µC- study the source code in details to understand how the
OS/II semaphore acquire and release time are the fastest. hardware-dependent parts work and how they are linked to
However, the fastest inter-task semaphore passing is the hardware-independent parts. These portions are usually
achieved by µITRON. µC-OS/II and µTKernel have better related to the microcontroller’s hardware architecture that
message passing and message retrieval time as compared to requires specific in-depth knowledge, especially those
µITRON and EmbOS. As far as fixed-size memory related to CPU operating modes and interrupt controls.
allocation is concerned, µC-OS/II has the best execution Detail of the porting is beyond the scope of this paper but is
time, followed by EmbOS, µITRON and µTKernel. Finally, available here [9]. Below shows some of the primary
µTKernel has the best performance time for task activation characterization results of the µTKernel after it is
from interrupt handler, followed by µC-OS/II, µITRON and successfully ported over to the H8S/2377 microcontroller.
EmbOS.
ROM (min) ROM (typ.) RAM (min) RAM (typ.)
Task switch time
Get semaphore
Release semaphore
5.94 % 9.64 % 33.76 % 47.26 %
Pass semaphore (from one task to another)
Pass message to queue Table 1: Minimum and typical ROM and RAM ultisation
Retrieve message from queue
Pass message (from one task to another)
Acquire fixe3d-size memory block
Table 1 shows the ROM and RAM sizes (in bytes), with
Release fixed-size memory block
minimal and typical µTKernel’s configurations. These
Micro-seconds

Task activation from interrupt

Average execution time
percentage values indicate how much memory is used from
the maximum on-chip memory of H8S/2377, i.e. ROM
(384KB) and RAM (24KB).
Micro-seconds

µC-OS/II µTKernel EmbOS µITRON

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-
µTKernel on H8S/2377 µTKernel on M16C/62P
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

1010
Authorized licensed use limited to: Gheorghe Asachi Technical University of Ia¿i. Downloaded on June 03,2021 at 20:21:02 UTC from IEEE Xplore. Restrictions apply.
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: 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
1011
Authorized licensed use limited to: Gheorghe Asachi Technical University of Ia¿i. Downloaded on June 03,2021 at 20:21:02 UTC from IEEE Xplore. Restrictions apply.
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].
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.