The 13th IEEE International Symposium on Consumer Electronics (ISCE2009) Real-time operating system (RTOS) for small (16-bit) microcontroller Su-Lim TAN Tran Nguyen Bao Anh School of Computer Engineering Singapore Engineering Centre Nanyang Technological University Renesas Technology Singapore Singapore Singapore Abstract —Real-time operating system (RTOS) is gaining RTOS for this range of devices [1-2], such as: increasing use not only in 32-bit systems but also in 16-bit • Optimizing software development : Even in system systems. RTOS is different from generic OS by several unique development using small microcontrollers, characteristics and the use of RTOS in embedded system development proves to be more advantageous. In this paper, 9 improving software productivity is a critical issue, RTOSes targeting smaller processors have been evaluated and due to time-to-market pressure as well as shorten four of the RTOSes have been selected for performance development cycle [3]. As the code complexity benchmarking on the same M16/62P microcontroller platform to grows, an RTOS is an efficient tool to manage the avoid bias. Based on the comparison, the µTKernel RTOS is code, and to distribute the tasks among developers. chosen for porting to the H8S/2377 16-bit microcontroller to Using an RTOS will allow the entire software to be demonstrate the ease of RTOS platform migration. The same version of µTKernel RTOS running on different platforms are partitioned into tasks taken care by individual then compared. Lastly, an application is developed with the programmers. RTOS to demonstrate the ease of multi-task application • Better and safer synchronization : In small development on such microcontroller platform. embedded system development without using any Keywords-kernel; operating system; real-time system; RTOS; RTOS, global variables are often used for RTOS benchmarking synchronization among modules/functions. However, especially in highly interrupt-driven system, using I. INTRODUCTION global variables lead to bugs and software safety Real-time embedded systems are typically designed for issues [4]. These global variables are often shared various purposes such as to control or to process data. and accessed among the functions, and there is high Characteristics of real-time system include meeting certain chance of them being corrupted any time during the deadlines at the right time. To achieve this purpose, real-time program execution. With an RTOS in place, operating system (RTOS) is often used. An RTOS is a piece synchronization is safely managed and tasks can pass of software with a set of APIs for users to develop applications. Using an RTOS does not guarantee that the messages or synchronize with each other without any system will always meet its deadlines, as it depends on how corruption problem. the overall system is designed and structured. • Resource management : Most RTOSes provide APIs for developers to manage the system resources [4]. While RTOS for embedded systems are predominantly These include task management, memory pool employed in high-end microprocessors or microcontrollers management, time management, interrupt with 32-bit central processing unit (CPU), there is an management, communication and synchronization increasing trend to provide these features in the mid-range methods. These features provide the abstraction layer (16-bit and 8-bit) processor systems. An operating system for developers to freely structure the software to (OS) is a piece of software that manages the sharing of achieve cleaner code. resources in a computer system. RTOS is often • Timing management by RTOS : With time differentiated from generic OS as it is specifically designed management functions, software designers can for scheduling to achieve real-time responses. achieve task delay, timer handling or time-triggered There are a number of variants of RTOSes available processing without resorting to understanding the nowadays; they range from commercial, proprietary, to underlying hardware mechanisms. As compared with open-source RTOSes. For small-scaled embedded systems a small system that does not use any RTOS, designed using small microcontrollers (i.e. microcontrollers achieving timing related features can be tricky, as the with typical ROM of 128Kbytes and RAM of 4Kbytes [1]), software designer needs to understand the underlying it is common perception that there is no need to have an peripherals (such as timers), how to use it, and how RTOS. However, there are significant advantages to have to link it with the top-level application code. 978-1-4244-2976-9/09/$25.00 ©2009 IEEE 1007 II. STUDY AND COMPARISON OF EXISTING RTOS ES FOR more ROM and RAM spaces. SMALL MICROCONTROLLERS • As far as documentation is concerned, some RTOSes The objective here is to investigate RTOSes available (KeilOS, PortOS and XMK) do not have details of (open-source, commercial, and research) and determine APIs available. SharcOS is based on µC-OS/II, so it those that are suitable for small microcontrollers only. follows the same APIs of µC-OS/II. For the above Information is mainly based on documentations and APIs reasons, these RTOSes will not be considered for the available on websites. These RTOSes are: µITRON, following APIs comparison. µTKernel, µC-OS/II, EmbOS, FreeRTOS, Salvo, TinyOS, Figure 1 shows a comparison of the number of system SharcOS, XMK OS, Echidna, eCOS, Erika, Hartik, KeilOS, APIs available for each RTOS. Based on the RTOSes’ and PortOS. Below summarized some of the criteria used common definitions, the APIs shown in Figure 1 are for comparison. categorized into: • Priority-based preemptive scheduling has been • System management : initialize OS, start/shutdown adopted by majority of the RTOSes, except for two OS, lock/unlock CPU, etc. RTOSes in the list (Salvo and TinyOS) using • Interrupt management : entry/exit function, cooperative scheduling. begin/end critical section, etc. • Majority of RTOSes support C language, which is • Task management : create task, delete task, start the popular choice for embedded system task, terminate task, etc. programming, especially in small system design. • Task-dependent synchronization : sleep task, • Only a few RTOSes have OS-awareness support in wakeup task, resume task, etc. IDE: µC-OS/II and EmbOS have plug-in modules for • Communication and synchronization : semaphore, IAR compiler; KeilOS is supported by Keil compiler; data queue, event flag, mailbox, mutex, etc. µITRON and µTkernel are supported by Renesas • Memory management : fixed size memory pool, HEW compiler. variable-size memory pool, etc. • In the case of eCOS [5], it requires a bootloader • Time management : get system operating time, OS (known as Redboot) of at least 64Kbytes ROM. timer, etc. Redboot will boot up first and load programs into • Trace API : hook routine into certain RTOS RAM via user terminal. Hence, eCOS requires much functions such as scheduler, etc. Number of system APIs Figure 1: Number of system APIs for various RTOSes µITRON, µTKernel, µC-OS/II and EmbOS support implementation. These RTOSes are more suitable for very comprehensive APIs for all the categories above. Most small system development. However, µC-OS/II stands out commercial RTOSes are well-implemented, with µITRON to have more APIs available. Among the open-source supporting all the categories except for trace functions. RTOSes surveyed, µC-OS/II and µTKernel have the most EmbOS also supports most of the categories, except for number of APIs available. µTKernel supports all of the trace, system time management, system management and categories, except for data queue. It also has almost the message buffer. same APIs as the commercial RTOS µITRON, as it is As far as open-source RTOSes (FreeRTOS, Echidna, backed by T-Engine Forum [6] led by Professor Ken Erika and Hartik) are concerned, most have only minimal Sakamura who is also the designer of µITRON architecture. 1008 For the above reasons, these 4 RTOSes: µITRON, developers cannot change this order. On the other hand, in µTKernel, µC-OS/II and EmbOS will be focused for the µITRON and µTKernel, developers can specify whether subsequent comparison and benchmarking. tasks are queued in FIFO order or in priority order. This Besides those functions mentioned in Figure 1, the flexibility applies not only to semaphore, but also to other following are also supported by some RTOSes: APIs, including mailbox, message queue, memory pool and • Timeout : timeout is supported in some system APIs. event flag. To achieve such features in µITRON and For example, a task can wait for a semaphore for a µTKernel, there are tradeoffs in memory footprint as well as maximum number of n milliseconds. RTOSes such performance. as µITRON and µTKernel have mechanisms to allow users to specify the timeout in absolute values. III. PERFORMANCE BENCHMARKING OF RTOS ES Others such as µC-OS/II, FreeRTOS, Salvo and Four RTOSes (µITRON, µTKernel, µC-OS/II and EmbOS can only allow user to specify timeout EmbOS) have been selected for performance benchmarking values in terms of the number of clock ticks. on the Renesas M16C/62P 16-bit microcontroller platform, • Debug API : these are the APIs that allows user’s the main reasons these RTOSes were selected are: application to retrieve information managed by the • Comprehensive and mature APIs. kernel. Currently, only µTKernel supports these APIs • Footprint and design concepts are suitable for small (e.g. get task register, set task register). microcontrollers. • Cyclic handler, alarm handler : cyclic handler a • These four RTOSes are ported onto the Renesas mechanism to indicate to the RTOS to execute a M16C/62P platform with the HEW IDE together function at a periodic interval while alarm handler with the NC30 toolchain [7]. An in-depth evaluation allows RTOS to execute a function after certain is made to compare the performance of these four amount of time. These APIs are currently available in RTOSes running on the same platform. µITRON and µTKernel. For each criterion, the benchmarking code is compiled, • Rendezvous : µITRON and µTKernel also support and ROM and RAM usage will be obtained from the rendezvous mechanism for synchronization and toolchain report.