Energy Management in TinyOS 2

1. Energy Management in TinyOS 2

2. Learning Objectives • Understand the basic ideas of Integrated Concurrency and Energy Management (ICEM) • Understand representive ICEM examples in TinyOS 2

3. Prerequisites • Basic concepts of Operating Systems • Basic concepts of Object-oriented design and analysis

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) [Energy_1]

5. 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

6. 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

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

8. Motivation Example – Pseudocode for hand-tuned implementation without ICEM

9. TelosB

10. 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

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 also see TEP 108 at http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep108.html

12. 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

13. 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

14. ICME Drivers - Dedicated • Low-level hardware resources • Examples • GPIO Pins

15. ICME Drivers - Shared

16. CC2420 Stack

17. Arbiters • Lock: Resource in T2 • Arbiter Configure: ResourceConfigure • DefaultOwner: ResourceDefaultOwner

18. Atmegal 128 ADC

19. MTS300 Sensor Boards