T2What the Second Generation HoldsPhilip Levis, David Gay, David Culler, Vlado Handziski, Jan Hauer, Cory Sharp, Ben Greenstein, Jonathan Hui, Joe Polastre, Robert Szewczyk, Kevin Klues,Gilman Tolle, Lama Nachman, Adam Wolisz, and a few more...In the Beginning(1999)Sensor networks are on the horizon...... but what are they going to do?What problems will be important?What will communication look like?What will hardware platforms look like?Having an operating system is nice...... but how do you design one with these uncertainties?The TinyOS Goals(ASPLOS 2000)Allow high concurrency Operate with limited resourcesAdapt to hardware evolutionSupport a wide range of applicationsBe robustSupport a diverse set of platformsTinyOS BasicsA program is a set of componentsComponents can be easily developed and reusedAdaptable to many application domainsComponents can be easily replaced Components can be hardware or softwareAllows boundaries to change unknown to programmerHardware has internal concurrencySoftware needs to be able to have it as wellHardware is non-blockingSoftware needs to be so as wellSoftwareCryptoEncryptThisEncryptFinishedComponentTinyOS Basics, Continued(2002)HardwareCryptoTasksEncryptThisEncryptFinishedNon-volatile StorageNon-volatile StorageInterfaceComponentThe TinyOS Goals(ASPLOS 2000)Allow high concurrency Operate with limited resourcesAdapt to hardware evolutionSupport a wide range of applicationsBe robustSupport a diverse set of platformsThe TinyOS Goals(The David Gay Scorecard, 2005)Allow high concurrency (A)Operate with limited resources (A-)Adapt to hardware evolution (B)Support a wide range of applications (B)Be robust (C)Support a diverse set of platforms (D)The T2 AgendaAllow high concurrency (A)Operate with limited resources (A-)Adapt to hardware evolution (B)Support a wide range of applications (B)Be robust (C)Support a diverse set of platforms (D)OutlineTinyOSIssues facing a second-generation OST2 core structureMulti-layer abstractionsStatic binding and allocationService distributionsThe Issues AheadSupport a wide range of applications (B)Building small applications is easyBuilding large applications is possible, but hardBe robust (C, but a D in Phil’s world)New hardware has punched holes in assumptionsMany unforeseen interactionsSupport a diverse set of platforms (D)Current trend is to have 1-2 supported platformsMore platforms leads to lots of redundant codeDiverse PlatformsProblem: many new platforms emerging, but few run TinyOSE.g., “How do I port TinyOS to my new platform with an XXX?”E.g.,“Porting TinyOS requires a lot of work!”Cause: platforms are self-contained units, with dependencies and assumptionsFuture PlatformsA platform is usually a collection of interconnected hardware chipsA next generation OS needs to separate the code for hardware resources from the code that composes them into a platform.PlatformMCURadiomica2ATMega128CC1000micaZATMega128CC2420TelosMSP430CC2420eyesMSP430InfineonRobustnessProblem: failures of structure Components written to operate independently, but manifest conflicts when combinedE.g., “The ADC hangs when I send packets!”Problem: failures of abstractionDynamic allocation leads to dynamic failuresGenerally, TinyOS follows a static allocation policy, except for one place: the task schedulerCause: TinyOS didn’t get everything right the first timeImproving RobustnessA next generation OS needs to define a structure and architecture for how components interactMechanisms and division of responsibilitiesA next generation OS needs to identify and redefine problematic abstractionsThere’s a five years of experience from thousands of usersApplication SupportProblem: building large applications out of many independent components is hardE.g., “Why is it that if I turn off the radio to save power, flash storage stops working?”E.g., “Why is it that if I put the send queue above this component it hangs?”Problem: inefficiency of defensive codeE.g., the radio stack is initialized 6 timesCause: components are independent, applications are notSupporting ApplicationsComplexities stem from hidden dependencies over shared resourcesE.g., SPI busInefficiencies stem from tension between local independence and global propertiesAll 6 use the radio, but how can the app know?A next generation OS needs to have true APIs that encapsulate underlying services in a usable wholeAn Example: CC2420Platform diversity: needs to be easily portable to new platforms (micaZ + Telos)Robustness: 1.x implementation breaks TinyOS concurrency model due to shared task queueApplications: interactions with other components are a big source of problemsThree ApproachesMulti-layer abstractionsPresent a true spectrum of abstraction layers, from the most general and portable to the most efficient and platform-specificStatic binding and allocationAnything and everything that can be determined statically, should beService distributionsA coherent collection of APIs above the OS core, which implement policies for an intended set of application domainsOutlineTinyOSIssues facing a second-generation OST2 coreMulti-layer abstractionsStatic binding and allocationService distributionsT2 CorePlatformsConcurrency modelSchedulerT2 PlatformsA platform is a collection of chipsChip implementations are platform independentPlatforms provide adapter codePlatformMCURadiomica2ATMega128CC1000micaZATMega128CC2420TelosMSP430CC2420eyesMSP430InfineonExample: CC2420CC2420RadioPCC2420FifoPCC2420PCC2420 RegistersCC2420 FIFO MemorySPI BusInterruptsAtm128SpiMasterCHplCC2420PinsCAtm128IOCCC2420 ComponentMicaZ ComponentAtmega128 ComponentTinyOS 1.x ConcurrencyTasks run to completion (do not preempt)while(1) {runNextTaskOrSleep();}Two kinds of functionSynchronous: can only run in a task (main)Asynchronous: can run in a task or interruptAsynchronous code can preemptCompile-time race condition detectionPosting is how you go from async to syncConcurrency ModelT2 has the same basic concurrency modelTasks, sync vs. asyncT2 changes the task semanticsTinyOS 1.x: post() can return FAIL, can post() multiple times (shared slots)T2: post returns FAIL iff the task is already in the queue (single reserved slot per task)TinyOS 1.x T2SchedulerCommon (but mostly disappeared) TinyOS complaint: why no task priorities?Scheduler was the one part you could not change (built into the language)Some application domains may really need themT2 solution: scheduler is a component, tasks are just another
View Full Document
Unlocking...