Docstoc

Commands

Document Sample
Commands Powered By Docstoc
					       Part 2
TinyOS and nesC
 Programming
  Selected slides from:
 Wireless Sensor Networks
     Hardware/Software
Tiny OS & NesC Programming

     borrowed from
     Turgay Korkmaz
                  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
  – Single shared stack
  – NO kernel, process/memory management
  – Sleep as often as possible to save power
        Programming Model
• Basic concept behind nesC
  • Separation of construction and composition
• Programs are built out of components
                    Components
                                                                provides
                                    StdControl       Timer
• A component is a black box
                                          Timer Component
  specified by interface(s)
• Interfaces define a set of                  Clock
                                                                 uses
  logically related I/O functions   StdControl.nc
  called commands and events        interface StdControl {
                                      command result_t init();
• Components use and provide          command result_t start();
  interfaces                          command result_t stop();
                                    }
• Components are statically         Clock.nc
  wired together based on their     interface Clock {
  interfaces                          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
           Component          Commands           Events
 Provide               Must implement    Can signal
 Use                   Can call          Must implement
             Commands and Events
• commands                                          {
                                                    ...
  – deposit request parameters into the frame        status = call CmdName(args)
                                                    ...
  – are non-blocking                                }

  – need to return status
                                                command CmdName(args) {
  – postpone time consuming work by posting a   ...
    task                                        return status;
                                                }
  – can call lower level commands
• events
                                                event EvtName(args) {
  – can call commands, signal events, post      ...
    tasks                                       return status;
                                                }
  – can Not be signaled by commands
  – preempt tasks, not vice-versa                  {
                                                   ...
  – interrupt trigger the lowest level events       status = signal EvtName(args)
                                                   ...
                                                   }
  – deposit the information into the frame
         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 {                                      provides                              uses
      interface StdControl;
   }                                                                            CommControl
   uses {
      interface StdControl as CommControl;                                       ReceiveMsg
                                                      StdControl
      interface ReceiveMsg;
      interface SendMsg;                                                            SendMsg
      interface Leds;                                              ForwarderM
  }                                                                                     Leds
}
implementation {
code implementing all                              interface StdControl {
provided commands                                  command result_t init();
used events, and                                   command result_t start();
tasks                                              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()
Command       {       call CommControl.init();
imp.                  call Leds.init();
(interface            return SUCCESS;
provided)       }
                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           }
imp.            event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool
(interface    success)
used)           {   call Leds.greenToggle();
                    return success;
                }
              }
         Component Syntax - Configuration
                      configuration Forwarder { }
                      implementation
                      {
                        components Main, LedsC;
Component               components GenericComm as Comm;
Selection               components ForwarderM;

                          Main.StdControl -> ForwarderM.StdControl;
                          ForwarderM.CommControl -> Comm;
 Wiring the               ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG];
 Components               ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG];
 together                 ForwarderM.Leds -> LedsC;
                      }


                      provides                              uses
Forwarder                                                          StdControl

                                                    CommControl
                                                                   ReceiveMsg


  Main   StdControl       StdControl                 ReceiveMsg    SendMsg      GenericComm
                                                        SendMsg
                                       ForwarderM
                                                           Leds

                                                                      Leds      LedsC
Lab 3
• The lab is done on the computer :
  • csmisc19.cs.chalmers.se
• To get a username and password:
  • do an empty submission in Fire!
• TinyOS with all sources for libraries and everything is
  installed at /opt/tinyos-2.1.0
  • Unpack Rout.tar.gz into your home directory (at the server) and
    do the assignment from there.
  • Compile the program by executing: make micaz sim
  • Run the simulation by executing: ./simulation.py <topology file>
  • Build topologies using buildtopo.py to get a grid and then
    remove some nodes to get some interesting formation
Part 1 – improve the basic routing
• Implement something better than the basic routing
  algorithm.
• The battery level is something that is known to a
  node, so feel free to use that in your algorithm.
• Report:
  • Discuss the idea behind your algorithm.
  • Present results from comparing your algorithm to the
    original algorithm.
  • Discuss failed improvements.
Part 2 – Clustered data aggregation
• Aggregate information and send it to the sink.
• Many nodes in an area send their information to a cluster
  head, that do the summarization and then sends the aggregate
  message to the sink.
• A simple algorithm to choose cluster head: for every node with
  a certain probability announces itself to be a cluster head.
  • Choose the parameters you like: battery level of the node, battery level
    of neighbors, etc.
• A cluster head should not store content for more than 1 round.
• Report:
  • Discuss the idea behind your algorithm.
  • Present results from comparing your algorithm to your
     algorithm in part one.
  • Discuss failed improvements.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:10/15/2012
language:English
pages:14