The nes C Language A Holistic Approach to

The nes. C Language: A Holistic Approach to Networked Embedded Systems 2004. 9. 3 이좌형 SNSLAB

Paper Authors and Credits v David Gay, Phil Levis, Rovert von Behren, Matt Welsh, Eric Brewer, David Culler EECS Department University of California, Berkeley Intel Research, Berkeley, CA v http: //nescc. sourceforge. net/ v http: //webs. cs. berkeley. edu v PLDI’ 03, June 9– 11, 2003, San Diego, California v Copyright 2003 ACM 1 -58113 -662 -5/03/0006

Presentation Outline v Introduction v Background v nes. C Design v Evaluation v Discussion and Future Work

Introduction to nes. C v Systems programming language for networked embedded systems. v Supports programming model v v v reactivity to the environment concurrency communication v Simplifies application development v Reduces code size v Eliminates bugs

Introduction to nes. C v Key focus of nes. C v Holistic system design v This approach yields 3 important properties: v Resources are known statically. v Applications use reusable system components. v Hardware/software boundary varies depending on application and hardware platform.

Challenges nes. C Must Address v Driven by interaction with environment. Event driven motes. v Concurrent event arrival and data processing. v v Limited resources. v Motes have limited resources. v Reliability. v Need to enable long-lived applications.

Challenges nes. C Must Address v Soft real-time requirements. v do not focus on hard real-time guarantees v met by complete control over OS and app. v radio link v unreliable v not necessary to meet hard deadline.

nes. C Contributions v Defines component model v supports event driven systems provides bidirectional interfaces v supports flexible hardware/software boundary v admits efficient implementation v

nes. C Contributions v Defines concurrency model extensive compile-time analysis v detect race-conditions at compile time v v Provides unique balance accurate program analysis v expressive power for building apps. v improves reliability v reduces code size v

nes. C In Use v Many applications already using nes. C: Tiny. OS, Tiny. DB, Maté.

Background v Wireless Sensor Network v v v v v low-power CPU limited memory radio/optical communications low cost (~10¢/unit) low-power consumption long lifetime interact with environment physical inaccessibility evolves rapidly

Tiny. OS Is Component Based v Component Based Architecture v Set of reusable components v Connects components v Software v Wrappers around hardware v Modular

Task and Event Based Concurrency v Tasks Run to completion. v Do not preempt each other. v Components use task v v v when time restriction is not strict. Components post task v the post operation returns. Task is run by scheduler. v Tasks should be short. v Prohibit heavy computation. v

Task and Event Based Concurrency v Events Run to completion v Can preempt tasks or another event v Completion of split-phase operation v Event from environment v v Tiny. OS v driven by events representing hardware interrupts

Split-Phase Operations v Tiny. OS v non-preemptive v no blocking operations v Split-phase Operation v separated op requests and completions v completion events v long-latency ops

Split-Phase Operations v Commands v requests to start operation v Events v signal completion of operation v Send a packet example one component invokes send v communication component signals send. Done when packet is sent. v

Surge: A Sensor Network Application v Simple application v periodic sampling v ad hoc routing over wireless network v Each node v chooses node with least depth to be parent. v forwards received message to parent.

nes. C Design v An Extension of C v safer (less expressive power) v helps with components v Whole Program Analysis v for safety and optimization v do not consider separate compilation

nes. C Design v A “Static Language” No dynamic memory allocation v fully known call-graph at compile time. v v Supports and Reflects Tiny. OS’s Design based around concept of component v Tiny. OS’s event-based concurrency model. v v Adresses issue of concurrent access to share data.

Component Spefication v Components provide and use interfaces v abstract the hardware/software boundary. v

Interface v Interface the only point of access to a component. v bidirectional v commands and events v Separated type definition and use v v Split-phase operations v modeled by putting commands/events in the same interface.

Component Implementation v Component cosists v module and configuration v Modules v application code implementing interfaces. v Configurations v used to wire components together v connect interfaces to interfaces provided by others.

Examples of Components

Concurrency and Atomicity v Two types of code in nes. C v Asynchronous Code (AC) v v Code reachable from at least one interrupt handler. Synchronous Code (SC) v Code that is only reachable from tasks. v Claims for potential race condition any update to shared state from AC v any update to shared state from SC that is also updated from AC v

Concurrency In nes. C v nes. C provides 2 tools: v atomic sections v tasks. v Atomicity v atomic section v implemented by disabling/enabling interrupts v just few cycles

Concurrency In nes. C v Disabling interrupts for a long time v delay interrupt handling v make systems less responsive v post tasks v specifying as “norace” v potential race condition is present v programmer knows its not an actual race condition, .

Concurrency In nes. C

Parameterized Interfaces v Runtime command event dispatch. v Interface with a parameter list v creates a separate interface for each tuple of parameter values. v Wires to a parameterized interface v specify a specific interface with a compiletime constant.

Parameterized Interfaces

Evaluation of nes. C v Component model v Concurrency model v nes. C compiler creates a single C source file v Compiled with gcc 3. 1. 1 v Atmel ATmega 103, an 8 -bite RISC microprocessor used on the Mica mote.

Component Model Evalutaion v Core Tiny. OS source v 186 components total: 121 code modules v 65 configuration modules v v Number of modules per app v v 20 -69 with an average of 35 Each module very small, averaging 144 lines of code v expressive power of nes. C components v

Component Model Evalutaion v Bidirectional interfaces v syntax for grouping related computation split-phase v asynchronous operations v v excellent for event-driven systems v 74% of the 186 components in Tiny. OS v use at least one component

Concurrency Evalutaion

Optimization Evaluation

Discussion and Future Work v Express the concepts embodied in Tiny. OS. v Focus on holistic system design v Component model v Concurrency model v Bidirectional interfaces v Atomic statements v whole-program analysis and optimizations.

Discussion and Future Work v future work v concurrency support v enhancement to language features v applications to other domains other then networked embedded systems.