Wireless Sensor Networks Hardware/Software Tiny OS

1
Wireless Sensor NetworksHardware/SoftwareTiny
OS NesC Programming

• CS 6543 Networks
• Spring
• Turgay Korkmaz

2
Characteristics of Sensor Network

• Small physical size and low power consumption
• Concurrency-intensive operation
• multiple flows, not wait-command-respond
• Limited Physical Parallelism and Controller
  Hierarchy
• primitive direct-to-device interface
• Diversity in Design and Usage
• application specific, not general purpose
• huge device variation
• gt efficient modularity
• gt migration across HW/SW boundary
• Robust Operation
• numerous, unattended, critical
• gt narrow interfaces

3
Hardware/Software

• IRIS - MTS100 - MIB520
• Get MoteWorks from xbow.com
• Windows 2000/XP with Cygwin

4
Hardware Setup Overview
5
Mica2 and Mica2Dot IRIS
1 inch

• ATmega128 CPU
• 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

6
MTS300CA Sensor BoardMTS100
7
Programming Board (MIB510)MIB520
8
Software

• Get MoteWorks from xbow.com and install it on XP
• Windows 2000/XP with Cygwin

Directory Structure /apps /contrib /doc /tools /to
s /interfaces /lib /platform /sensorboard /sy
stem /types
9
The make system

• From within the applications directory
• make ltplgt (re)install.ltnode idgt ltpbgt,ltcomX)
• ltplgt platform (e.g., mica2, mica2dot, iris)
• ltnode idgt is an integer between 0 and 255
• 0 is for base station
• ltpbgt programming board (e.g., mib520)
• ltcpgt communication port (e.g., com5)
• make clean
• make docs
• Generates documentation in lttosgt/doc/nesdoc/iri
  s
• make pc
• Generates an executable that can be run a pc
  for
• simulation

10
Install an application usingIRIS - MIB520

• cd application_directory
• make iris
• make iris reinstall,1 mib520,com5
• motelist

11
TinyOS and nesCProgramming
12
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
• High concurrency, interrupt driven
• never poll, never block
• Single shared stack
• NO kernel, process/memory management
• Sleep as often as possible to save power

13
Programming Model

• Separation of construction and composition
• Programs are built out of components

14
Components

• A component is a black box
  specified by interface(s)
• Interfaces define a set of
  logically related I/O functions called commands
  and events
• Components use and provide interfaces
• Components are statically wired together based on
  their interfaces

StdControl.nc interface StdControl command
result_t init() command result_t start()
command result_t stop() Clock.nc interface
Clock command result_t setRate( char
interval, char scale) event
result_t fire()
15
Components (contd)

• 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

split-phase,
16
Commands and Events

• commands
• deposit request parameters into the frame
• are non-blocking
• need to return status
• postpone time consuming work by posting a task
• can call lower level commands
• events
• can call commands, signal events, post tasks
• can Not be signaled by commands
• preempt tasks, not vice-versa
• interrupt trigger the lowest level events
• deposit the information into the frame

... status call CmdName(args) ...
command CmdName(args) ... return status
event EvtName(args) ... return status
... status signal EvtName(args) ...
17
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

18
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

19
Component Syntax - module
module ForwarderM provides
interface StdControl uses
interface StdControl as CommControl
interface ReceiveMsg interface
SendMsg interface Leds
implementation code implementing all
provided commands used events, and tasks
interface StdControl command result_t init()
command result_t start() 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)
20
Component implementation
module ForwarderM //interface
declaration implementation command result_t
StdControl.init() call CommControl.init()
call Leds.init() return SUCCESS
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 result_t
SendMsg.sendDone(TOS_MsgPtr msg, bool success)
call Leds.greenToggle() return
success
Command imp. (interface provided)
Event imp. (interface used)
21
Component Syntax - Configuration
configuration Forwarder implementation
components Main, LedsC components GenericComm
as Comm components ForwarderM
Main.StdControl -gt ForwarderM.StdControl
ForwarderM.CommControl -gt Comm
ForwarderM.SendMsg -gt Comm.SendMsgAM_INTMSG
ForwarderM.ReceiveMsg -gt Comm.ReceiveMsgAM_INTMSG
ForwarderM.Leds -gt LedsC
Component Selection
Wiring the Components together
Forwarder
22
Configuration Wires

