real time operating systems for small microcontrollers

Click here to load reader

Post on 24-Oct-2015

63 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • ..........................................................................................................................................................................................................................

    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 doesnt guarantee that a systemwill always meet the deadlines, becausethese systems also depend on the overall sys-tems 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

  • 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-tems overall responsiveness and dont 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,isnt 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) dont 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,theyre 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

  • system uses a single chunk of code to manageall printer activitiespaper feeding, user-input reading, and printing controls. AnRTOS lets individual tasks manage each ofthese activities. Except for passing status in-formation, each task doesnt 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 20042006 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 RTOSsfrom 16 percentin current projects to 19 percent in upcom-ing projects; and toward commercial distri-butions of open source RTOSsfrom12 percent in current projects to 17 percentin upcoming projects. Use of commercialand in-house systems, although currently ex-tensive, is decliningfrom 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), computationalresou

View more