Energy Management in TinyOS 2

Learning Objectives

• Understand the basic ideas of Integrated Concurrency and Energy Management (ICEM)

• Understand representative ICEM examples in TinyOS 2

Prerequisites

• Module 2

• Basic concepts of Operating Systems

• Basic concepts of Object-oriented Design and Analysis

[Energy_1] 4

Motivation

• If the application must explicitly invoke power control operations, this will introduce application code complexity

• Let the OS automatically minimize energy consumption - Integrated Concurrency and Energy Management (ICEM)

ICEM (Integrated Concurrency and Energy Management)

• Most WSN OS are completely event-driven• Diverse peripherals• An application simply needs to make a set of asynchronous

system calls and let OS schedule the underlying operations• Power locks

– When a client acquires a driver’s power lock: ICEM has powered and configured the hardware for the client

– When a power lock is idle, ICEM powers down the underlying hardware

Example Implementations in T2

• Lock Interface is named Resource in T2

• Arbiter Configure Interface is named ResourceConfigure in T2

• DefaultOwner Interface is named ResourceDefaultOwner in T2

Example Applications based on TelosB

• Every five minutes, the application samples four sensors (photo active, total solar, temperature, and humidity) and logs the readings in flash with a sequence number

• Every twelve hours, the application retrieves new readings from the flash and sends them to the gateway

• Five Operations– Sampe its four sensors– Log the record to flash

Motivation Example – Pseudocode for hand-tuned implementation without ICEM

TelosB

Five Operations

• Humidity and Temperature are digital sensors

• Total Solar and Photo Active are analog sensors

• The OS can concurrently sample one digital and one analog sensor

• The OS must arbitrate sensors of the same kind

also see TEP 108 at http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/

html/tep108.html

11

ICEM Drivers – Resource Arbitration

• Virtualized– Simplest for a client to use– Virtualized drivers buffer client requests– Provide implicit concurrency– Usually buffer functional requests (e.g. send a packet)

• Dedicated– Support a single user

• Shared– Provide explicit concurrency– Support multiple users, but users must contend for the

driver through a lock– Usually buffer lock requests

ICME Drivers - Virtualized

• Oval: Client• Example:

– Data Link Packet Sender• Round Robin policy

– Application-level millisecond timers

– Application-level millisecond timers

• Maintain per-client state

• Schedule underlying hardware timer

Virtualized Example

• ADC (Analog-Digital-Converter)– A shared resource usually multiplexed between

several clients– AdcReadClientC.nc, AdcReadNowClientC.nc and

AdcReadStreamClientC.nc provide virtualized access to the HIL

– AdcReadClientC.nc: tos/chips/msp430/adc12/AdcReadClientC.nc

ICME Drivers - Dedicated

• Low-level hardware resources

• Examples– GPIO Pins

ICME Drivers - Shared

CC2420 Stack

Arbiters

• Lock: Resource in T2

• Arbiter Configure: ResourceConfigure

• DefaultOwner: ResourceDefaultOwner

Atmegal 128 ADC

MTS300 Sensor Boards

Assignment

• 1. What is the difference between virtualized and shared access in TinyOS 2?

• 2. Please use examples to explain what are virtualized, dedicated, and shared accesses in TinyOS 2.

• 3. How are virtualized, dedicated, and shared mechanisms implemented in TinyOS 2?