Tiny OS Software Challenges Tiny OS Power efficient

Tiny. OS

Software Challenges - Tiny. OS • 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 http: //www. tinyos. net 2

Tiny. OS Hardware Abstraction Architecture (HAA) • Section 2. 3 and Figure 2. 5 of J. Polastre Dissertation: http: //www. polastre. com/papers/polastre-thesis-final. pdf [Tiny. OS_1]: Table 2 3

Tiny. OS Hardware Abstraction Architecture (HAA) Ref: Figure 2. 4 of J. Polastre Dissertation http: //www. polastre. com/papers/polastre-thesis-final. pdf

Traditional OS Architectures Application 2 Application 1 I/O Micro-kernel Monolith-kernel VM NFS Application 1 Scheduler IPC HW Scheduler HW 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. VM

Tiny. OS Architecture Overview (1) Scheduler Application Component I/O Application Component COMM. Tiny. OS Application Component ……. 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.

Tiny. OS 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 Communication Sensing Communication Hardware Abstractions

Tiny. OS Component Model • Component has: – Frame (storage) – Tasks: computation – Interface: • Command • Event Messaging Component Internal Tasks Commands Internal State Events • Frame: static storage model - compile time memory allocation (efficiency) • Command events are function calls (efficiency) [Tiny. OS_4] 8

Typical WSN Application processing data acquisition communication • Periodic – Data Collection – Network Maintenance – Majority of operation • Triggered Events • Long Lifetime – Months to Years without changing batteries – Power management is the key to WSN success wakeup • But… must be reported quickly and reliably Power – Detection/Notification – Infrequently occurs sleep The mote revolution: Low Powr Wireless Sensor Network Time 10

Design Principles • Key to Low Duty Cycle Operation: – Sleep – majority of the time – Wakeup – quickly start processing – Active – minimize work & return to sleep The mote revolution: Low Powr Wireless Sensor Network 11

Minimize Power Consumption • Compare to Mica 2: a Mica. Z mote with AVR mcu and 802. 15. 4 radio • Sleep – Majority of the time – Telos: 2. 4 m. A – Mica. Z: 30 m. A • Wakeup – As quickly as possible to process and return to sleep – Telos: 290 ns typical, 6 ms max – Mica. Z: 60 ms max internal oscillator, 4 ms external • Active – Get your work done and get back to sleep – Telos: 4 -8 MHz 16 -bit – Mica. Z: 8 MHz 8 -bit The mote revolution: Low Powr Wireless Sensor Network 12

Power Consumption

Energy Consumption • Idle listen: receive: send = 1: 1. 05: 1. 4

Tiny. OS Radio Stack [Introduction_2]: Figure 3 15

Code and Data Size Breakdown [Introduction_2]: Table 2 16

WSN Protocol Stack Ref: [Introduction_1] “A Survey on Sensor Networks, ” IEEE Communications Magazine, Aug. 2002, pp. 102 -114.

Tiny. OS 2 • An operating system for tiny, embedded, and networked sensors • Nes. C 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. “T 2: A Second Generation OS For Embedded Sensor Networks”

Tiny. OS 2 • Static binding and allocation – Every resource and service is bound at compile time and 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. net/index. php/Modules_and_the_Tiny. OS _Execution_Model • • Ref: P. Levis, et al. “T 2: A Second Generation OS For Embedded Sensor Networks” Ref: [Tiny. OS_3] Section 2. 1

Tiny. OS 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 • ATmega 128 has two 8 -bit timers and two 16 -bit timers • Ref: P. Levis, et al. “T 2: A Second Generation OS For Embedded Sensor Networks”

Tiny. OS 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 Tiny. OS 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 Tiny. OS lesson: – Modules and the Tiny. OS Execution Model

802. 15. 4 and CC 2420 • CC 2420 hardware signals packet reception by triggering an interrupt • The software stack is responsible for reading the received bytes out of CC 2420’s memory; • The software stack sends a packet by writing it to CC 2420’s memory then sending a transmit command • Ref: P. Levis, et al. “T 2: A Second Generation OS For Embedded Sensor Networks”

Tiny. OS 2 • Platforms – Mica. Z, Mica 2, 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. “T 2: A Second Generation OS For Embedded Sensor Networks”

