David E. Culler University of California, Berkeley

1. Wireless Embedded Inter-NetworkingFoundations of Ubiquitous Sensor NetworksTinyOS 2.0 Programing – An IPv6 Kernel Approach David E. Culler University of California, Berkeley WEI L4 - TinyOS Prog

2. Blocks Example Complete Network Embedded System Domain-Specific Application Components ServiceInterface Persistent Attributes & Event Streams Init/Boot Messages Commands Attributes Events Discovery DeviceAttributes &Event Streams Management & Power Core OSInterface Files Logs Net Prog NetworkEpidemics and Routing Vibration Light Motor Domain-SpecificDevice Drivers Links Device Abstraction Interface Flash RadioSerial Sensor / Actuator resource Microcontroller Abstraction Interface sched ADC uart i2c SPI timer Telos micaZ imote2 other WEI L4 - TinyOS Prog

3. Outline • Key TinyOS Concepts • TinyOS Abstraction Architecture • A Simple Event-Driven Example • Execution Model • Critical system elements • Timers, Sensors, Communication • Service Architecture WEI L4 - TinyOS Prog

4. TinyOS 2.0 • Primary Reference: http://www.tinyos.net/tinyos-2.x/doc/ • http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/ • http://nescc.sourceforge.net/papers/nesc-ref.pdf WEI L4 - TinyOS Prog

5. Key TinyOS Concepts • Application / System = Graph of Components + Scheduler • Module: component that implements functionality directly • Configuration: component that composes components into a larger component by connecting their interfaces • Interface: Logically related collection of commands and events with a strongly typed (polymorphic) signature • May be parameterized by type argument • Provided to components or Used by components • Command: Operation performed (called) across components to initiate action. • Event: Operation performed (signaled) across components for notification. • Task: Independent thread of control instantiated within a component. Non-preemptive relative to other task. • Synchronous and Asynchronous contexts of execution. WEI L4 - TinyOS Prog

6. TinyOS Abstraction Architecture • HPL – Hardware Presentation Layer • Components that encapsulate physical hardware units • Provide convenient software interface to the hardware. • The hardware is the state and computational processes. • Commands and events map to toggling pins and wires • HAL –Hardware Abstraction Layer • Components that provide useful services upon the basic HW • Permitted to expose any capabilities of the hardware • Some platforms have more ADC channels, Timers, DMA channels, capture registers, … • Logically consistent, but unconstrained • HIL – Hardware Independent Layer • Components that provide well-defined services in a manner that is the same across hardware platforms. • Implement common interfaces over available HAL WEI L4 - TinyOS Prog

7. Illustration WEI L4 - TinyOS Prog

8. TinyOS – a tool for defining abstractions • All of these layers are constructed with the same TinyOS primitives. • We’ll illustrate them from a simple application down. • Note, components are not objects, but they have strong similarities. • Some components encapsulate physical hardware. • All components are allocated statically (compile time) • Whole system analysis and optimization • Logically, all components have internal state, internal concurrency, and external interfaces (Commands and Events) • Command & Event handlers are essentially public methods • Locally scoped • Method invocation and method hander need not have same name (like libraries and objects) • Resolved statically by wiring • Permits interpositioning WEI L4 - TinyOS Prog

9. Platform is a collection of Chips • TinyOS 2.x components provide the capabilities of the chips. • TinyOS 2.x components glue to together those capabilities into a consistent system. • TinyOS 2.x components provide higher level capabilities and services WEI L4 - TinyOS Prog

10. Overall System Configuration (std) WEI L4 - TinyOS Prog

11. Application IPv6 Network Kernel Driver Driver Driver Driver Driver Driver Sensors Actuator Sensors Actuator Radio Timer Flash Sensor Actuator TinyOS IPv6 Network Kernel • Network Kernel • Manages communication and storage • Scheduler (decides when to signal events) WEI L4 - TinyOS Prog

12. Illustration of TinyOS Programming Concepts WEI L4 - TinyOS Prog

13. A simple event-driven module – BlinkM.nc #include "Timer.h" module BlinkM { uses interface Boot; uses interface Timer<TMilli> as Timer0; uses interface Leds; } implementation { event void Boot.booted() { call Timer0.startPeriodic( 250 ); } event void Timer0.fired() { call Leds.led0Toggle(); } • Coding conventions: TEP3 Module Module name Internal name of external interface BlinkM Boot Timer0 Leds • Interfaces • Boot • Timer • Leds WEI L4 - TinyOS Prog