• A configuration can bind an interface user to a
  provider using -gt or lt-
• User.interface -gt Provider.interface
• Provider.interface lt- User.interface
• Bounce responsibilities using
• User1.interface User2.interface
• Provider1.interface Provider2.interface
• May be implicit if there is no ambiguity
• e.g., User.interface -gt Provider
• User.interface -gt Provider.interface

23
(No Transcript)
24
TinyOS Execution

• two level scheduling events and tasks

main while(1) while(more_tasks)
schedule_task sleep
25
Events and Tasks

• Tasks
• Time flexible
• Longer background processing jobs
• Hardware event handlers
• Time critical
• Shorter duration (hand off to task if need be)
• Interrupts task and other hardware handler.
• Last-in first-out semantics (no priority among
  events)
• executed in response to a hardware interrupt
• do not confuse an event from the NesC event
  keyword!!

26
TASKS

• provide concurrency internal to a component
• longer running operations
• can not preempt another task
• events preempt tasks (higher priority)
• event may preempt another event
• event should be smaller by posting task
• able to perform operations beyond
  event context
• may call commands
• may signal events

... post TskName() ...
Put into task queue Execute later
task void TskName ...
27
Typical application use of tasks

• event driven data acquisition
• schedule task to do computational portion

event result_t sensor.dataReady(uint16_t data)
putdata(data) post processData()
return SUCCESS task void processData()
int16_t i, sum0 for (i0 i maxdata
i) sum (rdatai 7)
display(sum shiftdata)

• 128 Hz sampling rate
• simple FIR filter
• dynamic software tuning for centering the
  magnetometer signal (1208 bytes)
• digital control of analog, not DSP
• ADC (196 bytes)

28
Tasks in low-level operation

• transmit packet
• send command schedules task to calculate CRC
• task initiated byte-level data pump
• events keep the pump flowing
• receive packet
• receive event schedules task to check CRC
• task signals packet ready if OK
• byte-level tx/rx
• task scheduled to encode/decode each complete
  byte
• must take less time that byte data transfer
• i2c component
• i2c bus has long suspensive operations
• tasks used to create split-phase interface
• events can procede during bus transactions

29
Concurrency in TinyOS/nesC

• The execution model consists of
• run-to-completion tasks that typically represent
  the ongoing computation
• interrupt handlers that are signaled
  asynchronously by hardware.
• 2 types of code in nesC
• Synchronous Code (SC) code (functions, commands,
  events, tasks) that is only reachable from tasks.
• Asynchronous Code (AC) code that is reachable
  from at least one interrupt handler.
• Anything executed as a direct result of a
  hardware interrupt must be declared async (e.g.,
  async command result_t cmdName())

30
Data Race Conditions

• Tasks may be preempted by other asynchronous code
• Variables shared across sync and async boundaries
  should be protected by atomic

async command bool toggle() if (state 0)
state 1 ? INTERRUPT
return 1 if (state 1) state 0
return 0
Now look what happens if the command is called in
the middle of another execution (we start with
state 0 ) CALL toggle() since (state
0) state 1 ? INTERRUPT toggle() since
(state 1) state 0 returns 0 END
INTERRUPT return 1 END CALL The function will
return 1 even though state is in fact 0. The code
word atomic can delimit sections of code that run
atomically.
31
Data Race Conditions (contd)

• Races are avoided by
• Accessing shared data exclusively within task(s)
• Having all accesses within atomic statements
• Race-Free Invariant Any update to shared state
  is either SC-only or occurs in an atomic
  statement.
• The nesC compiler (ncc) reports potential data
  races to the programmer at compiling time
