real time operating systems for small microcontrollers

16
.......................................................................................................................................................................................................................... REAL-TIME OPERATING SYSTEMS FOR SMALL MICROCONTROLLERS .......................................................................................................................................................................................................................... REAL-TIME OPERATING SYSTEMS HAVE GAINED POPULARITY IN MICROCONTROLLER- AND PROCESSOR-BASED EMBEDDED SYSTEM DESIGN.THIS ARTICLE DISCUSSES DIFFERENCES BETWEEN RTOSS AND GENERIC OPERATING SYSTEMS, THE ADVANTAGES AND DISADVANTAGES OF USING RTOSS FOR SMALL MICROCONTROLLER SYSTEM DEVELOPMENT, AND THE BENCHMARKING METHODS USED FOR RTOSS.BENCHMARKING RESULTS FOR FOUR RTOSS SHOW NO CLEAR WINNER, WITH EACH RTOS PERFORMING BETTER ON SOME CRITERIA THAN OTHERS. ......Real-time embedded systems serve various purposes, such as to control or process data. A real-time operating system is a piece of software with a set of APIs that developers can use to build applications. RTOSs support the need of some embedded systems to meet deadlines. However, using an RTOS doesn’t guarantee that a system will always meet the deadlines, because these systems also depend on the overall sys- tem’s design. Although RTOSs for embedded systems are predominantly used in high-end micro- processors or microcontrollers with 32-bit CPUs, there is a growing trend to provide these features in mid-range (16-bit and 8-bit) processor systems. Generic operating systems versus RTOSs Operating systems manage resource shar- ing in computer systems. Unlike generic operating systems, an RTOS is specifically designed to achieve real-time responses. RTOS differ from generic operating systems in several other ways as well. First, RTOSs offer preemptive, priority- based scheduling. A scheduling scheme refers to how the RTOS assigns CPU cycles to tasks for execution. Thus, scheduling schemes affect how the operating system will execute the various software programs. Most generic operating systems are time- sharing systems, which allocate tasks the same number of time slices for execution (for example, by round-robin scheduling). RTOSs often assign tasks priorities, and higher-priority tasks can preempt lower- priority tasks during execution (preemptive scheduling). Other RTOSs adopt coopera- tive scheduling, which usually implies that the running task must explicitly invoke the scheduler to switch between tasks. In addition, RTOSs allow predictable task synchronization. In generic operating systems, task synchronization is unpredict- able because the operating system can di- rectly or indirectly introduce delays into the application software. In an RTOS, task syn- chronization must be time-predictable. The system services must have a known and expected duration of execution time. Tran Nguyen Bao Anh Singapore Engineering Center Su-Lim Tan Nanyang Technological University .............................................................. 30 Published by the IEEE Computer Society 0272-1732/09/$26.00 c 2009 IEEE

Upload: ivan-alberto-arias-g

Post on 24-Oct-2015

85 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Real Time Operating Systems for Small Microcontrollers

..........................................................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMSFOR SMALL MICROCONTROLLERS

..........................................................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS HAVE GAINED POPULARITY IN MICROCONTROLLER- AND

PROCESSOR-BASED EMBEDDED SYSTEM DESIGN. THIS ARTICLE DISCUSSES DIFFERENCES

BETWEEN RTOSS AND GENERIC OPERATING SYSTEMS, THE ADVANTAGES AND

DISADVANTAGES OF USING RTOSS FOR SMALL MICROCONTROLLER SYSTEM DEVELOPMENT,

AND THE BENCHMARKING METHODS USED FOR RTOSS. BENCHMARKING RESULTS FOR

FOUR RTOSS SHOW NO CLEAR WINNER, WITH EACH RTOS PERFORMING BETTER ON SOME

CRITERIA THAN OTHERS.

......Real-time embedded systemsserve various purposes, such as to controlor process data. A real-time operating systemis a piece of software with a set of APIs thatdevelopers can use to build applications.RTOSs support the need of some embeddedsystems to meet deadlines. However, usingan RTOS doesn’t guarantee that a systemwill always meet the deadlines, becausethese systems also depend on the overall sys-tem’s design.

Although RTOSs for embedded systemsare predominantly used in high-end micro-processors or microcontrollers with 32-bitCPUs, there is a growing trend to providethese features in mid-range (16-bit and8-bit) processor systems.

Generic operating systems versus RTOSsOperating systems manage resource shar-

ing in computer systems. Unlike genericoperating systems, an RTOS is specificallydesigned to achieve real-time responses.RTOS differ from generic operating systemsin several other ways as well.

First, RTOSs offer preemptive, priority-based scheduling. A scheduling scheme refersto how the RTOS assigns CPU cycles totasks for execution. Thus, schedulingschemes affect how the operating systemwill execute the various software programs.Most generic operating systems are time-sharing systems, which allocate tasks thesame number of time slices for execution(for example, by round-robin scheduling).RTOSs often assign tasks priorities, andhigher-priority tasks can preempt lower-priority tasks during execution (preemptivescheduling). Other RTOSs adopt coopera-tive scheduling, which usually implies thatthe running task must explicitly invoke thescheduler to switch between tasks.

In addition, RTOSs allow predictabletask synchronization. In generic operatingsystems, task synchronization is unpredict-able because the operating system can di-rectly or indirectly introduce delays into theapplication software. In an RTOS, task syn-chronization must be time-predictable. Thesystem services must have a known andexpected duration of execution time.

Tran Nguyen

Bao Anh

Singapore Engineering

Center

Su-Lim Tan

Nanyang Technological

University

..............................................................

30 Published by the IEEE Computer Society 0272-1732/09/$26.00 �c 2009 IEEE

Page 2: Real Time Operating Systems for Small Microcontrollers

The key difference between generic oper-ating systems and RTOSs is that an RTOSsupports deterministic behaviors. In anRTOS, task dispatch time, task switch la-tency, and interrupt latency must be time-predictable and consistent even when thenumber of tasks increases. In contrast, ge-neric operating systems (mainly owing totheir time-sharing approach) reduce a sys-tem’s overall responsiveness and don’t guar-antee service call execution within a certainamount of time when the number of tasksincreases. Dynamic memory allocation(malloc() in C language), although widelysupported in generic operating systems,isn’t recommended in RTOSs because itgenerates unpredictable behavior.1 Instead,RTOSs provide fixed-size memory allocationin which they allocate only a fixed-size mem-ory block for every request.

RTOSs for small-scale embedded systemsAvailable RTOSs include commercial,

