TinyOS Software Challenges - TinyOS Power efficient Pu

1
TinyOS
2
Software Challenges - TinyOS

• Power efficient
• Put microcontroller and radio to sleep
• Small memory footprint
• Non-preemptable FIFO task scheduling
• Efficient modularity
• Function call (event and command) interface
  between commands
• Application specific
• Concurrency-intensive operation
• Event-driven architecture
• No user/kernel boundary

3
TinyOS Hardware Abstraction Architecture (HAA)

• Section 2.3 and Figure 2.5 of J. Polastre
  Dissertation http//www.polastre.com/papers/polas
  tre-thesis-final.pdf

4
TinyOS Hardware Abstraction Architecture (HAA)
Ref Figure 2.4 of J. Polastre Dissertation
http//www.polastre.com/papers/polastre-thesis-fin
al.pdf
5
Traditional OS Architectures

• Problem with Large Scale Deeply embedded system..
• Large memory storage requirement
• Unnecessary and overkill functionality (
  address space isolation,
• complex I/O subsystem , UI ) for our scenario.
• Relative high system overhead ( e.g, context
  switch )
• Require complex and power consuming hardware
  support.

6
TinyOS Architecture Overview (1)
TinyOS
Scheduler
.
I/O
COMM .
NO Kernel Direct hardware
manipulation NO Process management Only
one process on the fly. NO Virtual memory
Single linear physical address space NO Dynamic
memory allocation Assigned at compile
time NO Software signal or exception
Function Call instead Goal to strip down memory
size and system overhead.
7
TinyOS Overview

• Application scheduler graph of components
• Compiled into one executable
• Event-driven architecture
• Single shared stack
• No kernel/user space differentiation

Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Communication
Hardware Abstractions
8
TinyOS Component Model

• Component has
• Frame (storage)
• Tasks computation
• Interface
• Command
• Event
• Frame static storage model - compile time memory
  allocation (efficiency)
• Command and events are function calls (efficiency)

9
Power Optimization

• Energy is the most valuable resource
• All components must support low power modes
  (sleep)
• Low Duty cycle operation
• Duty cycle - The proportion of time during which
  a device is operated
• Get job done quickly and go to sleep!

10
Typical WSN Application
processing data acquisition communication

• Periodic
• Data Collection
• Network Maintenance
• Majority of operation
• Triggered Events
• Detection/Notification
• Infrequently occurs
• But must be reported quickly and reliably
• Long Lifetime
• Months to Years without changing batteries
• Power management is the key to WSN success

Power
wakeup
sleep
Time
11
Design Principles

• Key to Low Duty Cycle Operation
• Sleep majority of the time
• Wakeup quickly start processing
• Active minimize work return to sleep

12
Minimize Power Consumption

• Compare to Mica2 a MicaZ mote with AVR mcu and
  802.15.4 radio
• Sleep
• Majority of the time
• Telos 2.4mA
• MicaZ 30mA
• Wakeup
• As quickly as possible to process and return to
  sleep
• Telos 290ns typical, 6ms max
• MicaZ 60ms max internal oscillator, 4ms external
• Active
• Get your work done and get back to sleep
• Telos 4-8MHz 16-bit
• MicaZ 8MHz 8-bit

13
Power Consumption
14
Energy Consumption

• Idle listenreceivesend 11.051.4

15
TinyOS Radio Stack
16
Code and Data Size Breakdown
17
WSN Protocol Stack
Ref Introduction_1 A Survey on Sensor
Networks, IEEE Communications Magazine, Aug.
2002, pp. 102-114.
18
TinyOS 2

• An operating system for tiny, embedded, and
  networked sensors
• NesC language
• A dialect of C Language with extensions for
  components
• Three Limitations
• Application complexity
• High cost of porting to a new platform
• reliability
• Little more that a non-preemptive scheduler
• Component-based architecture
• Event-driven

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

19
TinyOS 2