Tiny. OS 2 • A T 2 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. “T 2: A Second Generation OS For Embedded Sensor Networks”

Scheduler in Tiny. OS 2. x Scheduler. Basic. P. nc of Tiny. OS 2. x

Tiny. OS Serial Stack • Ref: P. Levis, et al. “T 2: A Second Generation OS For Embedded Sensor Networks”

Device Drivers in T 2 • Virtualized • Dedicated • Shared • Ref: Section 3 of [Energy_1]

T 2 Timer Subsystem • MCU comes with a wide variation of hardware timers – ATmega 128: two 8 -bit timers and two 16 -bit times – MSP 430: two 16 -bit timers • Requirement of Timer subsystem – Different sampling rates: one per day to 10 k. Hz [Tiny. OS_1]: Section 5 28

T 2 Timer Subsystem • See interface at: – tos/lib/timer/Timer. nc

One Example Tiny. OS Application Blink. C • http: //docs. tinyos. net/index. php/Tiny. OS_Tutor ials

One Example of Wiring • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

App. M • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

App. M • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

Sensor Interface • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

Initialize Interface • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

Sensor. C • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

App. C • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”

Notation

CTP Routing Stack

Parameterized Interfaces • An interface array • Ref: D. Gay, et al. “Software Design Patterns for Tiny. OS”, Section 2. 3

unique and unique. Count • 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 Tiny. OS”, Section 2. 4

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 section 4. 5 "Tiny. OS Programming manual" 42

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)

Example - Virtualize. Timer. C • Use a single timer to create up to 255 virtual timers • generic module Virtualize. Timer. C(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 Virtualize. Timer. C(TMilli, 3) as Timer. A • This will allocate three timers – Components new Virtualize. Timer. C(TMilli, 4) as Timer. B • This will allocate three timers • Ref: – /tos/lib/timer/Virtualize. Timer. C. nc – Section 7. 1 of “Tiny. OS Programming Manual” /tos/lib/timer/Virtualize. Timer. C. n 44

Virtualized Timer

Timer Stack on Mica. Z/Mica 2 Figure 4 of [Tiny. OS_1] 46

Timer Subsystem • Hpl. Timer[0 -3]C provide dedicated access to the two 8 -bit and two 16 -bit timers of ATmega 128 MCU • T 2 subsystem is built over the 8 -bit timer 0 • Timer 1 is used for CC 2420 radio

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

Relationship between CC 1000 Radio Implementation and message_t • tos/chips/cc 1000/CC 1000 Msg. h

Relationship between CC 2420 Radio Implementation and message_t • tos/chips/cc 2420/CC 2420. h

Relationship between Serial Stack Packet Implementation and message_t • tinyos-2. x/tos/lib/serial/Serial. h

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

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!!!!!!!

Tiny. OS Component • Two types of components – Module: provide implementations of one or more interfaces – Configuration: assemble other components together

Tiny. OS Component Model • Component has: – Frame (storage) – Tasks: computation – Interface: • Command • Event Messaging Component Internal Tasks Commands • Frame: static storage model - compile time memory allocation (efficiency) • Command events are function calls (efficiency) Internal State Events

Structure of a Component Command Handlers Set of Tasks Event Handlers Frame (containing state information) Tiny. OS Component

Tiny. OS 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 Tasks Preempt events POST FIFO commands Interrupts Hardware Time

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

How to Program motes Under Tiny. OS • make telosb install, n mib 510, /dev/tty. USB 0 • make telosb install, 1 mib 510, /dev/tty. USB 0

Representative WSN Applications • Base. Station – Listen – Blink. To. Radio – One-hop WSN application to collect sensed values • Oscillo. Scope – one-hop WSN application with GUI interface • Multi. Oscillo. Scopre – multihop WSN application • Octopus – multi-hop WSN application with a more dynamic display of network topology and data dissemination functions

Application Example - Base. Station, Listen and Blink. To. Radio

Application Example - Oscilloscope

Application Example Multihop. Oscilloscope

Application Example - MViz

MViz

Application Example - Octopus • http: //csserver. ucd. ie/~rjurdak/Octopus. htm

Octopus

Base. Station – Listen - Blink. To. Radio

Oscillo. Scope

Multihop. Oscilloscope

MViz

Octopus

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