14. A simple event-drvien module (cont) #include "Timer.h" module BlinkM { uses interface Boot; uses interface Timer<TMilli> as Timer0; uses interface Leds; } implementation { event void Boot.booted() { call Timer0.startPeriodic( 250 ); } event void Timer0.fired() { call Leds.led0Toggle(); } BlinkM Boot Timer0 Leds ? ? ? Two Event Handlers Each services external event by calling command on some subsystem WEI L4 - TinyOS Prog

15. Simple example: Boot interface interface Boot { /** * Signaled when the system has booted successfully. Components can * assume the system has been initialized properly. Services may * need to be started to work, however. * * @see StdControl * @see SplitConrol * @see TEP 107: Boot Sequence */ event void booted(); } • $tinyOS-2.x/tos/interfaces/ • Defined in TEP 107 – Boot Sequence • Consists of a single event. • Hardware and operating system actions prior to this simple event may vary widely from platform to platform. • Allows module to initialize itself, which may require actions in various other parts of the system. WEI L4 - TinyOS Prog

16. Simple example: LEDs interface • $tinyOS-2.x/tos/interfaces/ • set of Commands • Cause action • get/set a physical attribute (3 bits) • async => OK to use even within interrupt handlers • Physical wiring of LEDs to microcontroller IO pins may vary => We will implement a simplified version #include "Leds.h" interface Leds { async command void led0On(); async command void led0Off(); async command void led0Toggle(); async command void led1On(); ... /* * @param val a bitmask describing the on/off settings of the LEDs */ async command uint8_t get(); async command void set(uint8_t val); } WEI L4 - TinyOS Prog

17. Timer interface Timer<precision_tag> { command void startPeriodic(uint32_t dt); event void fired(); command void startOneShot(uint32_t dt); command void stop(); command bool isRunning(); command bool isOneShot(); command void startPeriodicAt(uint32_t t0, uint32_t dt); command void startOneShotAt(uint32_t t0, uint32_t dt); command uint32_t getNow(); command uint32_t gett0(); command uint32_t getdt(); } • $tinyOS-2.x/tos/lib/timer/Timer.nc • Rich application timer service built upon lower level capabilities that may be very different on different platform • Microcontrollers have very idiosyncratic timers • Parameterized by precision WEI L4 - TinyOS Prog

18. TinyOS Directory Structure • tos/system/ - Core TinyOS components. This directory's • components are the ones necessary for TinyOS to actually run. • tos/interfaces/ - Core TinyOS interfaces, including • hardware-independent abstractions. Expected to be heavily used not just by tos/system but throughout all other code. tos/interfaces should only contain interfaces named in TEPs. • tos/platforms/ - code specific to mote platforms, but chip-independent. • tos/chips/***/ - code specific to particular chips and to chips on particular platforms. • tos/lib/***/ - interfaces and components which extend the usefulness of TinyOS but which are not viewed as essential to its operation. • apps/, apps/demos, apps/tests, apps/tutorials. WEI L4 - TinyOS Prog

19. Kernel Overlay for this course • Trunk • Kernel • Include • Interfaces • Lib • Make • Src • Tools • TOS: TinyOS code that we will work with • Drivers – abstractions of phyisical hardware • Epic • Telosb • Lib – Useful serves • App* • Binaries – precompiled tinyos Apps • Unix WEI L4 - TinyOS Prog

20. Timers • Timers are a fundamental element of Embedded Systems • Microcontrollers offer a wide range of different hardware features • Idiosyncratic • Logically Timers have • Precision - unit of time the present • Width - # bits in the value • Accuracy - how close to the precision they obtain • TEP102 defines complete TinyOS timer architecture • Direct access to low-level hardware • Clean virtualized access to application level timers #include "Timer.h“ … typedef struct { } TMilli; // 1024 ticks per second typedef struct { } T32khz; // 32768 ticks per second typedef struct { } TMicro; // 1048576 ticks per second WEI L4 - TinyOS Prog

