introduction to tinyos. networking open experimental platform small microcontroller 8 kb code 512 b...
Post on 21-Dec-2015
216 views
TRANSCRIPT
Introduction to TinyOS
Networking
Open Experimental Platform
Small microcontroller 8 kB code 512 B data
Simple, low-power radio 10 kbps ASK
EEPROM (32 KB)
Simple sensors
WeC 99“Smart Rock”
Mica 1/02
NEST open exp. Platform128 kB code, 4 kB data40kbps OOK/ASK radio512 kB Flash
Rene 11/00
Designed for experimentation
-sensor boards
-power boards
TinyOS
Services
Dot 9/01
Demonstrate scale
Spec 6/03“Mote on a chip”
Telos 4/04RobustLow Power250kbpsEasy to use
Mica2 12/0238.4kbps radioFSK
Commercial Off The Shelf Components (COTS)
Reminder
• watt = voltage * amphere– Unit of power
• joule = watt * second– Unit of energy
Faster, Smaller, Numerous
• Moore’s Law– “Stuff” (transistors, etc)
doubling every 1-2 years
• Bell’s Law– New computing class every
10 years
year
log
(p
eo
ple
pe
r c
om
pu
ter)
Streaming Data to/from the
Physical World
Source: HotChips 2004
Mote Evolution
Source: HotChips 2004
Design Principles
• Key to Low Duty Cycle Operation:– Sleep – majority of the time– Wakeup – quickly start processing– Active – minimize work & return to sleep
Source: HotChips 2004
Sleep
• Majority of time, node is asleep– >99%
• Minimize sleep current through– Isolating and shutting down individual circuits– Using low power hardware
• Need RAM retention
• Run auxiliary hardware components from low speed oscillators (typically 32kHz)– Perform ADC conversions, DMA transfers, and bus
operations while microcontroller core is stopped
Source: HotChips 2004
• Overhead of switching from Sleep to Active Mode
Wakeup
• Microcontroller • Radio (FSK)
10ns – 4ms typical1– 10 ms typical
2.5 ms
292 ns
Source: HotChips 2004
Active• Microcontroller
– Fast processing, low active power
– Avoid external oscillators
• Radio– High data rate, low power
tradeoffs– Narrowband radios
• Low power, lower data rate, simple channel encoding, faster startup
– Wideband radios• More robust to noise, higher
power, high data rates
• External Flash (stable storage)– Data logging, network code
reprogramming, aggregation– High power consumption– Long writes
• Radio vs. Flash– 250kbps radio sending 1 byte
• Energy : 1.5J• Duration : 32s
– Atmel flash writing 1 byte• Energy : 3J• Duration : 78s
Source: HotChips 2004
• Mica2 (AVR)– 0.2 ms wakeup
– 30 W sleep
– 33 mW active
– 19 kbps
• 2/3 of AA capacity
– 2.5V min
Power Calculation ComparisonDesign for low power
• MicaZ (AVR)– 0.2 ms wakeup
– 30 W sleep
– 33 mW active
– 250 kbps
– 2.5V min
• 2/3 of AA capacity
• Telos (TI MSP)– 0.006 ms wakeup
– 2 W sleep
– 3 mW active
– 250 kbps
– 1.8V min
• 8/8 of AA capacity
Report data once every 3 minutes with two AA batteries (<1% duty cycle)
328 days 945 days453 days
Software challenges
• Power efficiency• Small memory footprint• Application specific• Modularity• Concurrency-intensive operations
– Multiple, high-rate data flows (radio, sensor, actuator)
• Real-time– Real-time query and feedback control of physical world– Little memory for buffering: Data must be processed on the fly– TinyOS: No buffering in radio hw: deadline miss data loss– TinyOS provides NO real-time guarantees!– EDF (Earliest Deadline First) scheduling supported in TinyOS 2.x
• http://www.tinyos.net/tinyos-2.x/doc/html/tep106.html• Perfect???
“General-Purpose” OS?
MANY functionalities & programming APIs• Protection between “untrusted” applications
and kernel– Overhead for crossing kernel/user boundary & interrupt
handling
• Multi-threaded architecture– Large number of threads large memory– Context switch overhead
• I/O model– Blocking I/O: waste memory on blocked threads– Polling: waste CPU cycles and power
• Need a new OS architecture!
TinyOS Overview• Application = scheduler + graph of components
– Compiled into one executable
• Event-driven architecture• Single shared stack• No kernel/user space differentiation
CommunicationActuating Sensing Communication
Application (User Components)
Main (includes Scheduler)
Hardware Abstractions
Traditional OS Architectures
Problems
• Large memory & storage requirement
• Unnecessary and overkill functionality
• Address space isolation, complex I/O subsystem, UI
• Relative high system overhead, e.g, context switch
• Require complex and power consuming hardware support
VM I/O Scheduler
Application 1 Application 2
Monolithic kernel
HW
NFS I/O
Scheduler
Application 1
Micro-kernel
HW
IPC VM
Desirable OS architecture
• Extremely small footprint
• Extremely low system overhead
• Extremely low power consumption
NO Kernel Direct hardware manipulationNO Process management Only one process on the flyNO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile timeNO Software signal or exception Function call
Goal: to strip down memory size and system overhead.
TinyOS Architecture Overview
I/O COMM . …….
Scheduler TinyOS
Application Component
Application Component
Application Component
TinyOS Architecture Overview
• Characteristics of TinyOS– No UI, power constrained– Application specific HW and SW– Multiple flows, concurrent bursts– Extremely passive vigilance (power saving )– Tightly coupled with the application
Mote Hardware
Actuating Sensing
Simplified
TinyOS
ArchitectureActive Message
Communication
Application (User Components)
Main (includes Scheduler)
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)
Messaging Component
Internal StateInternal Tasks
Commands Events
An Example Application
RFM
Radio byte (MAC)
Radio Packet
i2c
Tempphoto
Messaging Layer
clocksbit
byte
packet
Routing Layer
sensing applicationapplication
HW
SW
ADC
messaging
routing
TinyOS Two-level Scheduling
• Tasks do computations– Non-preemptive FIFO scheduling– Bounded number of pending tasks
• Events handle concurrent dataflows– Interrupts trigger lowest level events
– Events preempt tasks, tasks do not– Events can signal events, call commands, or post tasks
Hardware
Interrupts
eve
nts
commands
FIFO
TasksPOST
Preempt
Time
commands
Two-Level Scheduling• Event and Task
– Tasks cannot preempt other tasks– Single shared stack
• Used by both interrupts and function calls
– Simple FIFO scheduler – Events can preempt a task– Events can preempt each other– When idle, scheduler shuts down the node
except for clock
Event implementation Event is independent of FIFO scheduler. • Lowest level events are supported directly by
Hardware interrupt • Software events propagate from lower level to
upper level through function call
How to handle multiple data flows?
• Data are handled by– A sequence of non-blocking event/command (function calls)
through the component graph– Post tasks for computations that are not “emergent”
• Preempting tasks to handle new data
How should network msg be handled?
• Socket/TCP/IP?– Too much memory for buffering and threads
• Data are buffered until application threads read it• Application threads blocked until data is available
– Transmit too many bits (sequence #, ack, re-transmission)
– Tied with multi-threaded architecture
• TinyOS solution: Active Messages
Active Message• Every message contains the name of an event
handler• Sender
– Declare buffer storage in a frame– Name a handler– Request Transmission– Done - completion signal
• Receiver– The corresponding event handler invoked
No blocked or waiting threads on the receiver Behaves like any other events Single buffering
Analysis and Evaluation
• Space, Power and Time
Code and Data Size Breakdown
Scheduler: 178 Bytes codeTotals: 3450 Bytes code
226 Bytes data
Time Breakdown
Time Breakdown
Total propagation delay: 40 us (80 instructions)
Power Breakdown…
Evaluation of TinyOS
• Small memory footprint– Non-preemptable FIFO task scheduling
• Power efficient – Put microcontroller and radio to sleep
• Efficient modularity – Function call (event, command) interface between components
• Concurrency-intensive operations – Event-driven architecture– Efficient interrupts/events handling (function calls, no user/kernel
boundary)
• Real-time – Non-preemptable FIFO task scheduling– No real-time guarantees or overload protection
What should be added to TinyOS?
• Priority- & deadline-driven scheduling?– RM? EDF?– Appropriate for data-centric applications?– How to deal with multiple resources, e.g., CPU &
wireless bandwidth? Extend RM or EDF?• End-to-end timing guarantees?• Reliable synchronization mechanism?• Internet or large scale service infrastructure?
– Interoperability?– Protocols?
• TCP/IP, UDP, RTP?
• …