REAL-TIMEOPERATINGSYSTEMSFORSMALLMICROCONTROLLERS..........................................................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMSHAVEGAINEDPOPULARITYINMICROCONTROLLER-AND
PROCESSOR-BASEDEMBEDDEDSYSTEMDESIGN.THISARTICLEDISCUSSESDIFFERENCESBETWEENRTOSSANDGENERICOPERATINGSYSTEMS,THEADVANTAGESAND
DISADVANTAGESOFUSINGRTOSSFORSMALLMICROCONTROLLERSYSTEMDEVELOPMENT,ANDTHEBENCHMARKINGMETHODSUSEDFORRTOSS.BENCHMARKINGRESULTSFORFOURRTOSSSHOWNOCLEARWINNER,WITHEACHRTOSPERFORMINGBETTERONSOMECRITERIATHANOTHERS.
......
TranNguyenBaoAnhSingaporeEngineering
CenterSu-LimTanNanyangTechnological
University
Real-timeembeddedsystems
servevariouspurposes,suchastocontrolorprocessdata.Areal-timeoperatingsystemisapieceofsoftwarewithasetofAPIsthatdeveloperscanusetobuildapplications.RTOSssupporttheneedofsomeembeddedsystemstomeetdeadlines.However,usinganRTOSdoesn’tguaranteethatasystemwillalwaysmeetthedeadlines,becausethesesystemsalsodependontheoverallsys-tem’sdesign.
AlthoughRTOSsforembeddedsystemsarepredominantlyusedinhigh-endmicro-processorsormicrocontrollerswith32-bitCPUs,thereisagrowingtrendtoprovidethesefeaturesinmid-range(16-bitand8-bit)processorsystems.
GenericoperatingsystemsversusRTOSs
Operatingsystemsmanageresourceshar-ingincomputersystems.Unlikegenericoperatingsystems,anRTOSisspecificallydesignedtoachievereal-timeresponses.RTOSdifferfromgenericoperatingsystemsinseveralotherwaysaswell.
First,RTOSsofferpreemptive,priority-basedscheduling.AschedulingschemereferstohowtheRTOSassignsCPUcyclestotasksforexecution.Thus,schedulingschemesaffecthowtheoperatingsystemwillexecutethevarioussoftwareprograms.Mostgenericoperatingsystemsaretime-sharingsystems,whichallocatetasksthesamenumberoftimeslicesforexecution(forexample,byround-robinscheduling).RTOSsoftenassigntaskspriorities,andhigher-prioritytaskscanpreemptlower-prioritytasksduringexecution(preemptivescheduling).OtherRTOSsadoptcoopera-tivescheduling,whichusuallyimpliesthattherunningtaskmustexplicitlyinvoketheschedulertoswitchbetweentasks.
Inaddition,RTOSsallowpredictabletasksynchronization.Ingenericoperatingsystems,tasksynchronizationisunpredict-ablebecausetheoperatingsystemcandi-rectlyorindirectlyintroducedelaysintotheapplicationsoftware.InanRTOS,tasksyn-chronizationmustbetime-predictable.Thesystemservicesmusthaveaknownandexpecteddurationofexecutiontime.
..............................................................
30
PublishedbytheIEEEComputerSociety0272-1732/09/$26.00c2009IEEE
Thekeydifferencebetweengenericoper-atingsystemsandRTOSsisthatanRTOSsupportsdeterministicbehaviors.InanRTOS,taskdispatchtime,taskswitchla-tency,andinterruptlatencymustbetime-predictableandconsistentevenwhenthenumberoftasksincreases.Incontrast,ge-nericoperatingsystems(mainlyowingtotheirtime-sharingapproach)reduceasys-tem’soverallresponsivenessanddon’tguar-anteeservicecallexecutionwithinacertainamountoftimewhenthenumberoftasksincreases.Dynamicmemoryallocation(malloc()inClanguage),althoughwidelysupportedingenericoperatingsystems,isn’trecommendedinRTOSsbecauseitgeneratesunpredictablebehavior.1Instead,RTOSsprovidefixed-sizememoryallocationinwhichtheyallocateonlyafixed-sizemem-oryblockforeveryrequest.
RTOSsforsmall-scaleembeddedsystems
AvailableRTOSsincludecommercial,proprietary,andopensourcesystems.Manysystemdesignersbelievethatsmall-scaleembeddedsystemsdesignedusingsmallmicrocontrollers(thatis,microcontrollerswithamaximumROMof128KbytesandmaximumRAMof4Kbytes2)don’tneedanRTOS.However,RTOSsoffersignificantadvantagesforthisrangeofdevices.2,3Forexample,developerscanuseanRTOStooptimizesoftwaredevelopment.Insystemdevelopmentusingsmallmicro-controllers,softwareproductivityisacriticalissuebecauseoftime-to-marketpressuresaswellasashorteneddevelopmentcycle(seetheEmbeddedSystemDesign2004surveyathttp://www.embedded.com/columns/survey).Forprojectsinvolvingcomplexcode,anRTOSisanefficienttooltomanagethesoft-wareandtodistributetasksamongdevelop-ers.UsinganRTOSletsprojectleaderspartitiontheentiresoftwareintomodulartasksthatindividualprogrammerscanhan-dle.Moreover,otherdeveloperscandevelopthelow-leveldrivers.
AnRTOSalsoprovidesbetterandsafersynchronization.InsmallembeddedsystemdevelopmentwithoutanRTOS,developersoftenuseglobalvariablesforsynchronizationandcommunicationamongmodulesandfunctions.However,usingglobalvariables
canleadtobugsandsoftwaresafetyissues,especiallyinhighlyinterrupt-drivensystems(seetheEmbeddedSystemDesign2006surveyathttp://www.embedded.com/columns/survey).Becausetheseglobalvariablesareoftensharedandaccessedamongfunctions,they’rehighlyvulnerabletocorruptiondur-ingprogramexecution.Asthecodebeginstogrow,thesebugsaremoredeeplyhiddenandthusmoredifficulttouncover.Conse-quently,developmenttimecanlengthenevenforsuchsmall-scalesystems.WithanRTOSinplace,taskscansafelypassmessagesorsynchronizewitheachotherwithoutcor-ruptionproblems.
MostRTOSsprovideAPIsthatletdevel-opersmanagesystemresourcestoestablishfunctionsincludingtaskmanagement,mem-orypoolmanagement,timemanagement,interruptmanagement,communication,andsynchronization.RTOSsprovidetheab-stractionlayerfordeveloperstofreelystruc-turethesoftware,toachievecleanercode,andeventoquicklyportacrossdifferenthardwareplatformswithfewcodemodifica-tions.Insmallsystemdevelopmentinpartic-ular,hardwarecostisacriticalconstraintanddevelopmenttimeisusuallyshort.
Timemanagementfunctionsletsoftwaredesignersachievetaskdelay,timerhandling,ortime-triggeredprocessingwithouthavingtounderstandtheunderlyinghardwaremechanisms.Achievingtiming-relatedfea-turesinasmallsystemwithnoRTOScanbetrickybecausethesoftwaredesignermustunderstandtheunderlyingperipherals(suchastimers),howtousethem,andhowtolinkthemwiththetop-levelapplica-tioncode.Anymodification,suchasalongerdelaytime,wouldrequirethedevelopertore-examinethecodeandperipheralstomakechangesappropriately.Toportthesoftwaretoanotherplatformusingadiffer-entmicrocontrollerwithadifferentsetofperipherals,thedevelopermustrewritethesetimingfeatures.Unlesstheprojectinvolvesacriticaltimingissuewithauniquehardwareperipheral,usinganRTOScanhelpsignificantlyspeedupthedevelopmenttimerequiredtotacklethesetimingissues.GanssleillustratestheimportanceofRTOSsinsmallsystemdesignusingaprintersystemexample.3WithoutanRTOS,the
....................................................................
SEPTEMBER/OCTOBER2009
31
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
Don’t knowDon’t know2%12%NoNoYes21%Yes49%49%67%(a)(b)Figure1.RTOSusageasreportedinthe2004EmbeddedSystemsDesignembeddedmarketsurvey(http://www.embedded.com/columns/survey):haveused(a)andwouldconsiderusing(b).(Copyright2009TechInsights.Usedwithpermission.)
Table1.Resultsfromthe2006EmbeddedSystemDesign
surveyonthetypesofoperatingsystemsused(http://www.embedded.com/columns/survey).
Typeof
Currentproject
Upcomingproject
operatingsystem(%)(%)Commercialoperating5147systemInternallydevelopedor21
17
in-houseoperatingsystem
Opensourceoperating16
19
systemwithoutcommercialsupportCommercialdistribution12
17
ofanopensourceoperating.......................................................................................................
system
(Copyright2009TechInsights.Usedwithpermission.)
systemusesasinglechunkofcodetomanageallprinteractivities—paperfeeding,user-inputreading,andprintingcontrols.AnRTOSletsindividualtasksmanageeachoftheseactivities.Exceptforpassingstatusin-formation,eachtaskdoesn’tneedtoknowmuchaboutwhatothertasksareperforming.Hence,havinganRTOSinplacecanhelpinpartitioningthesoftwareinthetimedomain(fortaskstorunconcurrently)andintermsoffunctionalities(foreachtasktoperformaspecificoperation).
Figure1showsresultsfromthe2004EmbeddedSystemsDesignembeddedmarketsurveyonthenumberofdeveloperswhohaveusedandwouldconsiderusinganRTOSintheircurrentandupcoming
....................................................................
32
IEEEMICRO
projects.(Resultsfromthe20042006sur-veysareavailableathttp://www.embedded.com/columns/survey.)In2004,morethan49percentofdeveloperssaidtheyhadusedanRTOS.Thispercentageroseto80.9per-centinthe2005survey,andwas71percentinthe2006survey.Thepercentageofdevel-operswhowouldconsiderusinganRTOSinanupcomingprojectwas66.6in2004and86in2005,indicatingasteadytrendtowardusingRTOSs.
Table1,whichshowsresultsfromthe2006EmbeddedSystemDesignembeddedmarketsurvey,suggestsanothertrendinRTOSselection.Companiesaremovingto-wardopensourceRTOSs—from16percentincurrentprojectsto19percentinupcom-ingprojects;andtowardcommercialdistri-butionsofopensourceRTOSs—from12percentincurrentprojectsto17percentinupcomingprojects.Useofcommercialandin-housesystems,althoughcurrentlyex-tensive,isdeclining—from51percentincurrentprojectsto47percentinupcomingprojectsforcommercialoperatingsystems,andfrom21to17percentforin-houseoper-atingsystems.Inthe2007survey,commer-cialoperating4systemusedropsfurther,to41percent.The2007surveyalsoshowsthatthekeyinfluencingfactorsinRTOSse-lectionforcommercialoperatingsystemsarethequalityandavailabilityoftechnicalsup-port.Ifadequatetechnicalsupportisunavail-able,companiesmightlookforother,morecost-effectivechoices.
RTOSsalsohavesomedisadvantageswhenusedforsmallmicrocontrollers.Be-causeanRTOSconsumesadditionalmem-ory(bothROMandRAM),computationalresources,andpower,5systemdesignersmustdeterminewhetherthesystemcanab-sorbtheseoverheads.Forsmallmicrocon-trollers,theRTOSmusthavecompactROMandRAMrequirements.VariousRTOSsareavailableforthesedevices,andsomeareflexibleenoughthatdesignerscanconfigurethemtohaveonlythosefunctionsandAPIsthattheapplicationrequires,2,6-8thusallowingasmallercodesize.Inaddi-tion,mostRTOSsrequireaperiodictimer(anoperatingsystem‘‘tick’’)9toexecutetheschedulerandotherrelevantsystemservices.RTOSservicessuchastasksynchronization
musthaveaknownexecutiontime(thatis,theamountoftimeittakesforataskswitchtooccur).Dependingonthesetim-ingfactors,andbymakinguseoftherele-vantRTOSservices,thesystemdesignercandecideontheAPIsuiteandstructurethewholesystem.Hence,designersmustunderstandtheperformancemeasurementsandbenchmarkingmetricsamongRTOSs.
RTOSbenchmarking
MostRTOSbenchmarkingapproachesarebasedonapplicationsoronthemostfre-quentlyusedsystem10services(fine-grainedbenchmarking).Becauseapplicationshavedifferentrequirements,benchmarkingagainstagenericapplicationwon’treflectanRTOS’sstrengthsandweaknesses.Bench-markingmethodsbasedonfrequentlyusedsystemservicesincludetheRhealstonebench-mark,whichmeasurestaskswitchtime,pre-emptiontime,interruptlatencytime,semaphoreshufflingtime,deadlockbreakingtime,anddatagramthroughputtime.11How-ever,RhealstoneisunsuitableforRTOSbenchmarkingforseveralreasons.First,fewRTOSscanbreakdeadlock(aswediscusslater).Datagramthroughputtimeisbasedonmessagepassing,inwhichtheRTOScop-iesmessagestoamemoryareamanagedbytheoperatingsystem.However,notallRTOSsusethesamemessage-passingapproach.SomeRTOSsonlypassthemem-orypointer,sothere’snoneedtousethespe-cialmemoryareamanagedbytheoperatingsystem.Thisapproachismoresuitableforsmallmicrocontrollers,whichhavenoextramemoryforoperatingsysteminternaluse.In-terruptlatencytimeinRhealstoneisn’tdeter-minedbytheRTOS;rather,itdependspurelyontheCPUarchitecture.Rhealstoneisgenerallysomewhatadhocanddoesn’tcoverother10commonsituationsinreal-timeapplications.Garcia-Martinezetal.proposeseveralmetricsbasedonfrequentlyusedsystemser-vices:responsetoexternalevents(interrupt),intertasksynchronizationandresourceshar-ing,and10intertaskdatatransfer(messagepass-ing).IntertaskdatatransferissimilartoRhealstone’sdatagramthroughputtime.Inthe‘‘responsetoexternalevent(interrupt)’’test,theinterrupthandlerwakesanother
taskviaasemaphore.Inthiscase,usingasemaphoredoesn’tseemtobethebestapproach.Wakingupthetaskdirectlyusingasystemservicecall(suchasasleep/wakeupservicecall)isabetterapproachtoreducetheoverheaddelay.
Otherresearchershaveproposedtestsformeasuringmessagetransferdurationandcommunicationthroughapipe,thespeedoftasksynchronizationthroughproxyandsignal,andtask-switchingduration.12ThesemetricsarebasedonlyontheRTOSplat-formdistributedbyQNX;someconcepts,suchasproxyandsignal,don’texistonmostRTOSs.
RTOSfeaturesandAPIcomparison
WebasedourRTOScomparisonsononlinedocumentationandAPIs.Weexam-inedthefollowingsystems:mITRON,2,13mTKernel,7mC-OS/II,68EmbOS,14Free-RTOS,Salvo(http://www.pumpkininc.com),TinyOS(http://www.tinyos.net),SharcOS(http://www.sharcotech.com),eX-tremeMinimalKernel(XMK,http://www.shift-right.com/xmk/index.html),Echidna(http://www.ece.umd.edu/serts/research/echidna/index.shtml),eCOS,1517Erika,16Hartik,KeilOS(http://www.keil.com/rtos),andPortOS.18CriteriaforcomparingRTOSs
DevelopersbasetheirchoiceofanRTOSoncriteriasuchaslanguagesupport,toolcompatibility,systemserviceAPIs,memoryfootprint(ROMandRAMusage),perfor-mance,devicedrivers,operatingsystemawareness,debuggingtools,technicalsup-port,sourceandobjectcodedistribution,licensingscheme,andvendorreputation.19Theymightalsoconsiderinstallationandconfiguration,RTOSarchitecture,APIrichness,documentationandsupport,andtoolsupport.20AsFigure2shows,theEmbeddedSystemDesign20052007embeddedmarketsurveysfoundthatreal-timecapability4isthetopcriteriaforRTOSselection.WeusedthesedocumentstoestablishalistofcriteriaforcomparingtheRTOSs,whichwedescribeinthefollowingsections.Thisarticle’sscopelimitsthenumberandtypeofcriteriawecouldconsider.Criteria
....................................................................
SEPTEMBER/OCTOBER2009
33
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
....................................................................
34
IEEEMICRO
702007 (N = 325)612006 (N = 447)6059582005 (N = 441)5250504945434343)tn41e40c40re38373637p(35 e34cne313132u3030303029lfn272828I2014100ytytsnynetrselttiiooilooliloegiictiirbpobt abafa apt illttpuetanauystulsraar apepevmapa yclceyr arcwmetfou oo’miOnoccgsRm onreiisth e-rDkeirlmlcedao/aToowwppeezGdtiRreusahNS e droo CrossecorPFigure2.InfluentialfactorsinoperatingsystemselectionaccordingtoEmbeddedSystemsDesignembeddedmarketsurveysin2005,2006,and2007(http://www.embedded.com/columns/survey).ThetotalnumberofpeoplesurveyedisN¼441.(Copyright2009TechInsights.Usedwithpermission.)
suchassuppliers’reputationandcompanyDesignobjective.RTOSscanbeopensource,reputationaresubjective;overallcostpersonalhobbybased,orcommercial.Ade-dependsontheprojectandapplication;roy-signershouldunderstandanRTOS’shis-altyfeeisnormallybasedonquantity,eventoryandthemotivationthatledtoitsthoughRTOSvendorsmightuseotherbusi-creation.Apersonalhobby-basedRTOSnessmodelstochargetheircustomers(suchwilllikelybelessstablethanapopularasperapplication,productmodel,ormicro-opensourceorcommercialRTOS.controllerunit[MCU]model);andmemoryfootprintmightbeunavailableandde-Author.AdesignershouldalsoknowwhopendsonthecompilersettingsandRTOSoriginatedtheRTOS—whetheritwasaconfigurations.
personoranorganization.
Schedulingscheme.It’salsoimportanttoin-vestigatetheRTOS’sschedulingapproachtodeterminewhetheritusespreemptivescheduling,cooperativescheduling,orsomeotherschedulingscheme.
Real-timecapabilityandperformance.Real-timecapabilitygenerallydescribeswhetherasystemcanmeetthetimingdeadline.UsinganRTOStakesupCPUcycles;how-ever,theRTOSmustnothavenondeter-ministicbehaviors.TheamountofCPUcyclesandtimeconsumedbytheRTOSforanyservicecallshouldbemeasurable,andofloworacceptablevaluetothesystemdesigners.Real-timecapabilityandperfor-manceinformationaren’tavailableforsomeRTOSs.Evenifthisinformationisavailable,itmightnotbebasedonthehard-wareplatformadesignerisusing.Memoryfootprint.InadditiontoCPUcycles,anRTOSconsumesROMandRAMspace,whichcouldincreasetheROMandRAMsizesfortheentiresystem.Atrade-offalwaysexistsbetweenthememoryfootprintandthefunctionalitiesrequiredfromtheRTOS.MorerobustandreliableAPIstypicallyre-quiremorelinesofcode.However,simpleAPIsrequireonlyaminimumamountofcode.Hence,designersshouldunderstandthefeaturesofferedbytheRTOSandthecor-respondingmemoryfootprintrequirement.Languagesupport.Anothercriteriontocon-sideristheprogramminglanguagesup-portedbytheRTOS.
Systemcall/APIrichness.Thiscriteriondeter-mineshowcomprehensiveanRTOS’sAPIsarecomparedtotheotherRTOSs.WecountthetotalnumberofsystemcallsforeachRTOS.
Operating-system-awarenessdebuggingsupport.ThiscriteriondetermineswhethertheRTOSissupportedbyanintegrateddevelopmentenvironment(IDE).Operating-system-awarenessdebuggingwilleasethedevelop-mentworkbecauseuserscanemploytheRTOSinternalinformation(forexample,taskstates,systemstates,semaphores,andeventflags)providedbytheIDE.3Licensetype.ThiscriteriondetermineshowtheRTOSisdistributed:freeorfee-basedandforpurposessuchaseducationalorcommercial.
Documentation.ThiscriterionfocusesonthetypeofdocumentationavailablefortheRTOS(detailedAPIs,simpletutorial,book,orspecification).
Comparisonresults
Table2comparestheRTOSs.Weiden-tifiedseveralsignificantsimilaritiesandidiosyncrasiesamongthem:
MostRTOSsusepriority-basedpreemp-
tivescheduling.Onlytwo—SalvoandTinyOS—usecooperativescheduling.
MostRTOSssupportClanguage,whichisthepopularchoiceforembeddedsystemprogramming,espe-ciallyinsmallsystemdesign.21
OnlyafewRTOSshaveoperating-system-awarenesssupportinanIDE:mC-OS/IIandEmbOShaveplug-inmodulesfortheIARcompiler;Kei-lOSissupportedbytheKeilcom-piler;andmITRONandmTKernelaresupportedbytheRenesasHigh-PerformanceEmbeddedWorkshop(HEW)compiler.
TheeCOSRTOSrequiresabootloader(knownasRedboot)15ofatleast-KbytesROM.RedbootbootsandloadsprogramsintotheRAMviaauserterminal(typicallyoveraserialport).Hence,eCOSrequiresmuchmoreROMandRAMspace.
SomeRTOSs(KeilOS,PortOS,andXMK)don’tmakeavailabledetailsoftheirAPIs(marked‘‘N/A’’inthe‘‘Systemcall/APIrichness’’column).SharcOSisbasedonmC-OS/II,sousesthesameAPIs.Wethereforedon’tconsidertheseRTOSswhencomparingAPIs.
Figure3comparesthenumberofsystemAPIsavailableforeachRTOS.Wecategorizethem(withexamples)accordingtothefol-lowingfunctions:
Systemmanagement:initializeoperating
system,start/shutdownoperatingsys-tem,lock/unlockCPU
....................................................................
SEPTEMBER/OCTOBER2009
35
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
Table2.BasicfeaturescomparisonofRTOSsforsmallmicrocontrollers.
Operating-system-System
Design
RTOSmITRONmTKernel
objectiveCommercialCommercial/educational/research
mC-OS/II
Commercial/educational/research
EmbOSFree-RTOSSalvoTinyOS
CommercialEducational/research
SharcOSeXtremeMinimalKernel(XMK)Echidna
Educational/research
eCOS
Commercial/educational/research
Erika
Educational/research
Hartik
Educational/research
KeilOSPortOS
CommercialResearch
Priority-basedpreemptivePriority-basedpreemptivePriority-basedpreemptivePriority-basedpreemptive
Fee-based
Onlinedocument
N/A
C
None
Priority-basedpreemptivePriority-basedpreemptive
Freeforeduca-tionalandcommercialFreeforeduca-tionalandcommercialFreeforeduca-tionalandcommercialFreeforeduca-tionalandcommercialFee-based
Onlinedocument
N/A
C
KeilIDE
Onlinedocument
33
C
None
Onlinedocument
19
C
None
Bookandonlinedocument
N/A
C
None
Onlinedocument(incomplete)
18
C
None
CommercialEducational/research
Priority-basedpreemptivePriority-basedpreemptive
Freeforeduca-tionalandcommercial
Onlinedocument(incomplete)
N/A
C
None
CommercialHobby
Priority-basedpreemptivePriority-basedpreemptiveCooperativeCooperative
Freeforeduca-tionalandcommercialFee-basedFreeforeduca-tionalandcommercialFee-based
Usermanual
N/A
C
None
OnlinedocumentTutorials
31N/A
CnesC
NoneNone
Onlinedocument
27
C
None
Fee-based
Onlinedocument
56
C
IAR
Priority-basedpreemptiveSchedulingschemePriority-basedpreemptivePriority-basedpreemptive
Freeforeduca-tionalandcommercialFreeforeducational
Book
42
C
IAR
LicensetypeFee-based
DocumentationOpenspecificationandusermanualOpenspecificationandusermanual
81
C
RenesasIDE
call/APIrichness
93
Languagesupported
C
awarenesssupportinIDERenesasIDE
Interruptmanagement:entry/exitfunc-Communicationandsynchronization:
tion,begin/endcriticalsection
Taskmanagement:createtask,deletetask,starttask,andterminatetaskTask-dependentsynchronization:sleeptask,wakeuptask,andresumetasksemaphore,dataqueue,eventflag,mailbox,mutex,andmessagebuffer
Memorymanagement:fixed-sizeandvariable-sizememorypool
....................................................................
36
IEEEMICRO
Number of system APIs141210820µItronµTkernelµC-OS/IIFreeRTOSSalvoEchidnaemBosErikaHartikSystem managementTask-dependent synchronizationMailboxMessage bufferSystem time managementInterrupt managementSemaphoreData queueFixed-size memory poolTrace APITask managementEventflagMutexVariable-size memory poolFigure3.NumberofsystemAPIsforvariousRTOSs.
Timemanagement:getsystemoperating
time,operatingsystemtimer
TraceAPI:hooktheroutineintocertainRTOSfunctionssuchasaschedulerSeveraloftheRTOSscompared—mITRON,mTKernel,mC-OS/II,andEmbOS—supportcomprehensiveAPIsforthesecategories.MostcommercialRTOSsarewell-implemented,withmITRONsup-portingallthecategoriesexceptfortracefunctions.EmbOSalsosupportsmostofthecategories,exceptfortrace,systemtimemanagement,systemmanagement,andmes-sagebuffer.Foreachcategory,thenumberofAPIsforthesefourRTOSsalsoexceedsthoseforotherRTOSsbecausethey’vebeendevel-opedandimprovedandhavebeenonthemarketlonger.
MostopensourceRTOSs(suchasFree-RTOS,Echidna,Erika,andHartik)haveminimalimplementation.TheseRTOSsaremoresuitableforsmallsystemdevelopment.However,mC-OS/IIstandsoutashavingmoreavailableAPIs.Thissystemwasorigi-nallyanopensourceRTOSforpersonalandeducationalpurposes.Itsstabilityandpopularityledtoitscommercializationandwideuse.4NexttomC-OS/II,mTKernelhasthemostavailableAPIs.Thissystemsup-portsallthefunctioncategoriesbutdataqueue.IthasalmostthesamenumberofAPIsasthecommercialRTOSmITRON,becauseit’sbackedbytheT-EngineForum(http://www.t-engine.org),ledbyKenSaka-mura,themITRONarchitecturedesigner.
Forthesereasons,wefocusonmITRON,mTKernel,mC-OS/II,andEmbOSforoursubsequentcomparisonandbenchmarking.InadditiontothefunctionsmentionedinFigure3,someRTOSssupportthefollowing:
SomesystemAPIssupporttimeout.For
example,ataskcanwaitforasema-phoreforamaximumnumberofnmilliseconds.RTOSssuchasmITRONandmTKernelhavemechanismsthatletusersspecifythetimeoutinabsolutevalues.OtherRTOSs,suchasmC-OS/II,FreeRTOS,Salvo,andEmbOS,onlyletusersspecifytimeoutvaluesintermsofclockticks.
DebugAPIsletauser’sapplicationre-trieveinformationmanagedbytheker-nel.Currently,onlymTKernelsupportstheseAPIs(forexample,gettaskregis-terandsettaskregister).
AcyclichandlerinstructstheRTOStoexecuteafunctionataperiodicinterval,andanalarmhandlerletstheRTOSex-ecuteafunctionafteracertainamountoftime.TheseAPIsarecurrentlyavail-ableinmITRONandmTKernel.
Arendezvousmechanismallowssyn-chronizationandcommunicationbe-tweentasks(similartoAdalanguage22forreal-time).BothmITRONandmTKernelsupportthismechanism.FormITRONandmTKernel,severalAPIsprovidebettercontrollabilityandflexibility.
....................................................................
SEPTEMBER/OCTOBER2009
37
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
Table3.User-controllableparametersforRTOSsemaphorecreation.
ParametersName/informationAttributes
mC-OS/II
NotsupportedNotsupported
EmbOSNotsupportedNotsupported
mTKernel
ExtendedinformationTaskscanbequeuedinfirst-in,first-out(FIFO)orpriorityorder
Eitherthefirsttaskinthequeueorthetaskwithfewerrequestshasprecedence
mITRON
SemaphorenameTaskscanbequeuedinFIFOorpriorityorder
InitialcountMaximumcount
InitialsemaphorecountNotsupported
InitialsemaphorecountNotsupported
InitialsemaphorecountNotsupported
InitialsemaphorecountMaximumvalueofsemaphorecount
AsTable3shows,tasksinmC-OS/IIandEmbOSarequeuedinafirst-in,first-out(FIFO)bufferwhenwaitingforasema-phore,anddevelopersmaynotchangetheorder.However,inmITRONandmTKernel,developerscanspecifywhethertasksarequeuedinFIFOorpriorityorder.Thisflex-ibilitynotonlyappliestosemaphores,butalsotootherAPIs(includingmailbox,mes-sagequeue,memorypool,andeventflag).ToachievesuchfeaturesinmITRONandmTKernel,developersmustmaketrade-offsinbothmemoryfootprintandperformance.
Performanceandmemoryfootprintbenchmarking
WeranbenchmarksforthefourRTOSsidentifiedearlier:mITRON,mTKernel,mC-OS/IIandEmbOS.Forexecutiontimemeasurements,weusedoscilloscopesandlogicanalyzersincombinationwithI/Oporttogglingtoachievethebestaccuracy(intermsofmicroseconds).
PortsoftheRTOSsonthesameM16C/62Pplatform
Forourevaluations,weusedtheRenesasM16C/62Pmicrocontrollerplatform,whichhasthefollowingcharacteristics:
Operatingfrequencyof24MHz512KbytesofROM
31KbytesofRAM(nocacheormem-
orymanagementunit)Seven-levelinterruptmask
RenesasHEWversion4.03.00.001IDENC30toolchainversion5.43.00
TheM16C/62Phasa16-bitcomplexin-structionsetcomputer(CISC)architectureCPUwithatotalof91instructionsavailable.Mostinstructionscompletewithintwoorthreeclockcycles.TheMCUhasafour-stageinstructionqueuebuffer,whichissim-ilartothesimplifiedpipelinecommoninlarger32-bitprocessors.
ToensurethatalltheRTOSsoperateonthesameplatformwiththesametimerreso-lution,weusedthefollowingsettings.First,wetooktheOStickresolutionforalltheRTOSsfromtimerA023ofthemicrocon-troller.WeusedtheNC30compiler’sdefaultsettingsforcompilingtheworkspaces.
WetookthemC-OS/IIoriginalwork-spaceandfullsourcecodefromtheMicriumwebsite(http://www.micrium.com/renesas/index.html).WeconfiguredtimerA0fortheoperatingsystem,andcompiledtheen-tireworkspaceagainusingNC30toolchainversion5.43.00.
WetookthemTKerneloriginalwork-spaceandfullsourcecodefromtheRenesaswebsite.24WeconfiguredtimerA0at10ms.WetooktheEmbOSoriginalworkspaceandlibraryfiles(.lib)fromtheSeggerwebsite(http://www.segger.com).WeconfiguredtimerA0fortheoperatingsystemandcon-figuredtheentireworkspace(exceptthe.libfiles)withNC30toolchainversion5.43.00.We’reunawareofwhetherthe.libfileswerecompiledinanoldertoolchainorwithdifferentoptimizationsettings.Thismeansthatthetoolchainandcompilerset-tingsforEmbOSmightdifferfromthoseformC-OS/IIormTKernel.
....................................................................
38
IEEEMICRO
Table4.Systemservicecallimplementationandcriticalsectionimplementation.
CallServicecallCriticalsection
mC-OS/II
Directcall
Disableallinterrupts
mTKernel
UsingsoftwareinterruptRaiseinterruptmaskleveltolevel4
EmbOS
Directcall
Don’tdisableanyinterrupt(basedonaninternalmITRON
UsingsoftwareinterruptRaiseinterruptmaskleveltolevel4
WegeneratedthemITRONworkspace,libraryfiles(.lib),andtimerA0configurationfromtheRenesasconfigurationtoolformITRON.Wecompiledtheentirework-space(exceptforthe.libfiles)usingNC30toolchainversion5.43.00.ThisissimilartoEmbOSbecausetheoperatingsystemisdis-tributedintheformof.libfiles.Further-more,thetoolchainandcompilersettingsusedwhengeneratingthe.libfilesmightdif-ferfromthoseformC-OS/IIormTKernel.Inaddition,weusedthesameamountofstackmemorypertaskforallRTOSs.Fi-nally,ifaparticularRTOSfeatureisn’tused(forexample,asemaphoreormessagequeue),it’sdisabledbytheCpreprocessorformC-OS/IIandmTKernel,orduringlink-ingforEmbOS.However,formITRON,weincludedtheunusedfeaturesbecausetheRTOSisprovidedinlibraryformatandsys-temcallsareinvokedviasoftwareinterrupts.Table4showsthedifferencesintheim-plementationoftheRTOSs’systemservicecallsandcriticalsections.
WhenevermC-OS/IIandEmbOSissueasystemservicecall,theycallthefunctiondi-rectlyfromtheusertask.Theadvantageisthatthefunctionisexecutedimmediatelywithminimaloverheadtime;thedisadvan-tageisthattheservicecallwillusethecur-renttask’sstackforexecution.WhenmITRONandmTKernelissueasystemservicecall,itraisesanonmaskablesoft-wareinterrupt(anINTinstructioninM16C/62P).Hence,thecurrentexecutioncontextistoswitchtothekernelspace(thatis,aseparatestack)toexecutetheser-vicecall.Theadvantageofusingthisapproachisthattheservicecallwon’tusethecurrenttask’sstackforexecution;thedis-advantageisthateverysystemservicecallwillincuratimeoverhead.
Table4alsoshowsdifferentmethodsforimplementingacriticalsection.Tostarta
variable)
criticalsection,mC-OS/IIdisablesallinter-rupts,sonoexternalinterruptcanbeaccepted.Thisletsthecriticalsectionexecutesafelyfromstarttofinishwithoutinterven-tion,butitalsoimpliesthatthesystemwon’tacceptahighlyimportantreal-timein-terruptduringthisperiod.ThemITRONandmTKernelRTOSsimplementacriticalsectionbyraisingtheinterruptmasklevel(forM16C/62Ptheinterruptmasklevelissetto4,butcanbechanged)sothatacriticalinterruptcanbeacceptedaslongastheinter-rupthandlerdoesn’tinterferewiththeRTOSinternalvariables.EmbOSdoesn’tdisableorraisetheinterruptmasklevelforacriticalsection.Itallowsallinterruptstocomeinbutusesinternalvariablestocontrolthecriticalsection.Thus,anyinterruptcanbeacceptedandhandledduringthecriticalsection;however,EmbOSrequiresaddi-tionalcodetohandlethecriticalsection’sinternalvariables.
Benchmarkingcriteria
Weaimedtomakeourbenchmarkingcriteriaeasytoporttodifferentplatforms.Foreachcriterion,wecollectedexecutiontimemeasurementandmemoryfootprint(ROMandRAM).
Taskswitchtime.TaskswitchtimeisthetimeittakesfortheRTOStotransferthecurrentexecutioncontextfromonetasktoanother.Figure4ashowsthemeasurementmethod.
Itincludestwotasks,task1andtask2,withtask1havinghigherpriority.EachRTOSmustfirstexecutetask1,whichthengoesintoasleeporinactivestate.Theexecutioncontextthenswitchestotask2.Task2wakesuporactivatestask1.Rightafterwakingup,theexecutioncontextswitchesbacktotask1becauseithashigherpriority.DifferentRTOSsusedifferent
....................................................................
SEPTEMBER/OCTOBER2009
39
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
Task 1:(A)Get semaphore(B)Release semaphore(C)Time to get semaphore: (A) to (B)Time to release semaphore: (B) to (C)Task 1: (higher priority)Go to sleep(B)Task 2:(A)Wake up task 1Task switch time: time from (A) to (B)(a)(b)Task 1:(A)Pass message to the queue(that is, message is copied into the queue)Task 1: (higher priority)Get semaphore (put into wait list)(B)Task 2:(A)Release semaphore(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)Time to pass semaphore from task 1 to task 2: (A) to (B) (c)(d)Task 1:(A)Acquire fixed-size block(B)Release fixed-size block(C)Time to acquire memory block: (A) to (B)Time to release memory block: (B) to (C)Task 1: (higher priority)Retrieve message from queue(will be put into wait list)(B)Task 2:(A)Put message onto queueTime to pass message from task 2 to task 1: (A) to (B)(e)Task 1: (higher priority)Go to sleep(B)Task 2:Do some processing…Do some processing(f)InterruptDo some processing(A)Resume task 1Time from interrupt handler resuming task 1 until task 1 is resumed: (A) to (B)(g)Figure4.Benchmarkingcriteriameasurements:taskswitchtime(a),get/releasesemaphoretime(b),semaphore-passingtime(c),pass/retrievemessagetime(d),message-passingtime(e),acquire/releasefixed-sizememorytime(f),andtaskactivationfrominterrupthandlertime(g).
termstodescribesleep/inactiveandready/activestates(forexample,mC-OS/IIandEmbOSusesuspend/resume,andmITRONandmTKernelusesleep/wakeup).
Table5showsthesystemcallsusedineachRTOS.Get/releasesemaphoretime.RTOSsoftenusesemaphoresforsynchronizingprimitives.25Forsemaphorebenchmarking,wemeasurethetimetakenbythegetandreleasesema-phoreservicecallsaswellasthetimerequiredtopassthesemaphorefromone
....................................................................
40
IEEEMICRO
Table5.APIsusedforthetaskswitchtimebenchmark.
API
PassmessageRetrievemessage
mC-OS/II
OSTaskSuspend()OSTaskResume()
mTKernel
tk_slp_tsk()tk_wup_tsk()
EmbOSOS_Suspend()OS_Resume()
mITRON
slp_tsk()wup_tsk()
Table6.APIsusedfortheget/releasesemaphorebenchmark.
API
Getsemaphore
mC-OS/IImTKernel
EmbOS
mITRON
wai_sem()
OSSemPend()tk_wai_sem()OS_WaitCSema()
ReleasesemaphoreOSSemPost()tk_sig_sem()OS_SignalCSema()signal_sem()
Table7.APIsusedforthemessage-passingbenchmark.
API
PassmessageAPIRetrievemessageAPI
mC-OS/II
OSQPost()OSQPend()
mTKernel
tk_snd_mbx()tk_rcv_mbx()
EmbOSOS_Q_Put()OS_Q_GetPtr()
mITRON
snd_mbx()rcv_mbx()
tasktoanother.Figure4bshowshowwemeasurethegetandreleasesemaphoretime.Herethereisonlyonetask(task1)andonebinarysemaphore(initializedto1).Task1getsandthenreleasesthesemaphore.DifferentRTOSsusedifferenttermstode-scribethisprocess.Table6showstheAPIsusedbyeachRTOS.
Semaphore-passingtime.Tomeasuretheper-formanceofsemaphorepassing,weusethefollowingmethod,asFigure4cillustrates.Thismeasurementinvolvestwotasks,task1andtask2,withtask1havinghigherprior-ity,andabinarysemaphore(initializedto0).Thesystemexecutestask1,whichtriestogetthesemaphore.Becausethesemaphore’svalueis0,task1entersasleep/inactivestate,waitingforthesemaphore’srelease.Thecurrentexecutioncontextthenswitchestotask2,whichreleasesthesemaphore.Oncereleased,thesemaphorewakestask1andtheexecutioncontextswitchestotask1.Pass/receivemessagetime.Inadditiontosem-aphores,messagepassinghasbecomein-creasinglypopularforsynchronization.26Thismeasurementusesamessage-passingmechanismbasedonmemorypointerpass-ing.Itdoesn’tcopythemessageintoanin-ternalRTOSareabecausenotallRTOSs
supportthisapproach.Figure4dshowshowweperformthismeasurement.
Themeasurementinvolvesonlyonetask(task1).Thetaskfirstpassesthemes-sagepointer(usuallytoaninternalmessagequeue),andthenretrievesthesamemes-sagepointer.Table7showstheAPIsusedineachRTOS.
Intertaskmessage-passingtime.Figure4eshowshowwemeasurethemessage-passingtimebetweentasks.
Thismeasurementinvolvestwotasks,task1andtask2,withtask1havinghigherpri-ority.Task1isexecutedfirst,andittriestoretrieveamessagepointerfromthequeue.Becausenomessageisyetavailable,task1entersasleep/inactivestateandwaitsforanewmessage.Thecurrentexecutioncontextswitchestotask2,whichputsanewmessageintothequeue.Thenewmes-sagewakestask1,andtheexecutioncontextswitchestotask1.Thedifferencebetweenthismeasurementandthepass/receivemes-sagetimebenchmarkisthatthismethodincludestheRTOS’soverheadtimetopro-cessthemessagequeueandwakethereceiv-ingtask.
Fixed-sizememoryacquire/releasetime.InanRTOS,onlyfixed-sizedynamicmemory
....................................................................
SEPTEMBER/OCTOBER2009
41
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
Table8.APIsusedforthefixed-sizememorybenchmark.
API
Acquirefixed-sizeblockAPIReleasefixed-sizeblockAPI
mC-OS/II
OSMemGet()OSMemPut()
mTKernel
tk_get_mpf()tk_rel_mpf()
EmbOSOS_MEMF_Alloc()OS_MEMF_Release()
mITRON
get_mpf()rel_mpf()
Table9.APIsforthetaskactivationfromwithininterrupthandlerbenchmark.
API
GotosleepAPI
ResumefrominterruptAPI
mC-OS/II
OSTaskSuspend()OSTaskResume()
mTKernel
tk_slp_tsk()tk_wup_tsk()
EmbOSOS_Suspend()OS_Resume()
mITRON
slp_tsk()iwup_tsk()
allocationshouldbeused.Theallocationanddeallocationtimemustbedeterminis-tic.Figure4fillustrateshowwemeasurethetimetoacquireandtoreleaseafixed-sizememoryblock.
Thismeasurementinvolvesonlyonetask.Task1acquiresafixed-sizememoryblock(128bytes)andthenreleasesit.Table8showstheAPIsusedinthisprocess.Taskactivationfromwithininterrupthandlertime.AnRTOSmustdealwithexternalinterruptsthatmightbeassertedatanytime.Itwilltypicallykeepaninterrupthan-dler’sexecutionasshortaspossibletoavoidaffectingthesystemresponse.Iftheinter-ruptrequireslongprocessing,thehandlercanactivateanothertasktodothenecessaryprocessing.Thetimefromwhentheinter-rupthandlerresumesthetaskuntilthetimewhenthetaskisexecutediscrucialtothesystem’sdesign.
Figure4gshowsthemeasurement’ssetup,whichinvolvestwotasks,task1andtask2,withtask1havinghigherpriority,andanex-ternalinterruptwithaproperhandler.Task1executesfirst.Itgoestothesleep/inactivestate,andtheexecutioncontextswitchestotask2.Task2runscontinuously.Whenanexternalinterruptoccurs,theinterrupthan-dlerexecutesandresumestask1.Theexecu-tioncontextswitchesovertotask1.Table9showstheAPIsusedforeachRTOS.
report.ByaveragingtheROMinformationacrossalltestcriteria,wegottheaverageROMsize.Figure5ashowsthecodesizesforthefourRTOSswhenrunningthesevenbenchmarks.
Asthefigureshows,mTKernelhasalargercodesize.ThisisduetoitsAPIs’flexibilityandcomprehensivesupport.ThecommercialRTOSs,mITRONandEmbOS,offerarela-tivelycompactcodesize.Nevertheless,allfourRTOSsfitwellintomicrocontrollersoflimitedROMsizes.
Figure5bshowstheRAMinformationforthefourRTOSs.Twoofthesystems—mTKernelandmITRON—haverelativelylowerRAMusage,whilemC-OS/IIandEmbOShaveslightlyhigherusage.Accord-ingtoeachbenchmark’srequirement,wesetthenumberoftasks,stacksize,andnumberofRTOSobjects(forexample,semaphoreandeventflags)tobethesameforallRTOSs.TheamountofRAMdiffer-encesamongtheRTOSsrangefrom7to10bytes,whichmightbeduetointernalimplementationsortotheAPIdesignapproach.Insummary,theROMandRAMusageofalltheseRTOSsarewellsuitedforsmallmicrocontrollers.However,mITRONhastheoptimalusageofbothROMandRAM.
Executiontime
Figure6showstheexecutiontimemea-surementfortheRTOSsforthedifferentbenchmarkcriteria.Becausetimerinterruptistheonlyvariationinthesystem(foroper-atingsystemtick),weexecutedeachbench-markatleasttwicetoensureconsistent
Benchmarkingresults
Foreachcriterion,wecompiledthebenchmarkingcodeandobtainedtheROMandRAMusagefromthetoolchain
....................................................................
42
IEEEMICRO
results.Nevertheless,forallbenchmarks,runningonceisenoughtoyieldthecorrectmeasurement.Forthetaskactivationfromwithininterrupthandlerbenchmark,theex-ternalinterruptisanadditionalvariation.Whenmeasuringthisbenchmark,theexter-nalinterruptmightormightnotbeassertedduringtheoperatingsystem’scriticalsection(duringwhichtheoperatingsystemdisablesinterrupts).Ifit’sassertedduringthecriticalsection,theoperatingsystem’sresponsetimewillbeslightlylonger.Hence,thismeasure-mentmightnotincludetheworst-casescenario.
AsFigure6shows,mTKernelhasthelow-esttask-switchingtime,followedbymITRON,mC-OS/II,andEmbOS.ItalsoshowsthatthemC-OS/IIsemaphoreacquireandreleasetimesarethefastest.ThefastestintertasksemaphorepassingisachievedbymITRON,whereasmC-OS/IIandmTKernelhavebettermessagepassingandretrievaltimesthanmITRONandEmbOS.Asfarasfixed-sizememoryisconcerned,mC-OS/IIhasthebestexecutiontime,followedbyEmbOS,mITRON,andmTKernel.Fi-nally,mTKernelhasthebestperformancetimefortaskactivationfrominterrupthan-dler,followedbymC-OS/II,mITRON,andEmbOS.
Asthesebenchmarkingresultsshow,eachRTOShasitsownstrengthsandweak-nesses.Intheopensourcecategory,mC-OS/IIisusefulasasmallandcompactROM-sizeRTOS.However,formorecom-prehensiveAPIsupport,werecommendmTKernel(attheexpenseofaslightlyhigherROMfootprint).Ontheotherhand,ifthedeveloperprefersacommercialRTOS,werecommendeithermITRONorEmbOS,withmITRONhavingaslighterlowerRAMfootprint.
O
urbenchmarkingcriteriaaresimple,easytoporttodifferentplatforms,andrepresentativeoftypicalRTOSuses.TheyshowthateachRTOShasdifferentstrengthsandweaknesses,butthere’snoclearwinner.Withthesedetailedperfor-mancebenchmarks,potentialadoptersoftheseRTOSscansimplifytheirselectionbyexaminingtheirspecificapplicationrequire-ments.Oneofourfutureplansisto
12,000set10,000yb ni )M8,000OR( ez6,000is edoC4,0002,0000µC-OS/IIµTKernelEmbOSµITRON(a)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 interrupt2,000setyb n1,500i )MAR( ezis 1,000ataD5000µC-OS/IIµTKernelEmbOSµITRON(b)Figure5.BenchmarkingresultsforthefourRTOSs:comparisonsofcodesize(a)anddatasize(b).
investigatetheeffectivenessofusingRTOSforapplicationsdevelopment.Itwouldalsobeinterestingtoevaluatethepowerutiliza-tionbetweendifferentRTOSsanddevelop
....................................................................
SEPTEMBER/OCTOBER2009
43
...............................................................................................................................................................................................
REAL-TIMEOPERATINGSYSTEMS
4540353025µC-OS/II20151050µTKernelEmbOSµITRONTask switchGetReleasePassPasstimesemaphoresemaphoresemaphoremessage(from one toto queueanother task)RetrievePassAcquiremessagemessagefixed-sizefrom queue(from one tomemoryanother task)blockReleasefixed-sizememoryblockTaskactivationfrominterruptFigure6.ExecutiontimebenchmarkforfourRTOSs.
acommonadvancedconfigurationandpowerinterface(ACPI)frameworktoen-sureefficientpowerusage.MICRO
7.T-EngineForum,‘‘mTKernelspecification,
1.00.00,’’Mar.2007;http://www.t-engine.org.8.R.Barry,‘‘APortable,OpenSourceMiniReal-TimeKernel,’’Oct.2007;http://www.freertos.org.
9.K.Curtis,‘‘DoingEmbeddedMultitaskingwithSmallMicrocontrollers,Part2,’’EmbeddedSystemDesign,Dec.2006;http://www.embedded.com/columns/technicalinsights/196701565?_requestid=242226.
10.A.Garcia-Martinez,J.F.Conde,andA.Vina,
‘‘AComprehensiveApproachinPerfor-manceEvaluationforModernReal-TimeOperatingSystems,’’Proc.22ndEuroMicroConf.,IEEECSPress,1996,p.61.11.R.P.KarandK.Porter,‘‘Rhealstone:AReal-TimeBenchmarkingProposal,’’Dr.Dobb’sJ.ofSoftwareTools,vol.14,no.2,Feb.19,pp.14-22.
12.K.M.Sacha,‘‘MeasuringtheReal-Time
OperatingSystemPerformance,’’Proc.7thEuroMicroWorkshopReal-TimeSystems,IEEECSPress,1995,pp.34-40.
13.K.SakamuraandH.Takada,mITRON4.0Spec-ifications,TRONAssoc.,2002;http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf.14.EmbOSReal-TimeOperatingSystem,User
&ReferenceGuide,SeggerMicrocontroller,
....................................................................
References
1.D.Kalinsky,‘‘BasicConceptsofReal-TimeOperatingSystems,’’LinuxDevices,Nov.2003;http://www.jmargolin.com/uavs/jm_rpv2_npl_16.pdf.
2.K.SakamuraandH.Takada,‘‘mITRONforSmall-ScaleEmbeddedSystems,’’IEEEMicro,vol.15,no.6,Nov./Dec.1995,pp.46-54.3.J.Ganssle,‘‘TheChallengesofReal-TimeProgramming,’’EmbeddedSystemPro-gramming,vol.11,July1997,pp.20-26.4.R.Nass,‘‘AnnualStudyUncoverstheEm-beddedMarket,’’EmbeddedSystemsDesign,2Sept.2007;http://www.embedded.com/design/opensource/201803499;jsessionid=NGMOMOIGE5ZNNQE1GHOSKHWATMY32JVN?printable=true.
5.K.Baynesetal.,‘‘ThePerformanceandEn-ergyConsumptionofEmbeddedReal-timeOperatingSystems,’’IEEETrans.Com-puters,vol.52,no.11,2003,pp.1454-1469.6.J.J.Labrosse,MicroC/OS-II:TheReal-TimeKernel,R&DBooks,1999.
....................................................................
44
IEEEMICRO
2008;http://www.segger.com/cms/admin/uploads/productDocs/embOS_Generic.pdf.15.A.J.Massa,EmbeddedSoftwareDevelop-mentwitheCos,PrenticeHall,2002.16.P.Gaietal.,E.R.I.K.A.:EmbeddedReal-tIme
KernelArchitecture;ERIKAEducationalUserManual,RealtimeSystem(RETIS)Lab,ScuolaSuperioreSant’Anna,Italy,2004;http://erika.sssup.it/download.shtml#Doc.
17.G.C.Buttazzo,‘‘Hartik:AHardReal-Time
KernelforProgrammingRobotTaskswithExplicitTimeConstraintsandGuaran-teedExecution,’’Proc.IEEEInt’lConf.RoboticsandAutomation,IEEEPress,1993,pp.404-409.
18.R.Chrabieh,‘‘OperatingSystemwithPrior-ityFunctionsandPriorityObjects,’’Tech-Online,Feb.2005;http://www.techonline.com/learning/techpaper/193101942.19.G.Hawley,‘‘SelectingaReal-TimeOperat-ingSystem,’’EmbeddedSystemDesign,vol.12,no.3,1999,http://www.embedded.com/1999/9903.
20.M.TimmermanandL.Perneel,‘‘Understand-ingRTOSTechnologyandMarkets,’’
DedicatedSystemsRTOSEvaluationproj-ectreport,2005;http://www.dedicated-systems.com/vpr/layout/display/pr.asp?PRID=72.
21.R.BannatyneandG.Viot,‘‘Introductionto
Microcontrollers,Part2,’’NorthconConf.Proc.,IEEEPress,1998,pp.250-254.
22.B.Millard,D.Miller,andC.Wu,‘‘Support
forADAIntertaskCommunicationinaMessage-BasedDistributedOperatingSys-tem,’’ComputersandComm.Conf.Proc.,IEEEPress,1991,pp.219-225.
23.M16c/62PGroupHardwareManual,Renesas
Technology,2006;http://documentation.renesas.com/eng/products/mpumcu/rej09b0185_16c62pthm.pdf.
24.RenesasTechnology,‘‘mTKernelforM16C
SourceCodeandDocumentation,’’2007;http://www.superh-tkernel.org/eng/download/misc/software/M30626FJPGP_micro_tkernel/software/index.html.25.I.Ripolletal.,‘‘RTOSStateoftheArtAnal-ysis,’’tech.report,OpenComponentsforEmbeddedReal-timeApplications(OCERA)project,2002.
26.D.Kalinsky,‘‘AsynchronousDirectMessage
PassingRapidlyGainsPopularity,’’EmbeddedControlEurope,Nov.2004,p.32.
TranNguyenBaoAnhisaseniorembeddedengineeratSTSWirelessSoundSolutionsSingapore.Hisresearchinterestsincludeembeddedandreal-timesystemdevelopment.AnhhasanMScinembeddedsystemsfromNanyangTechnologicalUniversity.Su-LimTanisanassistantprofessorintheSchoolofComputerEngineeringatNanyangTechnologicalUniversity,Singapore.Hisresearchinterestsincludeembeddednetworksensingandsmartsensors.TanhasaPhDinengineeringfromtheUniversityofWarwick.DirectquestionsandcommentsaboutthisarticletoSu-LimTanattheSchoolofComputerEngineering,NanyangTechno-logicalUniversity,BlkN4-02a-32,Nan-yangAvenue,Singapore639798;assltan@ntu.edu.sg.
....................................................................
SEPTEMBER/OCTOBER2009
45
因篇幅问题不能全部显示，请点此查看更多更全内容