tinyos
play

TinyOS 3. Programming TinyOS Computer Network 4. Network - PDF document

Lecture Overview 1. Hardware Primer 2. Introduction to TinyOS TinyOS 3. Programming TinyOS Computer Network 4. Network Communication Programming Wenyuan Xu 1 2 UC Berkeley Family of Motes Mica2 and Mica2Dot ATmega128 CPU


  1. Lecture Overview � 1. Hardware Primer � 2. Introduction to TinyOS TinyOS � 3. Programming TinyOS Computer Network � 4. Network Communication Programming Wenyuan Xu 1 2 UC Berkeley Family of Motes Mica2 and Mica2Dot � ATmega128 CPU 1 inch � Self-programming � 128KB Instruction EEPROM � 4KB Data EEPROM � Chipcon CC1000 � Manchester encoding � Tunable frequency � 315, 433 or 900MHz � 38K or 19K baud � Lower power consumption � 2 AA batteries � Expansion � 51 pin I/O Connector 3 4 MTS300CA Sensor Board Programming Board (MIB510) 5 6

  2. Hardware Setup Overview Lecture Overview � 1. Hardware Primer � 2. Introduction to TinyOS � 3. Programming TinyOS � 4. Network Communication 7 8 What is TinyOS? Install TinyOS and the ‘make’ � An operation system � Download � From within the application’s directory: � http://www.tinyos.net/download.html � make (re)install.<node id> � An open-source development environment Directory Structure � <platform> /apps � <node id> is an integer between 0 /Blink and 255 � Not an operation system for general purpose, it is /Forwarder <platform> may be mica2, � /contrib mica2dot, or all designed for wireless embedded sensor network. /doc Example: make install.0 mica2 /tools � Official website: http://www.tinyos.net/ /java /tos /interfaces � Programming language: NesC (an extension of C) /lib /platform /mica � make pc � It features a component-based architecture. /mica2 Generates an executable that can /mica2dot � be run a pc for /sensorboard � Supported platforms include Linux, Windows 2000/XP /micasb /system with Cygwin. /types 9 10 Build Tool Chain Lecture Overview � 1. Hardware Primer Convert NesC into C and compile to exec � 2. Introduction to TinyOS Modify exec with platform-specific � 3. Programming TinyOS options Set the mote ID � 4. Network Communication Reprogram the mote 11 12

  3. Characteristics of Network Sensors A Operating System for Tiny Devices? � Small physical size and low power consumption � Main Concept � Concurrency-intensive operation � HURRY UP AND SLEEP!! � multiple flows, not wait-command-respond � Sleep as often as possible to save power � Limited Physical Parallelism and Controller � provide framework for concurrency and modularity Hierarchy � Commands, events, tasks � interleaving flows, events - never poll, never block � primitive direct-to-device interface � Separation of construction and composition � Diversity in Design and Usage � Programs are built out of components � application specific, not general purpose � Libraries and components are written in nesC. � huge device variation sensors actuators � Applications are too -- just additional components composed with the OS => efficient modularity components => migration across HW/SW boundary storage � Each component is specified by interfaces � Robust Operation � Provides “hooks” for wiring components together � numerous, unattended, critical network � Components are statically wired together based on their interfaces => narrow interfaces � Increases runtime efficiency 13 14 Programming TinyOs Component Syntax - Module � There are two types of components in nesC: � A component specifies a set of interfaces by which it is connected to other � Modules. It implements application code. components � Configurations. It assemble other components together, called wiring � provides a set of interfaces to others � uses a set of interfaces provided by others � A component does not care if another component is a module or configuration module identifier specification module-implementation � A component may be composed of other components via interface X as Y module ForwarderM { configurations provides { interface StdControl; uses provides � A component provides and uses interfaces. } uses { � A interface defines a logically related set of commands and events. CommControl interface StdControl as CommControl; � Components implement the events they use and the commands interface ReceiveMsg; ReceiveMsg they provide: StdControl interface SendMsg; interface Leds; SendMsg ForwarderM Component Commands Events } } Leds Use Can call Must implement implementation { …// code implementing all provided commands Provide Must implement Can signal = interface X as X and used events } 15 16 Component Syntax - Configuration Component Syntax - Configuration configuration Forwarder { } configuration Forwarder { } implementation implementation { { Component Component components Main, LedsC; components Main, LedsC; Selection components GenericComm as Comm; Selection components GenericComm as Comm; components ForwarderM; components ForwarderM; Main.StdControl -> ForwarderM.StdControl; Main.StdControl -> ForwarderM.StdControl; Wiring the ForwarderM.CommControl -> Comm; Wiring the ForwarderM.CommControl -> Comm; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; Components Components ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; together together ForwarderM.Leds -> LedsC; ForwarderM.Leds -> LedsC; } } uses Forwarder provides StdControl configuration identifier specification configuration-implementation CommControl ReceiveMsg ReceiveMsg GenericComm Main StdControl StdControl SendMsg SendMsg ForwarderM Leds LedsC Leds 17 18

  4. Interface Syntax- interface StdControl Interface Syntax- interface SendMsg � Look in <tos>/tos/interfaces/StdControl.nc � Look in <tos>/tos/interfaces/SendMsg.nc interface StdControl { includes AM; // includes AM.h located in <tos>\tos\types\ // Initialize the component and its subcomponents. command result_t init(); interface SendMsg { // send a message // Start the component and its subcomponents. command result_t send(uint16_t address, uint8_t length, command result_t start(); TOS_MsgPtr msg); // Stop the component and pertinent subcomponents // an event indicating the previous message was sent command result_t stop(); event result_t sendDone(TOS_MsgPtr msg, result_t success); } } � Multiple components may provide and use this interface � Includes both command and event. � Every component should provide this interface � Split the task of sending a message into two parts, send � This is good programming technique, it is not a language specification and sendDone. � To understand how an application works, start from reading the implementation of StdControl.init(), StdControl.start(). 19 20 Configuration Wires Component implementation uses module ForwarderM { provides � A configuration can bind an interface user to a //interface declaration } CommControl provider using -> or <- implementation { command result_t StdControl.init() ReceiveMsg StdControl � User.interface -> Provider.interface { call CommControl.init(); SendMsg call Leds.init(); Command ForwarderM � Provider.interface <- User.interface return SUCCESS; implementation Leds } � Bounce responsibilities using = (interface provided) command result_t StdControl.start() {…} � User1.interface = User2.interface command result_t StdControl.stop() {…} � Provider1.interface = Provider2.interface event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); � The interface may be implicit if there is no call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); Event return m; ambiguity implementation } � e.g., User.interface -> Provider �� (interface used) event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); User.interface -> Provider.interface return success; } } 21 22 TinyOS Commands and Events TinyOs Concurrency Model � TinyOS executes only one program consisting of a set of components. { ... � Two type concurrency: status = call interfaceName . CmdName(args) � Task ... } � Hardware event handler � Tasks: command CmdName(args) { event EvtName(args) { � Time flexible ... ... � Longer background processing jobs return status; return status ; } } � Atomic with respect to other tasks (single threaded) � Preempted by event Interface user � Hardware event handlers { � Time critical ... � Shorter duration (hand off to task if need be) status = signal interfaceName.EvtName(args) ... � Interrupts task and other hardware handler. • Commands “call down” } � Last-in first-out semantics (no priority among events) towards the hardware � executed in response to a hardware interrupt components Interface provider • Event “call up” towards application components 23 24

Recommend


More recommend