nes C A Programming Language for Motes David

nes. C: A Programming Language for Motes David Gay, Phil Levis, Eric Brewer, Rob von Behren, Nikita Borisov, Mike Chen, David Culler Intel Research, UC Berkeley

The State of the Motes n Tiny. OS programs hard to write n No compiler: n n n verbose, unwieldy syntax many compile-time checks missing No support for common idioms: n n n state-machine-like programs split-phase operations atomicity guarantees, etc

A Long-term Solution n We are working on an improved language n n Component-based Better support for common idioms n n n split-phase ops, state-machines, etc Clean atomicity model Very much in the design/investigation stage

A Short-term Solution: nes. C n n A cleaned up language for Tiny. OS Goals: n n Easier to use Allow whole-program optimisations Base for language experimentation Pronounced “nestlé”

nes. C: Easier to Use n n Nicer syntax Check errors n n Missing connections Type errors in connections Cycles, incorrect directions Interfaces: n Group related functionality (caller, callee): n send. Msg: n n n users: call send(m), implement send. Done(m) implementer: implement send(m), call send. Done(m) Concise wiring

The Old Model comp 3 n Components n comp 1: C code n n n specification: accepts commands n uses commands n signals events n handles events application: n comp 2: . desc comp 4 . comp: specification. C: behaviour. desc: select and wire . desc

The Old Model, continued n 4 kinds of components: n . desc only (ex: cnt_to_leds): n n . C and. comp (ex: CLOCK): n n a component implemented in C . desc and. comp (ex: GENERIC_COMM): n n top-level components and wiring for an application a component implemented by connecting other components . C, . comp and. desc (ex: INT_TO_RFM): n a component implemented in C with predefined wiring to other components

The nes. C Model comp 3 n Components: 1 file n comp 1: module n specification implementation n specification n comp 2: configuration comp 4 module: C behaviour configuration: select and wire n provides interface requires interface application: configuration

The nes. C Model, continued n 2 kinds of components n n n module: was. C and. comp configuration: was. desc and. comp What happened to the other 2 kinds of components ? n . desc only (ex: cnt_to_leds): n n use a configuration with empty specification { } . C, . comp and. desc (ex: INT_TO_RFM): n n n use a configuration and module (2 files) naming convention: Int. To. Rfm (configuration), Int. To. Rfm. M (module) allows module to be re-used with different wiring

Interfaces n Group related functionality, e. g. : n n n split-phase operation (send, send. Done) standard control interface: init, power Specifies bi-directional calls (defines, uses): interface Send. Msg { defines command result_t send(uint 16_t to, TOS_Msg. Ptr msg); uses event result_t send. Done(TOS_Msg. Ptr msg, result_t ok); } n if component C with interface I has function f: n n if I is required and f is uses, C must define f if I is provided and f is defines, C must define f

Some Interfaces interface Leds { defines { command result_t. . . } } init(); red. On(); red. Off(); red. Toggle(); interface Std. Control { defines { command result_t init(); command result_t power(char mode); } } interface Clock { defines command result_t set. Rate(char interval, char scale); uses event result_t fire(); }

Some More Interfaces interface Receive. Msg { uses event TOS_Msg. Ptr receive(TOS_Msg. Ptr m); } interface Send. Msg { defines command result_t send(uint 16_t to, TOS_Msg. Ptr msg); uses event result_t send. Done(TOS_Msg. Ptr msg, result_t ok); } interface ADC { defines command result_t get. Data(); defines command result_t get. Continuous. Data(); uses event result_t data. Ready(uint 16_t data); } n n But where did the Active Message type go ? But where did the ADC port go ?

Parameterised Interfaces n Specify a numeric parameter for an interface in a component: n n argument value specified in configurations dynamic dispatch (receive, send. Done), implicit argument (send) Like the current scheme for receiving active messages Used also for ADC ports, exclusive EEPROM access interface Receive { uses event receive(Msg. Ptr m); } interface Send { defines command send(Msg. Ptr m); uses event send. Done(Msg. Ptr m); } configuration Generic. Comm { provides interface Send[char id]; provides interface Receive[char id]; } implementation {. . . } configuration My. App. . . implementation { uses My. Main, Generic. Comm; My. Main. Msg 1 -> Generic. Comm. Send[12]; My. Main. Msg 2 -> Generic. Comm. Receive[99]; } module My. Main { requires interface Send Msg 1; requires interface Receive Msg 2; } implementation { event Msg 2. receive(Msg. Ptr m) { call Msg 1. send(my. Msg); } }