proprietary, and open source systems. Manysystem designers believe that small-scaleembedded systems designed using smallmicrocontrollers (that is, microcontrollerswith a maximum ROM of 128 Kbytes andmaximum RAM of 4 Kbytes2) don’t needan RTOS. However, RTOSs offer significantadvantages for this range of devices.2,3

For example, developers can use anRTOS to optimize software development.In system development using small micro-controllers, software productivity is a criticalissue because of time-to-market pressures aswell as a shortened development cycle (seethe Embedded System Design 2004 survey athttp://www.embedded.com/columns/survey).For projects involving complex code, anRTOS is an efficient tool to manage the soft-ware and to distribute tasks among develop-ers. Using an RTOS lets project leaderspartition the entire software into modulartasks that individual programmers can han-dle. Moreover, other developers can developthe low-level drivers.

An RTOS also provides better and safersynchronization. In small embedded systemdevelopment without an RTOS, developersoften use global variables for synchronizationand communication among modules andfunctions. However, using global variables

can lead to bugs and software safety issues,especially in highly interrupt-driven systems(see the Embedded System Design 2006 surveyat http://www.embedded.com/columns/survey). Because these global variables areoften shared and accessed among functions,they’re highly vulnerable to corruption dur-ing program execution. As the code beginsto grow, these bugs are more deeply hiddenand thus more difficult to uncover. Conse-quently, development time can lengtheneven for such small-scale systems. With anRTOS in place, tasks can safely pass messagesor synchronize with each other without cor-ruption problems.

Most RTOSs provide APIs that let devel-opers manage system resources to establishfunctions including task management, mem-ory pool management, time management,interrupt management, communication,and synchronization. RTOSs provide the ab-straction layer for developers to freely struc-ture the software, to achieve cleaner code,and even to quickly port across differenthardware platforms with few code modifica-tions. In small system development in partic-ular, hardware cost is a critical constraint anddevelopment time is usually short.

Time management functions let softwaredesigners achieve task delay, timer handling,or time-triggered processing without havingto understand the underlying hardwaremechanisms. Achieving timing-related fea-tures in a small system with no RTOS canbe tricky because the software designermust understand the underlying peripherals(such as timers), how to use them, andhow to link them with the top-level applica-tion code. Any modification, such as a longerdelay time, would require the developer tore-examine the code and peripherals tomake changes appropriately. To port thesoftware to another platform using a differ-ent microcontroller with a different set ofperipherals, the developer must rewritethese timing features. Unless the projectinvolves a critical timing issue with a uniquehardware peripheral, using an RTOS canhelp significantly speed up the developmenttime required to tackle these timing issues.

Ganssle illustrates the importance ofRTOSs in small system design using a printersystem example.3 Without an RTOS, the

....................................................................

SEPTEMBER/OCTOBER 2009 31

Page 3: Real Time Operating Systems for Small Microcontrollers

system uses a single chunk of code to manageall printer activities—paper feeding, user-input reading, and printing controls. AnRTOS lets individual tasks manage each ofthese activities. Except for passing status in-formation, each task doesn’t need to knowmuch about what other tasks are performing.Hence, having an RTOS in place can help inpartitioning the software in the time domain(for tasks to run concurrently) and in termsof functionalities (for each task to performa specific operation).

Figure 1 shows results from the 2004Embedded Systems Design embedded marketsurvey on the number of developers whohave used and would consider using anRTOS in their current and upcoming

projects. (Results from the 2004�2006 sur-veys are available at http://www.embedded.com/columns/survey.) In 2004, more than49 percent of developers said they had usedan RTOS. This percentage rose to 80.9 per-cent in the 2005 survey, and was 71 percentin the 2006 survey. The percentage of devel-opers who would consider using an RTOS inan upcoming project was 66.6 in 2004 and86 in 2005, indicating a steady trend towardusing RTOSs.

Table 1, which shows results from the2006 Embedded System Design embeddedmarket survey, suggests another trend inRTOS selection. Companies are moving to-ward open source RTOSs—from 16 percentin current projects to 19 percent in upcom-ing projects; and toward commercial distri-butions of open source RTOSs—from12 percent in current projects to 17 percentin upcoming projects. Use of commercialand in-house systems, although currently ex-tensive, is declining—from 51 percent incurrent projects to 47 percent in upcomingprojects for commercial operating systems,and from 21 to 17 percent for in-house oper-ating systems. In the 2007 survey, commer-cial operating system use drops further, to41 percent.4 The 2007 survey also showsthat the key influencing factors in RTOS se-lection for commercial operating systems arethe quality and availability of technical sup-port. If adequate technical support is unavail-able, companies might look for other, morecost-effective choices.

RTOSs also have some disadvantageswhen used for small microcontrollers. Be-cause an RTOS consumes additional mem-ory (both ROM and RAM), computationalresources, and power,5 system designersmust determine whether the system can ab-sorb these overheads. For small microcon-trollers, the RTOS must have compactROM and RAM requirements. VariousRTOSs are available for these devices, andsome are flexible enough that designers canconfigure them to have only those functionsand APIs that the application requires,2,6-8

thus allowing a smaller code size. In addi-tion, most RTOSs require a periodic timer(an operating system ‘‘tick’’)9 to execute thescheduler and other relevant system services.RTOS services such as task synchronization

Table 1. Results from the 2006 Embedded System Design

survey on the types of operating systems used

(http://www.embedded.com/columns/survey).

Type of

operating system

Current project

(%)

Upcoming project

(%)

Commercial operating

system

51 47

Internally developed or

in-house operating

system

21 17

Open source operating

system without

commercial support

16 19

Commercial distribution

of an open source

operating system

12 17

.......................................................................................................(Copyright 2009 TechInsights. Used with permission.)

Don’t know2%

No49%

(a) (b)

No21%Yes

49%Yes67%

Don’t know12%

Figure 1. RTOS usage as reported in the 2004 Embedded Systems Design

embedded market survey (http://www.embedded.com/columns/survey):

have used (a) and would consider using (b). (Copyright 2009 TechInsights.

Used with permission.)

....................................................................

32 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 4: Real Time Operating Systems for Small Microcontrollers

must have a known execution time (that is,the amount of time it takes for a taskswitch to occur). Depending on these tim-ing factors, and by making use of the rele-vant RTOS services, the system designercan decide on the API suite and structurethe whole system. Hence, designers mustunderstand the performance measurementsand benchmarking metrics among RTOSs.

RTOS benchmarkingMost RTOS benchmarking approaches

are based on applications or on the most fre-quently used system services (fine-grainedbenchmarking).10 Because applications havedifferent requirements, benchmarking againsta generic application won’t reflect anRTOS’s strengths and weaknesses. Bench-marking methods based on frequently usedsystem services include the Rhealstone bench-mark, which measures task switch time, pre-emption time, interrupt latency time,semaphore shuffling time, deadlock breakingtime, and datagram throughput time.11 How-ever, Rhealstone is unsuitable for RTOSbenchmarking for several reasons. First, fewRTOSs can break deadlock (as we discusslater). Datagram throughput time is basedon message passing, in which the RTOS cop-ies messages to a memory area managed bythe operating system. However, not allRTOSs use the same message-passingapproach. Some RTOSs only pass the mem-ory pointer, so there’s no need to use the spe-cial memory area managed by the operatingsystem. This approach is more suitable forsmall microcontrollers, which have no extramemory for operating system internal use. In-terrupt latency time in Rhealstone isn’t deter-mined by the RTOS; rather, it dependspurely on the CPU architecture. Rhealstoneis generally somewhat ad hoc and doesn’tcover other common situations in real-timeapplications.10

Garcia-Martinez et al. propose severalmetrics based on frequently used system ser-vices: response to external events (interrupt),intertask synchronization and resource shar-ing, and intertask data transfer (message pass-ing).10 Intertask data transfer is similar toRhealstone’s datagram throughput time. Inthe ‘‘response to external event (interrupt)’’test, the interrupt handler wakes another

task via a semaphore. In this case, using asemaphore doesn’t seem to be the bestapproach. Waking up the task directlyusing a system service call (such as a sleep/wakeup service call) is a better approach toreduce the overhead delay.

Other researchers have proposed tests formeasuring message transfer duration andcommunication through a pipe, the speedof task synchronization through proxy andsignal, and task-switching duration.12 Thesemetrics are based only on the RTOS plat-form distributed by QNX; some concepts,such as proxy and signal, don’t exist onmost RTOSs.

RTOS features and API comparisonWe based our RTOS comparisons on

online documentation and APIs. We exam-ined the following systems: mITRON,2,13

mTKernel,7 mC-OS/II,6 EmbOS,14 Free-RTOS,8 Salvo (http://www.pumpkininc.com), TinyOS (http://www.tinyos.net),SharcOS (http://www.sharcotech.com), eX-treme Minimal Kernel (XMK, http://www.shift-right.com/xmk/index.html), Echidna(http://www.ece.umd.edu/serts/research/echidna/index.shtml), eCOS,15 Erika,16

Hartik,17 KeilOS (http://www.keil.com/rtos), and PortOS.18

Criteria for comparing RTOSsDevelopers base their choice of an RTOS

on criteria such as language support, toolcompatibility, system service APIs, memoryfootprint (ROM and RAM usage), perfor-mance, device drivers, operating systemawareness, debugging tools, technical sup-port, source and object code distribution,licensing scheme, and vendor reputation.19

They might also consider installationand configuration, RTOS architecture,API richness, documentation and support,and tool support.20 As Figure 2 shows,the Embedded System Design 2005�2007embedded market surveys found that real-time capability is the top criteria forRTOS selection.4

We used these documents to establish alist of criteria for comparing the RTOSs,which we describe in the following sections.This article’s scope limits the number andtype of criteria we could consider. Criteria

....................................................................

SEPTEMBER/OCTOBER 2009 33

Page 5: Real Time Operating Systems for Small Microcontrollers

such as suppliers’ reputation and companyreputation are subjective; overall costdepends on the project and application; roy-alty fee is normally based on quantity, eventhough RTOS vendors might use other busi-ness models to charge their customers (suchas per application, product model, or micro-controller unit [MCU] model); and memoryfootprint might be unavailable and de-pends on the compiler settings and RTOSconfigurations.

Design objective. RTOSs can be open source,personal hobby based, or commercial. A de-signer should understand an RTOS’s his-tory and the motivation that led to itscreation. A personal hobby-based RTOSwill likely be less stable than a popularopen source or commercial RTOS.

Author. A designer should also know whooriginated the RTOS—whether it was aperson or an organization.

6159

38

50

43

27

0

10

20

30

40

50

60

70

49

43

37

43

58

36

41

45

52

40

3130

3537

30

34

14

3028

31

46

2928

32

Proce

ssor

or ha

rdwar

e com

patibilit

y

Overa

ll cos

t

Docum

entat

ion

Influ

ence

(p

erce

nt)

Networ

king ca

pabilit

y

Supplie

rs’ re

putatio

n

Royalt

y fre

e

Code s

ize/m

emor

y usa

ge

Real-ti

me cap

abilit

y

Tech

nical

suppor

t

Good so

ftwar

e too

ls

2007 (N = 325)

2006 (N = 447)

2005 (N = 441)

Figure 2. Influential factors in operating system selection according to Embedded Systems

Design embedded market surveys in 2005, 2006, and 2007 (http://www.embedded.com/

columns/survey). The total number of people surveyed is N ¼ 441. (Copyright 2009

TechInsights. Used with permission.)

....................................................................

34 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 6: Real Time Operating Systems for Small Microcontrollers

Scheduling scheme. It’s also important to in-vestigate the RTOS’s scheduling approachto determine whether it uses preemptivescheduling, cooperative scheduling, orsome other scheduling scheme.

Real-time capability and performance. Real-time capability generally describes whethera system can meet the timing deadline.Using an RTOS takes up CPU cycles; how-ever, the RTOS must not have nondeter-ministic behaviors. The amount of CPUcycles and time consumed by the RTOSfor any service call should be measurable,and of low or acceptable value to the systemdesigners. Real-time capability and perfor-mance information aren’t available forsome RTOSs. Even if this information isavailable, it might not be based on the hard-ware platform a designer is using.

Memory footprint. In addition to CPU cycles,an RTOS consumes ROM and RAM space,which could increase the ROM and RAMsizes for the entire system. A trade-off alwaysexists between the memory footprint and thefunctionalities required from the RTOS.More robust and reliable APIs typically re-quire more lines of code. However, simpleAPIs require only a minimum amount ofcode. Hence, designers should understandthe features offered by the RTOS and the cor-responding memory footprint requirement.

Language support. Another criterion to con-sider is the programming language sup-ported by the RTOS.

System call/API richness. This criterion deter-mines how comprehensive an RTOS’s APIsare compared to the other RTOSs. Wecount the total number of system calls foreach RTOS.

Operating-system-awareness debugging support.This criterion determines whether the RTOSis supported by an integrated developmentenvironment (IDE). Operating-system-awareness debugging will ease the develop-ment work because users can employ theRTOS internal information (for example,task states, system states, semaphores, andevent flags) provided by the IDE.3

License type. This criterion determines howthe RTOS is distributed: free or fee-basedand for purposes such as educational orcommercial.

Documentation. This criterion focuses onthe type of documentation available forthe RTOS (detailed APIs, simple tutorial,book, or specification).

Comparison resultsTable 2 compares the RTOSs. We iden-

tified several significant similarities andidiosyncrasies among them:

� Most RTOSs use priority-based preemp-tive scheduling. Only two—Salvo andTinyOS—use cooperative scheduling.

� Most RTOSs support C language,which is the popular choice forembedded system programming, espe-cially in small system design.21

� Only a few RTOSs have operating-system-awareness support in an IDE:mC-OS/II and EmbOS have plug-inmodules for the IAR compiler; Kei-lOS is supported by the Keil com-piler; and mITRON and mTKernelare supported by the Renesas High-Performance Embedded Workshop(HEW) compiler.

� The eCOS RTOS requires a bootloader(known as Redboot) of at least 64-Kbytes ROM.15 Redboot boots andloads programs into the RAM via auser terminal (typically over a serialport). Hence, eCOS requires muchmore ROM and RAM space.

� Some RTOSs (KeilOS, PortOS, andXMK) don’t make available details oftheir APIs (marked ‘‘N/A’’ in the ‘‘Systemcall/API richness’’ column). SharcOS isbased on mC-OS/II, so uses the sameAPIs. We therefore don’t consider theseRTOSs when comparing APIs.

Figure 3 compares the number of systemAPIs available for each RTOS. We categorizethem (with examples) according to the fol-lowing functions:

� System management: initialize operatingsystem, start/shut down operating sys-tem, lock/unlock CPU

....................................................................

SEPTEMBER/OCTOBER 2009 35

Page 7: Real Time Operating Systems for Small Microcontrollers

� Interrupt management: entry/exit func-tion, begin/end critical section

� Task management: create task, deletetask, start task, and terminate task

� Task-dependent synchronization: sleeptask, wake up task, and resume task

� Communication and synchronization:semaphore, data queue, eventflag, mailbox, mutex, and messagebuffer

� Memory management: fixed-size andvariable-size memory pool

Table 2. Basic features comparison of RTOSs for small microcontrollers.

RTOS

Design

objective

Scheduling

scheme License type Documentation

System

call/API

richness

Language

supported

Operating-

system-

awareness

support

in IDE

mITRON Commercial Priority-based

preemptive

Fee-based Open specification

and user manual

93 C Renesas IDE

mTKernel Commercial/

educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Open specification

and user manual

81 C Renesas IDE

mC-OS/II Commercial/

educational/

research

Priority-based

preemptive

Free for

educational

Book 42 C IAR

EmbOS Commercial Priority-based

preemptive

Fee-based Online document 56 C IAR

Free-

RTOS

Hobby Priority-based

preemptive

Free for educa-

tional and

commercial

Online document 27 C None

Salvo Commercial Cooperative Fee-based Online document 31 C None

TinyOS Educational/

research

Cooperative Free for educa-

tional and

commercial

Tutorials N/A nesC None

SharcOS Commercial Priority-based

preemptive

Fee-based User manual N/A C None

eXtreme

Minimal

Kernel

(XMK)

Educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Online document

(incomplete)

N/A C None

Echidna Educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Online document

(incomplete)

18 C None

eCOS Commercial/

educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Book and online

document

N/A C None

Erika Educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Online document 19 C None

Hartik Educational/

research

Priority-based

preemptive

Free for educa-

tional and

commercial

Online document 33 C None

KeilOS Commercial Priority-based

preemptive

Fee-based Online document N/A C Keil IDE

PortOS Research Priority-based

preemptive

Fee-based Online document N/A C None

....................................................................

36 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 8: Real Time Operating Systems for Small Microcontrollers

� Time management: get system operatingtime, operating system timer

� Trace API: hook the routine into certainRTOS functions such as a scheduler

Several of the RTOSs compared—mITRON, mTKernel, mC-OS/II, andEmbOS—support comprehensive APIs forthese categories. Most commercial RTOSsare well-implemented, with mITRON sup-porting all the categories except for tracefunctions. EmbOS also supports most ofthe categories, except for trace, system timemanagement, system management, and mes-sage buffer. For each category, the number ofAPIs for these four RTOSs also exceeds thosefor other RTOSs because they’ve been devel-oped and improved and have been on themarket longer.

Most open source RTOSs (such as Free-RTOS, Echidna, Erika, and Hartik) haveminimal implementation. These RTOSs aremore suitable for small system development.However, mC-OS/II stands out as havingmore available APIs. This system was origi-nally an open source RTOS for personaland educational purposes. Its stability andpopularity led to its commercialization andwide use.4 Next to mC-OS/II, mTKernelhas the most available APIs. This system sup-ports all the function categories but dataqueue. It has almost the same number ofAPIs as the commercial RTOS mITRON,because it’s backed by the T-Engine Forum(http://www.t-engine.org), led by Ken Saka-mura, the mITRON architecture designer.

For these reasons, we focus on mITRON,mTKernel, mC-OS/II, and EmbOS for oursubsequent comparison and benchmarking.

In addition to the functions mentionedin Figure 3, some RTOSs support thefollowing:

� Some system APIs support timeout. Forexample, a task can wait for a sema-phore for a maximum number of nmilliseconds. RTOSs such as mITRONand mTKernel have mechanisms that letusers specify the timeout in absolutevalues. Other RTOSs, such as mC-OS/II, FreeRTOS, Salvo, and EmbOS,only let users specify timeout values interms of clock ticks.

� Debug APIs let a user’s application re-trieve information managed by the ker-nel. Currently, only mTKernel supportsthese APIs (for example, get task regis-ter and set task register).

� A cyclic handler instructs the RTOS toexecute a function at a periodic interval,and an alarm handler lets the RTOS ex-ecute a function after a certain amountof time. These APIs are currently avail-able in mITRON and mTKernel.

� A rendezvous mechanism allows syn-chronization and communication be-tween tasks (similar to Ada language22

for real-time). Both mITRON andmTKernel support this mechanism.

For mITRON and mTKernel, several APIsprovide better controllability and flexibility.

02468

101214

Task managementEventflagMutexVariable-size memory pool

System managementTask-dependent synchronizationMailboxMessage bufferSystem time management

Interrupt managementSemaphoreData queueFixed-size memory poolTrace API

µItron µTkernel µC-OS/II

Num

ber

of s

yste

m A

PIs

FreeRTOS Salvo Echidna emBos Erika Hartik

Figure 3. Number of system APIs for various RTOSs.

....................................................................

SEPTEMBER/OCTOBER 2009 37

Page 9: Real Time Operating Systems for Small Microcontrollers

As Table 3 shows, tasks in mC-OS/II andEmbOS are queued in a first-in, first-out(FIFO) buffer when waiting for a sema-phore, and developers may not change theorder. However, in mITRON and mTKernel,developers can specify whether tasks arequeued in FIFO or priority order. This flex-ibility not only applies to semaphores, butalso to other APIs (including mailbox, mes-sage queue, memory pool, and event flag).To achieve such features in mITRON andmTKernel, developers must make trade-offsin both memory footprint and performance.

Performance and memoryfootprint benchmarking

We ran benchmarks for the four RTOSsidentified earlier: mITRON, mTKernel, mC-OS/II and EmbOS. For execution timemeasurements, we used oscilloscopes andlogic analyzers in combination with I/Oport toggling to achieve the best accuracy(in terms of microseconds).

Ports of the RTOSs on the sameM16C/62P platform

For our evaluations, we used the RenesasM16C/62P microcontroller platform, whichhas the following characteristics:

� Operating frequency of 24 MHz� 512 Kbytes of ROM� 31 Kbytes of RAM (no cache or mem-

ory management unit)� Seven-level interrupt mask� Renesas HEW version 4.03.00.001 IDE� NC30 toolchain version 5.43.00

The M16C/62P has a 16-bit complex in-struction set computer (CISC) architectureCPU with a total of 91 instructions available.Most instructions complete within two orthree clock cycles. The MCU has a four-stage instruction queue buffer, which is sim-ilar to the simplified pipeline common inlarger 32-bit processors.

To ensure that all the RTOSs operate onthe same platform with the same timer reso-lution, we used the following settings. First,we took the OS tick resolution for all theRTOSs from timer A023 of the microcon-troller. We used the NC30 compiler’s defaultsettings for compiling the workspaces.

We took the mC-OS/II original work-space and full source code from the Micriumwebsite (http://www.micrium.com/renesas/index.html). We configured timer A0 forthe operating system, and compiled the en-tire workspace again using NC30 toolchainversion 5.43.00.

We took the mTKernel original work-space and full source code from the Renesaswebsite.24 We configured timer A0 at 10 ms.

We took the EmbOS original workspaceand library files (.lib) from the Segger website(http://www.segger.com). We configuredtimer A0 for the operating system and con-figured the entire workspace (except the .libfiles) with NC30 toolchain version 5.43.00.We’re unaware of whether the .lib fileswere compiled in an older toolchainor with different optimization settings. Thismeans that the toolchain and compiler set-tings for EmbOS might differ from thosefor mC-OS/II or mTKernel.

Table 3. User-controllable parameters for RTOS semaphore creation.

Parameters mC-OS/II EmbOS mTKernel mITRON

Name/information Not supported Not supported Extended information Semaphore name

Attributes Not supported Not supported Tasks can be queued in

first-in, first-out (FIFO)

or priority order

Tasks can be queued

in FIFO or priority

order

Either the first task in the queue

or the task with fewer

requests has precedence

Initial count Initial semaphore

count

Initial semaphore

count

Initial semaphore count Initial semaphore

count

Maximum count Not supported Not supported Not supported Maximum value of

semaphore count

....................................................................

38 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 10: Real Time Operating Systems for Small Microcontrollers

We generated the mITRON workspace,library files (.lib), and timer A0 configurationfrom the Renesas configuration tool formITRON. We compiled the entire work-space (except for the .lib files) using NC30toolchain version 5.43.00. This is similar toEmbOS because the operating system is dis-tributed in the form of .lib files. Further-more, the toolchain and compiler settingsused when generating the .lib files might dif-fer from those for mC-OS/II or mTKernel.

In addition, we used the same amount ofstack memory per task for all RTOSs. Fi-nally, if a particular RTOS feature isn’tused (for example, a semaphore or messagequeue), it’s disabled by the C preprocessorfor mC-OS/II and mTKernel, or during link-ing for EmbOS. However, for mITRON, weincluded the unused features because theRTOS is provided in library format and sys-tem calls are invoked via software interrupts.

Table 4 shows the differences in the im-plementation of the RTOSs’ system servicecalls and critical sections.

Whenever mC-OS/II and EmbOS issue asystem service call, they call the function di-rectly from the user task. The advantage isthat the function is executed immediatelywith minimal overhead time; the disadvan-tage is that the service call will use the cur-rent task’s stack for execution. WhenmITRON and mTKernel issue a systemservice call, it raises a nonmaskable soft-ware interrupt (an INT instruction inM16C/62P). Hence, the current executioncontext is to switch to the kernel space(that is, a separate stack) to execute the ser-vice call. The advantage of using thisapproach is that the service call won’t usethe current task’s stack for execution; the dis-advantage is that every system service call willincur a time overhead.

Table 4 also shows different methods forimplementing a critical section. To start a

critical section, mC-OS/II disables all inter-rupts, so no external interrupt can beaccepted. This lets the critical section executesafely from start to finish without interven-tion, but it also implies that the systemwon’t accept a highly important real-time in-terrupt during this period. The mITRONand mTKernel RTOSs implement a criticalsection by raising the interrupt mask level(for M16C/62P the interrupt mask level isset to 4, but can be changed) so that a criticalinterrupt can be accepted as long as the inter-rupt handler doesn’t interfere with theRTOS internal variables. EmbOS doesn’tdisable or raise the interrupt mask level fora critical section. It allows all interrupts tocome in but uses internal variables to controlthe critical section. Thus, any interrupt canbe accepted and handled during the criticalsection; however, EmbOS requires addi-tional code to handle the critical section’sinternal variables.

Benchmarking criteriaWe aimed to make our benchmarking

criteria easy to port to different platforms.For each criterion, we collected executiontime measurement and memory footprint(ROM and RAM).

Task switch time. Task switch time is thetime it takes for the RTOS to transfer thecurrent execution context from one task toanother. Figure 4a shows the measurementmethod.

It includes two tasks, task 1 and task 2,with task 1 having higher priority. EachRTOS must first execute task 1, whichthen goes into a sleep or inactive state. Theexecution context then switches to task 2.Task 2 wakes up or activates task 1. Rightafter waking up, the execution contextswitches back to task 1 because it has higherpriority. Different RTOSs use different

Table 4. System service call implementation and critical section implementation.

Call mC-OS/II mTKernel EmbOS mITRON

Service call Direct call Using software interrupt Direct call Using software interrupt

Critical section Disable all interrupts Raise interrupt mask

level to level 4

Don’t disable any interrupt

(based on an internal

variable)

Raise interrupt mask level

to level 4

....................................................................

SEPTEMBER/OCTOBER 2009 39

Page 11: Real Time Operating Systems for Small Microcontrollers

terms to describe sleep/inactive and ready/active states (for example, mC-OS/II andEmbOS use suspend/resume, and mITRONand mTKernel use sleep/wakeup).

Table 5 shows the system calls used ineach RTOS.

Get/release semaphore time. RTOSs often usesemaphores for synchronizing primitives.25

For semaphore benchmarking, we measurethe time taken by the get and release sema-phore service calls as well as the timerequired to pass the semaphore from one

(a)

Wake up task 1

Task 1: (higher priority)

Go to sleep

(B)

Task 2:

(A)

Task switch time: time from (A) to (B)

(b)

Task 1:

(A)

Get semaphore(B)

Release semaphore

(C)

Time to get semaphore: (A) to (B)Time to release semaphore: (B) to (C)

(c)

Task 1: (higher priority)

Get semaphore (put into wait list)

(B)

Task 2:

(A)

Release semaphore

Time to pass semaphore from task 1 to task 2: (A) to (B)

(d)

Task 1:

(A)

Pass message to the queue(that is, message is copied into the queue)

(B)

Retrieve message from the same queue

(C)

Time to put message onto queue: (A) to (B)Time to retrieve message from queue: (B) to (C)

(e)

(B)

Task 1: (higher priority)

Retrieve message from queue(will be put into wait list)

Task 2:

(A)

Put message onto queue

Time to pass message from task 2 to task 1: (A) to (B)

(f)

Time to acquire memory block: (A) to (B)Time to release memory block: (B) to (C)

(g)

Task 1: (higher priority)

Go to sleep

(B)

Task 2:

Do some processing

Do some processing

Interrupt

Do some processing

(A)

Resume task 1

Time from interrupt handler resuming task 1 until task 1 is resumed: (A) to (B)

Task 1:

(A)

Acquire fixed-size block

(B)

Release fixed-size block

(C)

Figure 4. Benchmarking criteria measurements: task switch time (a), get/release semaphore time (b), semaphore-passing

time (c), pass/retrieve message time (d), message-passing time (e), acquire/release fixed-size memory time (f), and task

activation from interrupt handler time (g).

....................................................................

40 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 12: Real Time Operating Systems for Small Microcontrollers

task to another. Figure 4b shows how wemeasure the get and release semaphore time.

Here there is only one task (task 1) andone binary semaphore (initialized to 1).Task 1 gets and then releases the semaphore.Different RTOSs use different terms to de-scribe this process. Table 6 shows the APIsused by each RTOS.

Semaphore-passing time. To measure the per-formance of semaphore passing, we use thefollowing method, as Figure 4c illustrates.

This measurement involves two tasks, task1 and task 2, with task 1 having higher prior-ity, and a binary semaphore (initialized to 0).The system executes task 1, which tries to getthe semaphore. Because the semaphore’svalue is 0, task 1 enters a sleep/inactivestate, waiting for the semaphore’s release.The current execution context then switchesto task 2, which releases the semaphore. Oncereleased, the semaphore wakes task 1 and theexecution context switches to task 1.

Pass/receive message time. In addition to sem-aphores, message passing has become in-creasingly popular for synchronization.26

This measurement uses a message-passingmechanism based on memory pointer pass-ing. It doesn’t copy the message into an in-ternal RTOS area because not all RTOSs

support this approach. Figure 4d showshow we perform this measurement.

The measurement involves only onetask (task 1). The task first passes the mes-sage pointer (usually to an internal messagequeue), and then retrieves the same mes-sage pointer. Table 7 shows the APIsused in each RTOS.

Intertask message-passing time. Figure 4eshows how we measure the message-passingtime between tasks.

This measurement involves two tasks, task1 and task 2, with task 1 having higher pri-ority. Task 1 is executed first, and it triesto retrieve a message pointer from thequeue. Because no message is yet available,task 1 enters a sleep/inactive state and waitsfor a new message. The current executioncontext switches to task 2, which puts anew message into the queue. The new mes-sage wakes task 1, and the execution contextswitches to task 1. The difference betweenthis measurement and the pass/receive mes-sage time benchmark is that this methodincludes the RTOS’s overhead time to pro-cess the message queue and wake the receiv-ing task.

Fixed-size memory acquire/release time. In anRTOS, only fixed-size dynamic memory

Table 5. APIs used for the task switch time benchmark.

API mC-OS/II mTKernel EmbOS mITRON

Pass message OSTaskSuspend() tk_slp_tsk() OS_Suspend() slp_tsk()

Retrieve message OSTaskResume() tk_wup_tsk() OS_Resume() wup_tsk()

Table 6. APIs used for the get/release semaphore benchmark.

API mC-OS/II mTKernel EmbOS mITRON

Get semaphore OSSemPend() tk_wai_sem() OS_WaitCSema() wai_sem()

Release semaphore OSSemPost() tk_sig_sem() OS_SignalCSema() signal_sem()

Table 7. APIs used for the message-passing benchmark.

API mC-OS/II mTKernel EmbOS mITRON

Pass message API OSQPost() tk_snd_mbx() OS_Q_Put() snd_mbx()

Retrieve message API OSQPend() tk_rcv_mbx() OS_Q_GetPtr() rcv_mbx()

....................................................................

SEPTEMBER/OCTOBER 2009 41

Page 13: Real Time Operating Systems for Small Microcontrollers

allocation should be used. The allocationand deallocation time must be determinis-tic. Figure 4f illustrates how we measurethe time to acquire and to release a fixed-size memory block.

This measurement involves only one task.Task 1 acquires a fixed-size memory block(128 bytes) and then releases it. Table 8shows the APIs used in this process.

Task activation from within interrupt handlertime. An RTOS must deal with externalinterrupts that might be asserted at anytime. It will typically keep an interrupt han-dler’s execution as short as possible to avoidaffecting the system response. If the inter-rupt requires long processing, the handlercan activate another task to do the necessaryprocessing. The time from when the inter-rupt handler resumes the task until thetime when the task is executed is crucial tothe system’s design.

Figure 4g shows the measurement’s setup,which involves two tasks, task 1 and task 2,with task 1 having higher priority, and an ex-ternal interrupt with a proper handler. Task1 executes first. It goes to the sleep/inactivestate, and the execution context switches totask 2. Task 2 runs continuously. When anexternal interrupt occurs, the interrupt han-dler executes and resumes task 1. The execu-tion context switches over to task 1. Table 9shows the APIs used for each RTOS.

Benchmarking resultsFor each criterion, we compiled the

benchmarking code and obtained theROM and RAM usage from the toolchain

report. By averaging the ROM informationacross all test criteria, we got the averageROM size. Figure 5a shows the code sizesfor the four RTOSs when running theseven benchmarks.

As the figure shows, mTKernel has a largercode size. This is due to its APIs’ flexibilityand comprehensive support. The commercialRTOSs, mITRON and EmbOS, offer a rela-tively compact code size. Nevertheless, allfour RTOSs fit well into microcontrollersof limited ROM sizes.

Figure 5b shows the RAM informationfor the four RTOSs. Two of the systems—mTKernel and mITRON—have relativelylower RAM usage, while mC-OS/II andEmbOS have slightly higher usage. Accord-ing to each benchmark’s requirement, weset the number of tasks, stack size, andnumber of RTOS objects (for example,semaphore and event flags) to be the samefor all RTOSs. The amount of RAM differ-ences among the RTOSs range from 7 to 10bytes, which might be due to internalimplementations or to the API designapproach. In summary, the ROM andRAM usage of all these RTOSs are wellsuited for small microcontrollers. However,mITRON has the optimal usage of bothROM and RAM.

Execution timeFigure 6 shows the execution time mea-

surement for the RTOSs for the differentbenchmark criteria. Because timer interruptis the only variation in the system (for oper-ating system tick), we executed each bench-mark at least twice to ensure consistent

Table 8. APIs used for the fixed-size memory benchmark.

API mC-OS/II mTKernel EmbOS mITRON

Acquire fixed-size block API OSMemGet() tk_get_mpf() OS_MEMF_ Alloc() get_mpf()

Release fixed-size block API OSMemPut() tk_rel_mpf() OS_MEMF_ Release() rel_mpf()

Table 9. APIs for the task activation from within interrupt handler benchmark.

API mC-OS/II mTKernel EmbOS mITRON

Go to sleep API OSTaskSuspend() tk_slp_tsk() OS_Suspend() slp_tsk()

Resume from interrupt API OSTaskResume() tk_wup_tsk() OS_Resume() iwup_tsk()

....................................................................

42 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 14: Real Time Operating Systems for Small Microcontrollers

results. Nevertheless, for all benchmarks,running once is enough to yield the correctmeasurement. For the task activation fromwithin interrupt handler benchmark, the ex-ternal interrupt is an additional variation.When measuring this benchmark, the exter-nal interrupt might or might not be assertedduring the operating system’s critical section(during which the operating system disablesinterrupts). If it’s asserted during the criticalsection, the operating system’s response timewill be slightly longer. Hence, this measure-ment might not include the worst-casescenario.

As Figure 6 shows, mTKernel has the low-est task-switching time, followed bymITRON, mC-OS/II, and EmbOS. It alsoshows that the mC-OS/II semaphore acquireand release times are the fastest. The fastestintertask semaphore passing is achieved bymITRON, whereas mC-OS/II and mTKernelhave better message passing and retrievaltimes than mITRON and EmbOS. As faras fixed-size memory is concerned, mC-OS/II has the best execution time, followedby EmbOS, mITRON, and mTKernel. Fi-nally, mTKernel has the best performancetime for task activation from interrupt han-dler, followed by mC-OS/II, mITRON, andEmbOS.

As these benchmarking results show,each RTOS has its own strengths and weak-nesses. In the open source category, mC-OS/II is useful as a small and compactROM-size RTOS. However, for more com-prehensive API support, we recommendmTKernel (at the expense of a slightly higherROM footprint). On the other hand, if thedeveloper prefers a commercial RTOS, werecommend either mITRON or EmbOS,with mITRON having a slighter lowerRAM footprint.

O ur benchmarking criteria are simple,easy to port to different platforms,

and representative of typical RTOS uses.They show that each RTOS has differentstrengths and weaknesses, but there’s noclear winner. With these detailed perfor-mance benchmarks, potential adopters ofthese RTOSs can simplify their selection byexamining their specific application require-ments. One of our future plans is to

investigate the effectiveness of using RTOSfor applications development. It would alsobe interesting to evaluate the power utiliza-tion between different RTOSs and develop

12,000

10,000

Cod

e si

ze (

RO

M)

in b

ytes

0

(a)

(b)

2,000

4,000

6,000

8,000

µC-OS/II µTKernel EmbOS µITRON

Task switch timeGet and release semaphore (one task)Pass semaphore (from one to another task)Pass and retrieve message to queuePass message (from one to another task)Acquire and release fixed-size memory blockTask activation from interrupt

0

500

1,000

1,500

2,000

µC-OS/II µTKernel EmbOS µITRON

Dat

a si

ze (

RA

M)

in b

ytes

Figure 5. Benchmarking results for the four RTOSs: comparisons of code

size (a) and data size (b).

....................................................................

SEPTEMBER/OCTOBER 2009 43

Page 15: Real Time Operating Systems for Small Microcontrollers

a common advanced configuration andpower interface (ACPI) framework to en-sure efficient power usage. M I CR O

....................................................................References

1. D. Kalinsky, ‘‘Basic Concepts of Real-Time

Operating Systems,’’ Linux Devices, Nov.

2003; http://www.jmargolin.com/uavs/jm_

rpv2_npl_16.pdf.

2. K. Sakamura and H. Takada, ‘‘mITRON for

Small-Scale Embedded Systems,’’ IEEE Micro,

vol. 15, no. 6, Nov./Dec. 1995, pp. 46-54.

3. J. Ganssle, ‘‘The Challenges of Real-Time

Programming,’’ Embedded System Pro-

gramming, vol. 11, July 1997, pp. 20-26.

4. R. Nass, ‘‘Annual Study Uncovers the Em-

bedded Market,’’ Embedded Systems Design,

2 Sept. 2007; http://www.embedded.com/

design/opensource/201803499;jsessionid=

NGMOMOIGE5ZNNQE1GHOSKHWATMY

32JVN?printable=true.

5. K. Baynes et al., ‘‘The Performance and En-

ergy Consumption of Embedded Real-time

Operating Systems,’’ IEEE Trans. Com-

puters, vol. 52, no. 11, 2003, pp. 1454-1469.

6. J.J. Labrosse, MicroC/OS-II: The Real-Time

Kernel, R&D Books, 1999.

7. T-Engine Forum, ‘‘mTKernel specification,

1.00.00,’’ Mar. 2007; http://www.t-engine.org.

8. R. Barry, ‘‘A Portable, Open Source Mini

Real-Time Kernel,’’ Oct. 2007; http://www.

freertos.org.

9. K. Curtis, ‘‘Doing Embedded Multitasking with

Small Microcontrollers, Part 2,’’ Embedded

System Design, Dec. 2006; http://www.

embedded.com/columns/technicalinsights/

196701565?_requestid=242226.

10. A. Garcia-Martinez, J. F. Conde, and A. Vina,

‘‘A Comprehensive Approach in Perfor-

mance Evaluation for Modern Real-Time

Operating Systems,’’ Proc. 22nd EuroMicro

Conf., IEEE CS Press, 1996, p. 61.

11. R.P. Kar and K. Porter, ‘‘Rhealstone: A Real-

Time Benchmarking Proposal,’’ Dr. Dobb’s

J. of Software Tools, vol. 14, no. 2, Feb.

1989, pp. 14-22.

12. K.M. Sacha, ‘‘Measuring the Real-Time

Operating System Performance,’’ Proc. 7th

EuroMicro Workshop Real-Time Systems,

IEEE CS Press, 1995, pp. 34-40.

13. K. Sakamura and H. Takada,mITRON 4.0 Spec-

ifications, TRON Assoc., 2002; http://www.

ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf.

14. EmbOS Real-Time Operating System, User

& Reference Guide, Segger Microcontroller,

5

0Task switch

timeGet

semaphoreRelease

semaphorePass

semaphore(from one toanother task)

Passmessageto queue

Retrievemessage

from queue

Passmessage

(from one toanother task)

Acquirefixed-sizememory

block

Releasefixed-sizememory

block

µC-OS/II

µTKernel

EmbOS

µITRON

Taskactivation

frominterrupt

10

15

20

25

30

35

40

45

Figure 6. Execution time benchmark for four RTOSs.

....................................................................

44 IEEE MICRO

...............................................................................................................................................................................................

REAL-TIME OPERATING SYSTEMS

Page 16: Real Time Operating Systems for Small Microcontrollers

2008; http://www.segger.com/cms/admin/

uploads/productDocs/embOS_Generic.pdf.

15. A.J. Massa, Embedded Software Develop-

ment with eCos, Prentice Hall, 2002.

16. P. Gai et al., E.R.I.K.A.: Embedded Real-tIme

Kernel Architecture; ERIKA Educational User

Manual,Realtime System (RETIS) Lab, Scuola

Superiore Sant’Anna, Italy, 2004; http://erika.

sssup.it/download.shtml#Doc.

17. G.C. Buttazzo, ‘‘Hartik: A Hard Real-Time

Kernel for Programming Robot Tasks

with Explicit Time Constraints and Guaran-

teed Execution,’’ Proc. IEEE Int’l Conf.

Robotics and Automation, IEEE Press,

1993, pp. 404-409.

18. R. Chrabieh, ‘‘Operating System with Prior-

ity Functions and Priority Objects,’’ Tech-

Online, Feb. 2005; http://www.techonline.

com/learning/techpaper/193101942.

19. G. Hawley, ‘‘Selecting a Real-Time Operat-

ing System,’’ Embedded System Design,

vol. 12, no. 3, 1999, http://www.embedded.

com/1999/9903.

20. M. Timmerman and L. Perneel, ‘‘Understand-

ing RTOS Technology and Markets,’’

Dedicated Systems RTOS Evaluation proj-

ect report, 2005; http://www.dedicated-

systems.com/vpr/layout/display/pr.asp?PRID=

8972.

21. R. Bannatyne and G. Viot, ‘‘Introduction to

Microcontrollers, Part 2,’’ Northcon Conf.

Proc., IEEE Press, 1998, pp. 250-254.

22. B. Millard, D. Miller, and C. Wu, ‘‘Support

for ADA Intertask Communication in a

Message-Based Distributed Operating Sys-

tem,’’ Computers and Comm. Conf. Proc.,

IEEE Press, 1991, pp. 219-225.

23. M16c/62P Group Hardware Manual, Renesas

Technology, 2006; http://documentation.

renesas.com/eng/products/mpumcu/

rej09b0185_16c62pthm.pdf.

24. Renesas Technology, ‘‘mTKernel for M16C

Source Code and Documentation,’’ 2007;

ht tp: / /www.superh- tkernel .org/eng/

download/misc/software/M30626FJPGP_

micro_tkernel/software/index.html.

25. I. Ripoll et al., ‘‘RTOS State of the Art Anal-

ysis,’’ tech. report, Open Components for

Embedded Real-time Applications (OCERA)

project, 2002.

26. D. Kalinsky, ‘‘Asynchronous Direct Message

Passing Rapidly Gains Popularity,’’ Embedded

Control Europe, Nov. 2004, p. 32.

Tran Nguyen Bao Anh is a senior embeddedengineer at STS Wireless Sound SolutionsSingapore. His research interests includeembedded and real-time system development.Anh has an MSc in embedded systems fromNanyang Technological University.

Su-Lim Tan is an assistant professor in theSchool of Computer Engineering at NanyangTechnological University, Singapore. Hisresearch interests include embedded networksensing and smart sensors. Tan has a PhD inengineering from the University of Warwick.

Direct questions and comments aboutthis article to Su-Lim Tan at the School ofComputer Engineering, Nanyang Techno-logical University, Blk N4-02a-32, Nan-yang Avenue, Singapore 639798; [email protected].

....................................................................

SEPTEMBER/OCTOBER 2009 45