1. June 2008 WEI L4 - TinyOS Prog 1 Wireless Embedded Inter-Networking Foundations of Ubiquitous Sensor Networks TinyOS 2.0 Programing – An IPv6 Kernel Approach David E. Culler University of California, Berkeley

2. June 2008WEI L4 - TinyOS Prog2 Example Complete Network Embedded System Microcontroller Abstraction Interface Init/Boot Persistent Attributes & Event Streams Device Attributes & Event Streams Motor Light Blocks Vibration Logs Files Device Abstraction Interface Core OS Interface Service Interface FlashRadio SerialSensor / Actuator Commands Attributes Events Discovery Network Epidemics and Routing Messages Management & Power Domain-Specific Application Components Net Prog Links Domain-Specific Device Drivers TelosmicaZimote2other SPI i2cuart timer sched ADC resource

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

4. June 2008WEI L4 - TinyOS Prog4 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

5. June 2008WEI L4 - TinyOS Prog5 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.

6. June 2008WEI L4 - TinyOS Prog6 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

7. June 2008WEI L4 - TinyOS Prog7 Illustration

8. June 2008WEI L4 - TinyOS Prog8 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

9. June 2008WEI L4 - TinyOS Prog9 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

10. June 2008WEI L4 - TinyOS Prog10 Overall System Configuration (std)

11. June 2008WEI L4 - TinyOS Prog11 TinyOS IPv6 Network Kernel Actuator Sensors TimerFlashRadioSensorActuator Network Kernel –Manages communication and storage –Scheduler (decides when to signal events) IPv6 Network Kernel Driver Application

12. June 2008WEI L4 - TinyOS Prog12 Illustration of TinyOS Programming Concepts

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

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

15. June 2008WEI L4 - TinyOS Prog15 Simple example: Boot interface $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. 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(); }

16. June 2008WEI L4 - TinyOS Prog16 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); }

17. June 2008WEI L4 - TinyOS Prog17 Timer $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 interface Timer { 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(); }

18. June 2008WEI L4 - TinyOS Prog18 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.

19. June 2008WEI L4 - TinyOS Prog19 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

20. June 2008WEI L4 - TinyOS Prog20 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 architectureTEP102 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

21. June 2008WEI L4 - TinyOS Prog21 Example – multiple virtual timers #include "Timer.h" module Blink3M { uses interface Timer as Timer0; uses interface Timer as Timer1; uses interface Timer 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(); }

22. June 2008WEI L4 - TinyOS Prog22 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

23. June 2008WEI L4 - TinyOS Prog23 Configuration 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. configuration BlinkAppC { } implementation { components MainC, BlinkM, LedsC; components new TimerMilliC() as Timer; BlinkM -> MainC.Boot; BlinkM.Leds -> LedsC; BlinkM.Timer0 -> Timer.Timer; } BlinkM Timer0BootLeds MainC Boot LedsC Leds Timer BlinkAppC

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

25. June 2008WEI L4 - TinyOS Prog25 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.

26. June 2008WEI L4 - TinyOS Prog26 Module state Private scope Sharing through explicit interface only! –Concurrency, concurrency, concurrency! –Robustness, robustness, robustness Static extent HW independent type –unlike int, long, char module BlinkC { uses interface Timer 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); }

27. June 2008WEI L4 - TinyOS Prog27 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

28. June 2008WEI L4 - TinyOS Prog28 Events Call commands Signal events Provider of interface handles calls and signals events User of interface calls commands and handles signals module BlinkM { uses interface Timer as Timer0; uses interface Leds; uses interface Boot; provides interface Notify 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); } BlinkM Timer0BootLeds Rollover Notify

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

30. June 2008WEI L4 - TinyOS Prog30 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!

31. June 2008WEI L4 - TinyOS Prog31 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;

32. June 2008WEI L4 - TinyOS Prog32 Examples - Split-Phase Sample Ready Read ReadDone

33. June 2008WEI L4 - TinyOS Prog33 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