21. Example – multiple virtual timers #include "Timer.h" module Blink3M { uses interface Timer<TMilli> as Timer0; uses interface Timer<TMilli> as Timer1; uses interface Timer<TMilli> as Timer2; uses interface Leds; uses interface Boot; } implementation { event void Boot.booted() { call Timer0.startPeriodic( 250 ); call Timer1.startPeriodic( 500 ); call Timer2.startPeriodic( 1000 ); } event void Timer0.fired() { call Leds.led0Toggle(); } event void Timer1.fired() { call Leds.led1Toggle(); } event void Timer2.fired() { call Leds.led2Toggle(); } } WEI L4 - TinyOS Prog

22. Composition • Our event-driven component, Blink, may be built directly on the hardware • For a particular microcontroller on a particular platform • or on a simple layer for a variety of platforms • or on a full-function kernel • Or it may run in a simulator on a PC, • Or… • As long as it is wired to components that provide the interfaces that this component uses. • And it can be used in a large system or application WEI L4 - TinyOS Prog

23. Timer Timer Configuration BlinkAppC • Generic components create service instances of an underlying service. Here, a virtual timer. • If the interface name is same in the two components, only one need be specified. BlinkM Boot Timer0 Leds configuration BlinkAppC { } implementation { components MainC, BlinkM, LedsC; components new TimerMilliC() as Timer; BlinkM -> MainC.Boot; BlinkM.Leds -> LedsC; BlinkM.Timer0 -> Timer.Timer; } Boot Leds MainC LedsC WEI L4 - TinyOS Prog

24. A Different Configuration • Same module configured to utilize a very different system substrate. BlinkC BlinkM configuration blinkC{ } implementation{ components blinkM; components MainC; components Kernel; blinkM.Boot -> Kernel.Boot; blinkM.Leds -> Kernel.Leds; components new TimerMilliC(); blinkM.Timer0 -> TimerMilliC.Timer; } Boot Timer0 Leds Timer Boot Leds TimerMillic Kernel WEI L4 - TinyOS Prog

25. Execution Behavior • Timer interrupt is mapped to a TinyOS event. • Handled in a safe context • Performs simple operations. • When activity stops, entire system sleeps • In the lowest possible sleep state • Never wait, never spin. Automated, whole-system power management. WEI L4 - TinyOS Prog

26. Module state module BlinkC { uses interface Timer<TMilli> as Timer0; uses interface Leds; users interface Boot; } implementation { uint8_t counter = 0; event void Boot.booted() { call Timer0.startPeriodic( 250 ); } event void Timer0.fired() { counter++; call Leds.set(counter); } } • Private scope • Sharing through explicit interface only! • Concurrency, concurrency, concurrency! • Robustness, robustness, robustness • Static extent • HW independent type • unlike int, long, char WEI L4 - TinyOS Prog

27. TinyOS / NesC Platform Independent Types • Common numeric types • Bool, … • Network Types • Compiler does the grunt work to map to canonical form http://nescc.sourceforge.net WEI L4 - TinyOS Prog

28. Events module BlinkM { uses interface Timer<TMilli> as Timer0; uses interface Leds; uses interface Boot; provides interface Notify<bool> as Rollover; } implementation { uint8_t counter = 0; event void Boot.booted() { call Timer0.startPeriodic( 250 ); } event void Timer0.fired() { counter++; call Leds.set(counter); if (!counter) signal Rollover.notify(TRUE); } } • Call commands • Signal events • Provider of interface handles calls and signals events • User of interface calls commands and handles signals Notify Rollover BlinkM Boot Timer0 Leds WEI L4 - TinyOS Prog

29. Start Timer TCP Bind Start Examples - Event-Driven Execution Service request recv Fire WEI L4 - TinyOS Prog

30. Split-Phase Operations • For potentially long latency operations • Don’t want to spin-wait, polling for completion • Don’t want blocking call - hangs till completion • Don’t want to sprinkle the code with explicit sleeps and yields • Instead, • Want to service other concurrent activities will waiting • Want to go sleep if there are none, and wake up upon completion • Split-phase operation • Call command to initiate action • Subsystem will signal event when complete • The classic concurrent I/O problem, but also want energy efficiency. • Parallelism, or sleep. • Event-driven execution is fast and low power! WEI L4 - TinyOS Prog