• Static binding and allocation
• Every resource and service is bound at compile
  time and all allocation is static
• Single thread of control
• Non-blocking calls
• A call to start lengthy operation returns
  immediately
• the called component signals when the operation
  is complete
• Split phase
• See this link for one example http//docs.tinyos.n
  et/index.php/Modules_and_the_TinyOS_Execution_Mode
  l

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks
• Ref TinyOS_3 Section 2.1

20
TinyOS 2

• The scheduler has a fixed-length queue, FIFO
• Task run atomically
• Interrupt handlers can only call code that has
  the async keyword
• Complex interactions among components
• Event
• In most mote applications, execution is driven
  solely by timer events and the arrival of radio
  messages
• ATmega128 has two 8-bit timers and two 16-bit
  timers

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

21
TinyOS 2

• sync code is non-preemptive,
• when synchronous (sync) code starts running, it
  does not relinquish the CPU to other sync code
  until it completes
• Tasks
• enable components to perform general-purpose
  "background" processing in an application
• A function which a component tells TinyOS to run
  later, rather than now
• The post operation places the task on an internal
  task queue which is processed in FIFO order
• Tasks do not preempt each other
• A Task can be preempted by a hardware interrupt
• See TinyOS lesson
• Modules and the TinyOS Execution Model

22
802.15.4 and CC2420

• CC2420 hardware signals packet reception by
  triggering an interrupt
• The software stack is responsible for reading the
  received bytes out of CC2420s memory
• The software stack sends a packet by writing it
  to CC2420s memory then sending a transmit command

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

23
TinyOS 2

• Platforms
• MicaZ, Mica2, etc
• Compositions of chips
• Chips
• MCU, radio, etc
• Each chip follows the HAA model, with a HIL
  implementation at the top

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

24
TinyOS 2

• A T2 packet has a fixed size data payload which
  exists at a fixed offset
• The HIL of a data link stack is an active message
  interface
• Zero-copy

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

25
Scheduler in TinyOS 2.x

• SchedulerBasicP.nc of TinyOS 2.x

26
TinyOS Serial Stack

• Ref P. Levis, et al. T2 A Second Generation OS
  For Embedded Sensor Networks

27
Device Drivers in T2

• Virtualized
• Dedicated
• Shared

• Ref Section 3 of Energy_1

28
T2 Timer Subsystem

• MCU comes with a wide variation of hardware
  timers
• ATmega128 two 8-bit timers and two 16-bit times
• MSP430 two 16-bit timers
• Requirement of Timer subsystem
• Different sampling rates one per day to 10kHz

29
T2 Timer Subsystem

• See interface at
• tos/lib/timer/Timer.nc

30
One Example TinyOS Application - BlinkC

• http//docs.tinyos.net/index.php/TinyOS_Tutorials

31
One Example of Wiring

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

32
AppM

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

33
AppM

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

34
Sensor Interface

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

35
Initialize Interface

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

36
SensorC

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

37
AppC

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS

38
Notation
39
CTP Routing Stack
40
Parameterized Interfaces

• An interface array

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS, Section 2.3

41
unique and uniqueCount

• Want to use a single element of a parameterized
  interface and does not care which one, as long as
  no one else use it

• Want to know the number of different values
  returned by unique

• Ref D. Gay, et al. Software Design Patterns for
  TinyOS, Section 2.4

42
async

• Functions that can run preemptively are labeled
  with async keyword
• Command an async function calls and events an
  async function signals must be async
• All interrupt handlers are async
• atomic keyword
• Race conditions, data races

43
Generic Components and Typed Interface

• Have at least one type parameter
• Generic Components are NOT singletons
• Can be instantiated within an configuration
• Instantiated with the keyword new (Singleton
  components are just named)

44
Example - VirtualizeTimerC

• Use a single timer to create up to 255 virtual
  timers
• generic module VirtualizeTimerC(typedef
  precision_tag, int max_timers)