Miscellaneous Features n default events and commands (cf: _NULL_FUNC) n n some commands, events not always connected specify default behaviour in the absence of connection, e. g. : default event TOS_Msg. Ptr receive(TOS_Msg. Ptr msg) { return msg; } n includes is used to include C types/constants/etc for use in an interface or component n n n these types are accessible to all components that use the interface or component use, e. g. , to share packet format specification across components nes. C source code is not preprocessed

Implementation n nesc 1 takes a “closed” component (no interfaces) and: n Checks nes. C errors n n Unknown/multiply-defined interfaces, components, etc Connections (missing, cyclical, type-incorrect, wrong direction) Checks (most) C errors Generates one C-file for the application n n Includes only reachable code (prunes out unreachable functions) Generated in reverse-topological-call-order n n Allows gcc’s inliner to do a much better inlining job avr-gcc compiles nesc 1 output n Generated code has #line directives, so clean error messages

Status n n Compiler complete (some bugs expected) Basic infrastructure and components for Mica n n n (old) radio stack ADC, Clock, Leds, EEPROM, serial port Apps ported: n n n Blink, Cnt. To{Leds, Rfm, Leds. And. Rfm}, Rfm. To. Leds Sense. To. Leds, Chirp, Oscilloscope, EEPROMTest Generic. Base

Status: Code Size Application Blink Cnt. To. Leds Sense. To. Leds Oscilloscope Rfm. To. Leds Generic. Base Cnt. To. Rfm Cnt. To. Leds. And. Rf m Chirp C (Tiny. OS) 1092 1170 nes. C Savings 796 972 27% 1636 2792 5226 4544 5220 5544 1086 2230 4168 4632 4678 4850 34% 20% -2% 10% 13% 5516 4948 10%

Plans n Goal: Switch all Tiny. OS C code to nes. C n Stage 1: convert all “standard” components & apps n n n n Who: The Tiny. OS team Support: Mica, Rene 2, all sensor boards Stage 1 a: Phil Levis will “port” TOSSIM to nes. C Stage 1 b: Eric Brewer will write porting guide, nes. C tutorial Stage 2: distribute nes. C in next Tiny. OS release Stage 3: discontinue support for macros/perl scripts Goal: Improve nes. C n See Eric’s talk

Open Issues n n Naming Convention (Java-inspired) Interface design Revisit some component designs Directory structure

Conclusions n nes. C much nicer to use than Tiny. OS n n nes. C produces smaller code than Tiny. OS n n n No more obscure C compiler warnings/errors No more obscure bugs due to typos No more obscure infinite loops due to wiring restrictions Prunes unreachable code Inlining across component boundaries The best is yet to come! n n Short-term: multiple instantiation, better inlining selection, packet format specification Long-term: language improvements for bug prevention

Packet Format Specification n Write a C file with the packet type: // Int. Msg. th: The message type for Int. To. Rfm/Rfm. To. Int typedef struct { char val; int src; } Int. Msg; enum { AM_INTMSG = 4 }; n n Use it in nes. C components via includes Automatic generation of corresponding Java type and marshaller/unmarshaller

Components n components module C 1 { requires interface triangle; } implementation {. . . } module C 2 { provides interface triangle in; requires { interface triangle out; interface rectangle side; } } implementation {. . . } configuration C 3 { provides interface triangle; provides interface rectangle; } implementation {. . . } C 1 C 2 C 3

Configurations n Connect components configuration app { } implementation { uses c 1, c 2, c 3; c 1 -> c 2; // implicit interface sel. c 2. out -> c 3. triangle; c 3 <- c 2. side; } n Partial configurations: component c 2 c 3 { provides interface triangle t 1; } implementation { uses c 2, c 3; t 1 -> c 2. in; c 2. out -> c 3. triangle; c 3 <- c 2. side; } C 1 C 2 C 3

Modules n n “C” implementation of components all top-level declarations private, except those specified in the components interface module C 2 { provides interface send in; requires interface send out; } implementation { enum { ready, busy } state; command in. send(Message m) { if (state == busy) return 0; state = busy; call out. send(m); return 1; } event out. send_done(Message m) { state = ready; signal in. send_done(m); }. . . }