• If potential race condition is present and
  programmer knows its not an actual race
  condition, he/she can specify something as
  norace
• should be used with extreme caution
• There are lots of examples in HPL.nc components
  found under lttosgt/tos/platform (e.g.,
  HPLClock.nc)

32
atomic section

• Atomic blocks should be used when a variable can
  be accessed by an asynchronous function
• However, it does not mean that an atomic block
  cannot be preempted
• It only means that two segments that access the
  same variables cannot preempt one another.
• programmer should not overuse the atomic codeword
  since it has a CPU cost.
• Atomicity is implemented by simply
  disabling/enabling interrupts (this only takes a
  few cycles).
• Disabling interrupts for a long time can delay
  interrupt handling and make systems less
  responsive.
• A block should be of small size, the exact length
  of an atomic statement is a complex matter.

33
(No Transcript)
34
Syntax summary

• Command
• Define command CmdName(args)
• Call call interfaceName.commandName(arg)
• Event
• Define event EvtName(args) ...
• Signal signal interfaceName.EvtName(args)
• Task
• Define task void TaskName()
• Call post TaskName()

35
Data Memory Model

• STATIC memory allocation!
• No heap (malloc)
• No function pointers
• Global variables
• Available on a per-frame basis
• Local variables
• Saved on the stack
• Declared within a method

36
(No Transcript)
37
Inter-Node Communication General Idea

• -Sender

38
Active Messaging

• All the messages sending/receiving in TinyOS are
  implemented as active messages
• The definitions are found in tos/types/AM.h
• Each message on the network specifies a HANDLER
  ID (group) in the header.
• HANDLER ID invokes specific handler on recipient
  nodes
• When a message is received, the EVENT wired that
  HANDLER ID is signaled
• Different nodes can associate different receive
  event handlers with the same HANDLER ID

39
Active Messaging (contd)
40
TOS Active Messages

• Message is active because it contains the
  destination address, group ID, and type.
• group group IDs create a virtual network
• an 8 bit value specified in lttosgt/apps/Makelocal
• The address is a 16-bit value specified by make
• make iris install.ltidgt ltpbgt,com5
• length specifies the size of the message .
• crc is the check sum

typedef struct TOS_Msg // the following are
transmitted uint16_t addr uint8_t
type uint8_t group uint8_t length int8_t
dataTOSH_DATA_LENGTH uint16_t crc // the
following are not transmitted uint16_t
strength uint8_t ack uint16_t time uint8_t
sendSecurityMode uint8_t receiveSecurityMode
TOS_Msg
41
Receiving a message

• Define the message format
• Define a unique active message number
• How does TOS know the AM number?

configuration Forwarder implementation
ForwarderM.SendMsg -gt Comm.SendMsgAM_INTMSG
ForwarderM.ReceiveMsg -gt Comm.ReceiveMsgAM_INTMSG

42
Sending a message

• Define the message format
• Define a unique active message number
• How does TOS know the AM number?

configuration Forwarder implementation
ForwarderM.SendMsg -gt Comm.SendMsgAM_INTMSG
ForwarderM.ReceiveMsg -gt Comm.ReceiveMsgAM_INTMSG

43
References

• google.com tinyos tutorial
• Text
• http//csl.stanford.edu/pal/pubs/tinyos-programm
  ing.pdf
• http//www.ece.rochester.edu/merlin/academic/Tin
  yOSTutorial.pdf
• Presentations
• TinyOS Tutorial, Chien-Liang Fok,
  http//www.princeton.edu/wolf/EECS579/imotes/tos_
  tutorial.pdf
• TinyOS Tutorial, wenyuan Xu
  www.winlab.rutgers.edu/trappe/Courses/CommNetsF06
  /Comnet_TinyOS_Tutorial_xwy.ppt
• Programming TinyOS, David Culler, Phil Levis,
  Rob Szewczyk, Joe Polastre www.tinyos.net/mobisys/
  2-tinyos.ppt