• Precision_tag A type indicating the precision of
  the Timer being virtualized
• max_timers Number of virtual timers to create.
• How to use it?
• Components new VirtualizeTimerC(TMilli, 3) as
  TimerA
• This will allocate three timers
• Components new VirtualizeTimerC(TMilli, 4) as
  TimerB
• This will allocate three timers
• Ref
• /tos/lib/timer/VirtualizeTimerC.nc
• Section 7.1 of TinyOS Programming Manual

45
Virtualized Timer
46
Timer Stack on MicaZ/Mica2
47
Timer Subsystem

• HplTimer0-3C provide dedicated access to the
  two 8-bit and two 16-bit timers of ATmega128 MCU
• T2 subsystem is built over the 8-bit timer 0
• Timer 1 is used for CC2420 radio

48
message_t

• tos/types/message.h
• Ref. TEP 111
• Every link layer defines its header, footer, and
  metadata structures

49
Relationship between CC1000 Radio Implementation
and message_t

• tos/chips/cc1000/CC1000Msg.h

50
Relationship between CC2420 Radio Implementation
and message_t

• tos/chips/cc2420/CC2420.h

51
Relationship between Serial Stack Packet
Implementation and message_t

• tinyos-2.x/tos/lib/serial/Serial.h

52
Active Message (AM)

• Why do we need AM?
• Because it is very common to have multiple
  services using the same radio to communicate
• AM layer to multiplex access to the radio
• make micaz install,n
• n unique identifier for a node

53
Active Message

• Every message contains the name of an event
  handler
• Sender
• Declaring buffer storage in a frame
• Naming a handler
• Requesting Transmission
• Done completion signal
• Receiver
• The event handler is fired automatically in a
  target node
• No blocked or waiting threads on the receiver
• Behaves like any other events
• Single buffering
• Double Check!!!!!!!

54
TinyOS Component

• Two types of components
• Module provide implementations of one or more
  interfaces
• Configuration assemble other components together

55
TinyOS Component Model

• Component has
• Frame (storage)
• Tasks computation
• Interface
• Command
• Event
• Frame static storage model - compile time memory
  allocation (efficiency)
• Command and events are function calls (efficiency)

56
Structure of a Component
Command Handlers
Set of Tasks
Event Handlers
Frame (containing state information)
TinyOS Component
57
TinyOS Two-level Scheduling

• Tasks do computations
• Non-preemptable FIFO scheduling
• Bounded number of pending tasks
• Events handle concurrent dataflows
• Interrupts trigger lowest level events
• Events prempt tasks, tasks do not
• Events can signal events, call commands, or post
  tasks

58
TinyOS Applications

• In most mote applications, execution is driven
  solely by timer events and the arrival of radio
  messages

59
How to Program motes Under TinyOS

• make telosb install,n mib510,/dev/ttyUSB0
• make telosb install,1 mib510,/dev/ttyUSB0

60
Representative WSN Applications

• BaseStation Listen BlinkToRadio
• One-hop WSN application to collect sensed values
• OscilloScope
• one-hop WSN application with GUI interface
• MultiOscilloScopre
• multihop WSN application
• Octopus
• multi-hop WSN application with a more dynamic
  display of network topology and data
  dissemination functions

61
Application Example - BaseStation, Listen and
BlinkToRadio
62
Application Example - Oscilloscope
63
Application Example - MultihopOscilloscope
64
Application Example - MViz
65
MViz
66
Application Example - Octopus

• http//csserver.ucd.ie/rjurdak/Octopus.htm

67
Octopus
68
BaseStation Listen - BlinkToRadio
69
OscilloScope
70
MultihopOscilloscope
71
MViz
72
Octopus
73
Class Project

• Group project
• Goal
• develop a multi-hop data collection tree protocol
  for WSNs
• Use the developed tree to collect light intensity
  information in Lab 209
• Collaboration is important