Lab 3, Part 2 Selected slides from: Wireless Sensor Networks Hardware/Software Tiny OS & NesC Programming borrowed from Turgay Korkmaz

TinyOS and nesC Programming

What is TinyOS? Operating system developed by UC Berkeley Open Source development environment – System, library and applications written in nesC nesC (network embedded system C) a component-based C – Event-driven architecture – High concurrency, interrupt driven never poll, never block – Single shared stack – NO kernel, process/memory management – Sleep as often as possible to save power

Programming Model Separation of construction and composition Programs are built out of components

Components A component is a black box specified by interface(s) Interfaces define a set of logically related I/O functions called commands and events Components use and provide interfaces Components are statically wired together based on their interfaces Timer Component StdControl Timer Clock provides uses StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Clock.nc interface Clock { command result_t setRate( char interval, char scale); event result_t fire(); }

Components (cont’d)‏ A component – Processes Commands – Throws Events – Has a Frame for local state – Uses Tasks for concurrency Components must implement – the events they use and – the commands they provide Messaging Component init Power(mode)‏ TX_packet(buf)‏ TX_packet_done (success)‏ RX_packet_done (buffer)‏ Internal State init power(mode)‏ send_msg(addr, type, data)‏ msg_rec(type, data)‏ msg_send_done)‏ internal thread Commands Events Can signalMust implement Provide Must implementCan call Use EventsCommandsComponent } split-phase,

Commands and Events commands – deposit request parameters into the frame – are non-blocking – need to return status – postpone time consuming work by posting a task – can call lower level commands events – can call commands, signal events, post tasks – can Not be signaled by commands – preempt tasks, not vice-versa – interrupt trigger the lowest level events – deposit the information into the frame {... status = call CmdName(args)‏... } command CmdName(args) {... return status; } {... status = signal EvtName(args)‏... } event EvtName(args) {... return status; }

Component Hierarchy Components are wired together by connecting users with providers Commands: – Flow downwards – Control returns to caller Events: – Flow upwards – Control returns to signaler

Types of Components There are two types of components: Modules: provide code that implements one or more interfaces and internal behavior Configurations: Wires/links components together to yield a new component A component does not care if another component is a module or configuration A component may be composed of other components

Component Syntax - module module ForwarderM { provides { interface StdControl; } uses { interface StdControl as CommControl; interface ReceiveMsg; interface SendMsg; interface Leds; } implementation { code implementing all provided commands used events, and tasks } ForwarderM StdControl ReceiveMsg provides uses CommControl SendMsg Leds interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } interface SendMsg{ command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg); event result_t sendDone(TOS_MsgPtr msg, result_t success); }

Component implementation module ForwarderM { //interface declaration } implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; } Command imp. (interface provided)‏ Event imp. (interface used)‏

Component Syntax - Configuration configuration Forwarder { } implementation { components Main, LedsC; components GenericComm as Comm; components ForwarderM; Main.StdControl -> ForwarderM.StdControl; ForwarderM.CommControl -> Comm; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.Leds -> LedsC; } Component Selection Wiring the Components together ForwarderM StdControl ReceiveMsg provides uses CommControl SendMsg Leds Main StdControl LedsC Leds GenericComm SendMsg ReceiveMsg StdControl Forwarder

Configuration Wires A configuration can bind an interface user to a provider using -> or <- – User.interface -> Provider.interface – Provider.interface <- User.interface Bounce responsibilities using = – User1.interface = User2.interface – Provider1.interface = Provider2.interface May be implicit if there is no ambiguity – e.g., User.interface -> Provider – User.interface -> Provider.interface