31. Examples /* Power-hog Blocking Call */ if (send() == SUCCESS) { sendCount++; } /* Split-phase call */ // start phase … call send(); … } //completion phase void sendDone(error_t err) { if (err == SUCCESS) { sendCount++; } } /* Programmed delay */ state = WAITING; op1(); sleep(500); op2(); state = RUNNING state = WAITING; op1(); call Timer.startOneShot(500); command void Timer.fired() { op2(); state = RUNNING; WEI L4 - TinyOS Prog

32. Ready ReadDone Examples - Split-Phase Sample Read WEI L4 - TinyOS Prog

33. Sensor Readings • Sensors are embedded I/O devices • Analog, digital, … many forms with many interfaces • To obtain a reading • configure the sensor • and/or the hardware module it is attached to, • ADC and associated analog electronics • SPI bus, I2C, UART • Read the sensor data • TinyOS 2.x allows applications to do this in a platform-independent manner WEI L4 - TinyOS Prog

34. Read Interface • Split-phase data acquisition of typed values • Flow-control handshake between concurrent processed • Hardware or software • $tinyOS-2.x/tos/interface/read.nc interface Read<val_t> { /* Initiates a read of the value. * @return SUCCESS if a readDone() event will eventually come back. */ command error_t read(); /** * Signals the completion of the read(). * * @param result SUCCESS if the read() was successful * @param val the value that has been read */ event void readDone( error_t result, val_t val ); } WEI L4 - TinyOS Prog

35. Example #include "Timer.h" module SenseM { uses { interface Boot; interface Leds; interface Timer<TMilli>; interface Read<uint16_t>; } } implementation { #define SAMPLING_FREQUENCY 100 event void Boot.booted() { call Timer.startPeriodic(SAMPLING_FREQUENCY); } event void Timer.fired() { call Read.read(); } event void Read.readDone(error_t result, uint16_t data) { if (result == SUCCESS){ call Leds.set(data & 0x07);} } } • What does it sense? WEI L4 - TinyOS Prog

36. Timer Timer Temp example configuration configuration TempDispAppC { } implementation { components SenseM, MainC, LedsC, new TimerMilliC() as Timer, TempC ; SenseM.Boot -> MainC; SenseM.Leds -> LedsC; SenseM.Timer -> TimerMilliC; SenseM.Read -> TempC; } SenseM TempDispAppC Boot Read Timer0 Leds Boot Read Leds MainC TempC LedsC WEI L4 - TinyOS Prog

37. Concurrency • Commands and event glue together concurrent activities • Hardware units operate on parallel • Commands used to initiate activity • Events used to signal completion, etc. • System software components are very similar • But they don’t have dedicated hardware to keep working on the command. • Tasks are used for that • Decouple execution and leave room for juggling • Use lots of little tasks to keep things flowing • Preempted by async events (interrupts) • Not other tasks WEI L4 - TinyOS Prog

38. Tasks – Crossing the Asynch / Synch Boundary module UserP { provides interface Button; uses interface Boot; uses interface Msp430Port as Pin; uses interface Msp430PortInterrupt as PinInt; } implementation { event void Boot.booted() { call Pin.setDirection(0); /* Input */ call PinInt.edge(1); /* Rising edge, button release */ call PinInt.enable(1); /* Enable interrupts */ } task void fire() { signal Button.pressed(); /* Signal event to upper layers */ } async event void PinInt.fired() { post fire(); } } WEI L4 - TinyOS Prog

39. Ready Examples - Tasks serviceReq notify Sample fired readDone fired WEI L4 - TinyOS Prog

40. Tasks events commands Interrupts Hardware Tasks /* BAD TIMER EVENT HANDLER */ event void Timer0.fired() { uint32_t i; for (i = 0; i < 400001; i++) { call Leds.led0Toggle(); } } • Need to juggle many potentially bursty events. • If you cannot get the job done quickly, record the parameters locally and post a task to do it later. • Tasks are preempted by lower level (async) events. • Allow other parts of the system to get the processor. • Without complex critical semaphores, critical sections, priority inversion, schedulers, etc. /* Better way to do a silly thing */ task void computeTask() { uint32_t i; for (i = 0; i < 400001; i++) {} } event void Timer0.fired() { call Leds.led0Toggle(); post computeTask(); } WEI L4 - TinyOS Prog

41. Uses of tasks (???) • High speed sampling • Filtering • Queueing • Smoothing • Detection • Classification • … WEI L4 - TinyOS Prog