34. June 2008WEI L4 - TinyOS Prog34 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 { /* 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 ); }

35. June 2008WEI L4 - TinyOS Prog35 Example #include "Timer.h" module SenseM { uses { interface Boot; interface Leds; interface Timer ; interface Read ; } 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?

36. June 2008WEI L4 - TinyOS Prog36 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 Timer0BootLeds MainC Boot LedsC Leds Timer TempDispAppC Read TempC Read

37. June 2008WEI L4 - TinyOS Prog37 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

38. June 2008WEI L4 - TinyOS Prog38 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(); }

39. June 2008WEI L4 - TinyOS Prog39 Examples - Tasks Sample Ready fired readDone serviceReq notify fired

40. June 2008WEI L4 - TinyOS Prog40 Tasks 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. /* BAD TIMER EVENT HANDLER */ event void Timer0.fired() { uint32_t i; for (i = 0; i < 400001; i++) { call Leds.led0Toggle(); } Hardware Interrupts event s commands Tasks /* 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(); }

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

42. June 2008WEI L4 - TinyOS Prog42 Networking Traditional TinyOS communication is based on active messages –Send a structure to –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

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

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

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

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

47. June 2008WEI L4 - TinyOS Prog47 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

48. June 2008WEI L4 - TinyOS Prog48 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

49. June 2008WEI L4 - TinyOS Prog49 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 ???

50. June 2008WEI L4 - TinyOS Prog50 UDP Interface 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 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 ); }

51. June 2008WEI L4 - TinyOS Prog51 And what about TCP UDP is a datagram transport –Essentially the same as AM –Fits naturally in event-driven model –Can use NesC platform independent data structure to have unambiguous packet formats without hton / ntoh error prone bit twiddling. But TCP is a stream protocol…

52. June 2008WEI L4 - TinyOS Prog52 TCP Interface Transitions of the TCP protocol reflected as events Recv per segment Send is NOT SPLIT PHASE !!! –More on this later interface Tcp { command error_t bind(uint16_t port, uint8_t *buf, uint16_t bufsize); event bool accept( sockaddr_in6_t *to ); command error_t connect( const sockaddr_in6_t *to, uint8_t *buf, uint16_t bufsize ); event void connected(); command error_t send( const void *buf, uint16_t len ); event void acked(); event uint16_t recv( void *buf, uint16_t len ); command error_t close( bool force ); event void closed(); }

53. June 2008WEI L4 - TinyOS Prog53 Example TinyOS Service Architecture Hardware Abstraction Layer Basic OS interface Service API FlashRadio / UartSensor/Actuator VolumesBuses & ADCsLinks Files Logs RF Light Sounder Other Commands Attributes Events Discovery Blocks OTA program Network Messages Hardware Management & Pwr Application

54. June 2008WEI L4 - TinyOS Prog54 Permanent Data Storage TinyOS 2.x provides three basic storage abstractions: –small objects, –circular logs, and –large objects. also provides interfaces the underlying storage services and components that provide these interfaces. Flash devices –ST Microelectronics M25Pxx family of flash memories used in the Telos family of motes (tos/chips/stm25p) –Atmel AT45DB family of flash memories used in the Mica2/MicaZ motes (tos/chips/at45b) –Special pxa271p30 versions for the Intel Mote2 contributed by Arch Rock. (tos/platforms/intelmote2) TEP103

55. June 2008WEI L4 - TinyOS Prog55 Storage Interfaces and Components Interfaces –BlockReadBlockRead –BlockWriteBlockWrite –MountMount –ConfigStorageConfigStorage –LogReadLogRead –LogWriteLogWrite –Storage.hStorage.h Components –ConfigStorageC - Configuration DataConfigStorageC »calibration, identity, location, sensing configuration,.. –LogStorageCLogStorageC »data –BlockStorageCBlockStorageC »Code, …

56. June 2008WEI L4 - TinyOS Prog56 Volumes TinyOS 2.x divides a flash chip into one or more fixed-sized volumes that are specified at compile-time using an XML file.

57. June 2008WEI L4 - TinyOS Prog57 Example – blink period config Define config storage object chipname.xml file Added to the TinyOS configuration New interfaces for the module Wire to the new interfaces

58. June 2008WEI L4 - TinyOS Prog58 On boot – Mount and Read

59. June 2008WEI L4 - TinyOS Prog59 Config data – done, write, commit

60. June 2008WEI L4 - TinyOS Prog60 Network Embedded Systems Hardware Abstraction Layer Basic OS interface Service API FlashRadio / UartSensor/Actuator VolumesBuses & ADCsLinks Files Logs RF Light Sounder Other Commands Attributes Events Discovery Blocks OTA program Network Messages Hardware Management & Pwr Application

61. June 2008WEI L4 - TinyOS Prog61 IP/6LoWPAN “Kernel Component” component KernelC { provides interface Boot; provides interface Timer as TimerMilli[ uint8_t id ]; provides interface TaskBasic[ uint8_t id ]; provides interface GlobalTime ; /* Global Time – NTP */ provides interface LocalIeeeEui64; /* EUI MAC Address */ provides interface Udp as Udp0; /* Udp */ provides interface Udp as Udp1; provides interface Tcp as Tcp0; /* Tcp */ provides interface Tcp as Tcp1; provides interface IPv6Addresses; /* IPv6 Utility Functions */ provides interface IPv6Notify; /* MCU generated interrupts */ provides interface HplSignal as HplSignalAdc12; provides interface HplSignal as HplSignalPort1; provides interface HplSignal as HplSignalPort2; provides interface HplSignal as HplSignalTimerA0; provides interface HplSignal as HplSignalTimerA1; provides interface HplSignal as HplSignalTimerB0; provides interface HplSignal as HplSignalTimerB1; }

62. June 2008WEI L4 - TinyOS Prog62 TinyOS IPv6 Network Kernel Actuator Sensors TimerFlashRadioSensorActuator Network Kernel –Manages communication and storage –Scheduler (decides when to signal events) IPv6 Network Kernel Driver Application

63. June 2008WEI L4 - TinyOS Prog63 Network Embedded Systems Hardware Abstraction Layer Basic OS interface Service API FlashRadio / UartSensor/Actuator VolumesBuses & ADCsLinks Config Logs RF Light Sounder Other Blocks OTA 6LoWPAN Network Hardware Management & Pwr Application ICMP / UDP / TCP Systat netstat Echo Our kernel boundary

64. June 2008WEI L4 - TinyOS Prog64 TinyOS Concepts not yet covered Generic Components –Generic modules and generic configurations –Multiple instances –Type polymorphism –Storage and configuration –Discovery Parameterized interfaces –Index array of interfaces to other components –Dispatch, services –Virtualization Platform independent structs –Replace xdr and all that –Eliminate error prone bit twiddling

65. June 2008WEI L4 - TinyOS Prog65 Discussion

66. June 2008WEI L4 - TinyOS Prog66 Traditional TinyOS Active Messages

67. June 2008WEI L4 - TinyOS Prog67 Sensor NETWORK We have a flexible, low-power, event-driven sensor / actuator platform. Let’s add the network Send / Receive of information Dispatching incoming data to computation processes that will handle it. –Automate in a systematic fashion Parsing the packet –Define the structure, let the compiler do the work. –Handler knows what it should be receiving

68. June 2008WEI L4 - TinyOS Prog68 message_t structure Packet - Provides the basic accessors for the message_t abstract data type. This interface provides commands for clearing a message's contents, getting its payload length, and getting a pointer to its payload area.Packet Send - Provides the basic address-free message sending interface. This interface provides commands for sending a message and canceling a pending message send. The interface provides an event to indicate whether a message was sent successfully or not. It also provides convenience functions for getting the message's maximum payload as well as a pointer to a message's payload area.Send Receive - Provides the basic message reception interface. This interface provides an event for receiving messages. It also provides, for convenience, commands for getting a message's payload length and getting a pointer to a message's payload area.Receive PacketAcknowledgements - Provides a mechanism for requesting acknowledgements on a per-packet basis.PacketAcknowledgements RadioTimeStamping - Provides time stamping information for radio transmission and reception.RadioTimeStamping

69. June 2008WEI L4 - TinyOS Prog69 Active Messages - Dispatching messages to their handlers AM type – dispatch selector –Frame_type at link layer –IP Protocol Field at network layer –Port at Transport layer AM_address AMPacket - Similar to Packet, provides the basic AM accessors for the message_t abstract data type. This interface provides commands for getting a node's AM address, an AM packet's destination, and an AM packet's type. Commands are also provides for setting an AM packet's destination and type, and checking whether the destination is the local node.AMPacket AMSend - Similar to Send, provides the basic Active Message sending interface. The key difference between AMSend and Send is that AMSend takes a destination AM address in its send command.AMSend

70. June 2008WEI L4 - TinyOS Prog70 Communication Components AMReceiverC - Provides the following interfaces: Receive, Packet, and AMPacket.AMReceiverC AMSenderC - Provides AMSend, Packet, AMPacket, and PacketAcknowledgements as Acks.AMSenderC AMSnooperC - Provides Receive, Packet, and AMPacket.AMSnooperC AMSnoopingReceiverC - Provides Receive, Packet, and AMPacket.AMSnoopingReceiverC ActiveMessageAddressC - Provides commands to get and set the node's active message address. This interface is not for general use and changing the a node's active message address can break the network stack, so avoid using it unless you know what you are doing.ActiveMessageAddressC

71. June 2008WEI L4 - TinyOS Prog71 HAL to HIL Since TinyOS supports multiple platforms, each of which might have their own implementation of the radio drivers, an additional, platform-specific, naming wrapper called ActiveMessageC is used to bridge these interfaces to their underlying, platform-specific implementations. ActiveMessageC provides most of the communication interfaces presented above. Platform-specific versions of ActiveMessageC, as well the underlying implementations which may be shared by multiple platforms (e.g. Telos and MicaZ) include: –ActiveMessageC for the intelmote2, micaz, telosa, and telosb are all implemented by CC2420ActiveMessageC.intelmote2micaztelosatelosbCC2420ActiveMessageC –ActiveMessageC for the mica2 platform is implemented by CC1000ActiveMessageC.mica2 CC1000ActiveMessageC –ActiveMessageC for the eyesIFX platform is implemented by Tda5250ActiveMessageC.eyesIFX Tda5250ActiveMessageC

72. June 2008WEI L4 - TinyOS Prog72 tos/types/message.htos/types/message.h. Link level concept used throughout the TinyOS research community and industry. How does this move forward to IP/WSN? typedef nx_struct message_t { nx_uint8_t header[sizeof(message_header_t)]; nx_uint8_t data[TOSH_DATA_LENGTH]; nx_uint8_t footer[sizeof(message_header_t)]; nx_uint8_t metadata[sizeof(message_metadata_t)]; } message_t;

73. June 2008WEI L4 - TinyOS Prog73 Sending a packet to the neighborhood #include #include "BlinkToRadio.h" module BlinkToRadioC { uses interface Boot; uses interface Leds; uses interface Timer as Timer0; uses interface Packet; uses interface AMPacket; uses interface AMSend; uses interface Receive; uses interface SplitControl as AMControl; } implementation { uint16_t counter; message_t pkt; bool busy = FALSE; event void Boot.booted() { call AMControl.start(); } event void AMControl.startDone(error_t err) { if (err == SUCCESS) { call Timer0.startPeriodic(TIMER_PERIOD_MILLI); }

74. June 2008WEI L4 - TinyOS Prog74 Sending a packet to the neighborhood event void Timer0.fired() { counter++; if (!busy) { BlinkToRadioMsg* btrpkt = (BlinkToRadioMsg*)(call Packet.getPayload(&pkt, NULL)); btrpkt->nodeid = TOS_NODE_ID; btrpkt->counter = counter; if (call AMSend.send(AM_BROADCAST_ADDR, &pkt, sizeof(BlinkToRadioMsg)) == SUCCESS) { busy = TRUE; } event void AMSend.sendDone(message_t* msg, error_t err) { if (&pkt == msg) { busy = FALSE; } event message_t* Receive.receive(message_t* msg, void* payload, uint8_t len){ if (len == sizeof(BlinkToRadioMsg)) { BlinkToRadioMsg* btrpkt = (BlinkToRadioMsg*)payload; call Leds.set(btrpkt->counter & 0x7); } return msg; }

75. June 2008WEI L4 - TinyOS Prog75 Receive – a network event Service the incoming message –Automatically dispatched by type to the handler Return the buffer –Or if you want to keep it, you need to return another one. Overlay a network type structure on the packet so the compiler does the parsing. event message_t* Receive.receive(message_t* msg, void* payload, uint8_t len) { if (len == sizeof(BlinkToRadioMsg)) { BlinkToRadioMsg* btrpkt = (BlinkToRadioMsg*)payload; call Leds.set(btrpkt->counter); } return msg; } enum { AM_BLINKTORADIO = 6, }; typedef nx_struct BlinkToRadioMsg { nx_uint16_t nodeid; nx_uint16_t counter; } BlinkToRadioMsg;

76. June 2008WEI L4 - TinyOS Prog76 Communication-Centric Operating Systems Design Elements Packets cross between different kinds of machines –Small Endian vs Large Endian –Representation of data types – int, long, char, … Protocols have specific message formats  Network Types  Overlay network type struct on the packet and let the compiler do the shifting, masking, and endian conversion  Eliminate error-prone parsing code Protocols are realized by state machines that advance on message events –Make external communication events as simple as internal events Network stacks involve dispatching on types at several levels –Frame type, Protocol Number, port number –Provide support for dispatch Packet events are intrinsically connected with buffer management –Make is a robust and simple as possible.

77. June 2008WEI L4 - TinyOS Prog77 AM_ID – port number #include #include "BlinkToRadio.h" configuration BlinkToRadioAppC { } implementation { components MainC, LedsC; components BlinkToRadioC as App; components new TimerMilliC() as Timer0; components ActiveMessageC; components new AMSenderC(AM_BLINKTORADIO); components new AMReceiverC(AM_BLINKTORADIO); App.Boot -> MainC; App.Leds -> LedsC; App.Timer0 -> Timer0; App.Packet -> AMSenderC; App.AMPacket -> AMSenderC; App.AMControl -> ActiveMessageC; App.AMSend -> AMSenderC; App.Receive -> AMReceiverC; }

78. June 2008WEI L4 - TinyOS Prog78 Indexed interfaces for dispatch Clients & Applications have individual view Provider has global view Active Message Network Stack Implementation Hardware SVC xSVC ySVC zSVC w

79. June 2008WEI L4 - TinyOS Prog79 Active Messages Concept – message carries unique identifier of handler that is to process it –Directly off the link –Compile time formation and parsing »It is a Structure –Bounded storage »Consume the receive buffer immediately Has been the central networking abstraction in all version of TinyOS –Used for all the multihop routing protocols, … Link frame derived from SW usage TCP/UDP / IP / 6LoWPAN will cause first serious re-examination of Message_T

80. June 2008WEI L4 - TinyOS Prog80 Parameterized Wiring Active Message clients wire to distinct AM_id –Unique ID of the service handler Many other system services provided to multiple clients (independently) but do not need a “protocol id” NesC “Unique” allocates new interfaces at compile time –Relative to a key set –Whole system compilation => tight resource allocation

81. June 2008WEI L4 - TinyOS Prog81 Wiring Examples ???