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

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

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 , 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 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. By averaging the ROM information across communication between tasks. all the test criteria, the average ROM sizes can be obtained. For µC-OS/II and EmbOS, tasks are queued in a FIFO Figure 2 shows the code size and data size for the 4 RTOSes (first in first out) buffer when waiting for a semaphore, and when running the 7 benchmarks listed in the legend. Code size (ROM) Data size (RAM)

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 Bytes

interrupt Bytes

µC-OS/II µTKernel EmbOS µITRON µ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. small microcontroller of limited ROM sizes. This is due to the flexibility and comprehensiveness support As for RAM usage, µTKernel and µITRON lower in the APIs. On the other hand, µITRON and EmbOS, requirements, while µC-OS/II and EmbOS are slightly which are commercial RTOSes, offer relatively compact higher. In summary, the ROM and RAM usage of all these code sizes. Nevertheless, all these RTOSes can fit well in RTOSes are well suited for small microcontrollers.

1009 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 5.94 % 9.64 % 33.76 % 47.26 % Release semaphore 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 Task activation from interrupt minimal and typical µTKernel’s configurations. These 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 Micro-seconds

µC-OS/II µTKernel EmbOS µITRON Figure 3: Execution time benchmark for 4 RTOSes

IV. µTK ERNEL IMPLEMENTATION ON RENESAS H8S/2377 Micro-seconds 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 on H8S/2377 µTKernel on M16C/62P µTKernel is recommended with a slightly higher ROM Figure 4: Execution time comparison of µTKernel footprint. Taking into considerations all the above, and most implementation on H8S/2377 and M16C/62P. importantly the need for an open and freely available RTOS for both educational and commercial used with OS A similar performance benchmark is conducted to evaluate awareness support, the µTKernel is eventually selected. the newly ported µTKernel RTOS on the H8S/2377 µTKernel specifications [8] govern the basic design microcontroller. Figure 4 shows the results of those critical policies of µTKernel. These specifications include system parameters when compared to the µTKernel implementation calls that have to be supported, system call prototypes (C on the M16C/62P microcontroller running at 24 MHz for language), naming conventions, return values conventions, both microcontrollers. It is noted that most parameters are as well as the licenses for distribution of reference source on par except a few where the advantages are related to code and object code. The reference source code comes with microcontroller’s unique architecture. Although both implementation for ATmel AT91 microcontroller is based microcontrollers are 16-bit and running at 24 MHz, on the free GNU toolchain. To preserve the original source M16/62P has a higher performance CPU of 16 MIPS tree structure, a new version of the port for H8S/2377 is compared to H8S/2377 with only 11 MIPS. In addition, the added. following could potentially explain the performance µTKernel implementation includes both hardware- disparity between the same RTOS running on different

1010 microcontrollers. Firstly, µTKernel implementation for Figure 5 shows the screen capture of a simple application M16C/62P has two instructions for the system call interface that has been developed to showcase the deployment of the instead of five in H8S/2377. Also, the commonly used µTKernel RTOS on H8S/2377. There are 9 different tasks instruction (MOV.W) takes 4 clock cycles to execute in running concurrently to demonstrate the ease towards M16/62P but 5 cycles in H8S/2377. Moreover, M16/62P creating multi-tasking applications on a small has a wider range of addressing modes (e.g. SP relative) and microcontroller using an RTOS. Each task has been instructions (91 instructions in M16/62P compared to 65 in allocated a different task priority and numerous inter-tasks H8S/2377) which speed up execution for stack pointer communication mechanisms have been used to pass related operations. Lastly, M16/62P CPU has a 4-stage information between tasks. Details of this application can instruction queue buffer (similar to simplified pipeline) that also be found here [9]. will help to reduce the execution time.

Figure 5: Demonstration of µTKernel RTOS deployment.

simplify their selection by examining their specific

V. CONCLUSION application requirements. Lastly, the µTKernel was ported RTOS is increasingly popular for deployment with to the H8S/2377 microcontroller and the two systems microcontroller-based embedded systems design. It can compared. helps to improve the development cycles, code reusability, easy of coding as well as maintenance, better resource and REFERENCES timing management even for small microcontrollers. RTOS [1] K. Sakamura, H. Takada, “µITRON for small scale embedded can be differentiated from generic OS in terms of scheduling systems”, IEEE Micro, vol. 15, pp. 46–54, Dec. 1995. [2] J. Ganssle, “The challenges of real-time programming”, Embedded (priority-based), predictability in inter-task synchronization, System Programming magazine, vol. 11, pp. 20–26, Jul. 1997. and deterministic behaviors. In this paper, a list of RTOSes [3] CMP Media, “State of embedded market survey”, Embedded System have been evaluated based on various selection criteria Design Magazine, 2004. [4] CMP Media, “State of embedded market survey”, Embedded System targeting small microcontrollers with about 128Kbytes of Design Magazine, 2006. ROM and 4Kbytes of RAM. Subsequently, µC-OS/II, [5] A. J. Massa, “Embedded software development with ECOS?” Prentice µTKernel, EmbOS and µITRON were selected and Hall, Nov. 2002. [6] T-Engine, “T-Engine forum”, http://www.t-engine.org/, Nov. 2007. benchmarked on the same microcontroller platform. A list [7] Renesas Technology Corp., “Renesas high-performance embedded of benchmarking criteria which is aimed to be simple, easy workshop (HEW)”, http://www.renesas.com/fmwk.jsp?cnt=ide_hew to be ported to different RTOS platforms and representative _tools_product_landing.jsp&fp=/products/tools/ide/ide_hew/ , 2007. [8] D. Kalinsky, “Basic concepts of real-time operating systems”, typical RTOS usages were used. The results show that each LinuxDevices magazine, Nov. 2003. RTOS has different strengths and weaknesses without any [9] Tran Nguyen Bao Anh, A real-time operating system for 16-bit clear emerging winner. With these detailed performance microcontroller, MSc dissertation, School of Computer Engineering, Nanyang Technological University, Singapore, May 2008. benchmarks, potential adopters of these RTOSes can

1011