42. Networking • Traditional TinyOS communication is based on active messages • Send a structure to <node,handlerId> • Receive is just a network event that signals the hander with a message • Earliest TinyOS (0.3) was essentially moving Active Messages and the Threaded Abstract Machine (TAM) from the MPP domain to emdedded devices. • Parallel Machine communication is internal! • Sensor networks are networks, not distributed computers • They connect to OTHER NETWORKS • Active Messages covered in Appendix • But I don’t use them any more WEI L4 - TinyOS Prog

43. Intranet/Internet (IP) Client Data Browsing and Processing Canonical SensorNet Network Architecture Patch Network Sensor Node Sensor Node Sensor Patch Gateway Gateway Transit Network (IP or not) Access point - Base station - Proxy Verification links Other information sources Data Service WEI L4 - TinyOS Prog

44. Internet VPN tunnels External networks ISP Company Router / Firewall Internal Private networks DMZ externally accessible hosts ethernet internally accessible hosts WiFi serial lines leased links point-point links WiFI Stand-alone networks inaccessible hosts Typical IP Network WEI L4 - TinyOS Prog

45. OTA IP 6LowPAN L2 UDP/TCP L4 IP route L3 TinyOS 2x Embedded IP Architecture Higher Level Embedded Web Services Basic Health & Mgmt Services Basic Configuration Services Low-Power 802.15.4 Flash Storage Sensor Drivers Virtual ms Timer Pwr Mgr Scheduler Ext. INT GPIO Pins s Timer SPI, i2c, UART ADC RTC arbiters WEI L4 - TinyOS Prog

46. Internet Internet IP-based corporate networks IP-based corporate networks gateway computer Router / Firewall controllers & analytics controllers & analytics ad hoc embedded network IP-based embedded network ad hoc embedded network IP-based embedded network monitoring devices monitoring devices Internally connected embedded networks Stand-alone embedded networks WSNs in an IP context WEI L4 - TinyOS Prog

47. Issues in Communication Abstraction • Names • What are they? • What do they mean? What is their scope? • How are they allocated? • How are they translated into useful properties • Address? Physical Resource? • Storage • Transmit • When can it be reused? How do you know? What do you do when it is full? • Receive • When is it allocated? Reclaimed? By whom? What happens when it overflows? • Asynchronous event • How do you know that something has arrived? • Many more issues in actually performing the requested communication WEI L4 - TinyOS Prog

48. Answers: Naming • TinyOS Active Messages • TOS_local_addr, 16 bits, only within “a network”, allocated at program download time • Scope limited to TOS_group, within PAN, Channel, and physical extent. • The standards that try to do it all with IEEE 802.15.4 16 bit short address are not much better • IP Architecture • Link name: IEEE 802.15.4 => EUID64 & SA16 • EUID64 globally unique, SA16 assigned to be unique over the PAN • Net name: IP address • Prefix | Interface Id • Must be unique within routability extent • Several IP address: Link Local, Global, Multicast, … • Service name: Port • Hostname Translated to IP by DNS WEI L4 - TinyOS Prog

49. Answers: Storage • TinyOS Active Messages • Sender app allocates send buffer, OS owns it till sendDone event • OS provides App with recv buffer, app must return it or a replacement • BSD Sockets • Sender app allocate buffer, copied to kernel on send • Receiver allocates buffer and passes pointer to kernel, kernel copies • Additional sets of buffer managed within the kernel • TinyOS Sockets ??? WEI L4 - TinyOS Prog

50. UDP Interface interface Udp { command error_t bind( uint16_t port ); command uint16_t getMaxPayloadLength( const sockaddr_in6_t *to ); command error_t sendto( const void *buf, uint16_t len, const sockaddr_in6_t *to ); event void recvfrom( void *buf, uint16_t len, sockaddr_in6_t *from, link_metadata_t *metadata ); } • Wiring to a UDP interface is enough for sendto • Standard Unix sockaddr_in6_t • Bind – associates the component that uses the interface with the port • Starts receiving whatever datagrams come in on it • Sendto sends a datagram from a buf to a IP destination • Neighbor, intra-PAN, inter-network (wherever it needs to go!) • Linklocal address is 1-hop neighbor • Pan-wide routable prefix • Error when not in network or overrun transmit resources • Recvfrom gets a buffer with a datagram and metadata about it • Able to fill the 15.4 frame without knowing details of header compression WEI L4 - TinyOS Prog