1 / 81

David E. Culler University of California, Berkeley

Wireless Embedded Inter-Networking Foundations of Ubiquitous Sensor Networks TinyOS 2.0 Programing – An IPv6 Kernel Approach. David E. Culler University of California, Berkeley. Blocks. Example Complete Network Embedded System. Domain-Specific Application Components. Service Interface.

trent
Download Presentation

David E. Culler University of California, Berkeley

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related