This chapter shows how to build a PC application that talks to motes. As we saw in Section 6.4, a PC typically interacts with a mote network by exchanging packets with a distinguished base station mote (occasionally, several motes) over a serial connection (Figure 6.2, page 95). The PC code in this chapter is written in Java, using the Java libraries and tools distributed with TinyOS. TinyOS also includes libraries and tool support for other languages (e.g. C). Please refer to the TinyOS documentation for more information on these other languages. The TinyOS Java code for communicating with motes is found under the net.tinyos package.

Basics

At the most basic level, PCs and motes exchange packets that are simply sequences of bytes, using a protocol inspired by, but not identical to, RFC 1663 [24] (more details on the protocol can be found in TEP 113 [7]). This packet exchange is not fully reliable: the integrity of packets is ensured by the use of a CRC, but invalid packets are simply dropped. Furthermore:

• Packets sent from a PC to a mote are acknowledged by the mote (but there is no retry if no acknowledge is received) – this prevents the PC from overloading the mote with packets.

• Packets sent from a mote to a PC are not acknowledged.

While it is possible to write mote communication code by reading and writing the raw bytes in packets, this approach is tedious and error-prone. Furthermore, any changes to the packet layout (e.g. adding a new field, changing the value of a constant used in the packets) requires corresponding changes throughout the code.

By their very nature, sensor network applications are often platform-specific: the application uses a particular set of sensors on a mote-specific sensor board, to measure application-specific conditions. The hardware, and hence the application, is typically not directly reusable on another mote platform. Furthermore, some applications may want to push a mote platform to its limits, e.g. to maximize sampling rate, or minimize the latency in reacting to an external event. Getting to these limits normally requires extensive platform-specific tuning, including platform-specific code (possibly even written in assembly language).

Conversely, large portions of sensor network applications are portable: multi-hop network protocols, radio stacks for commonly available radio chips, signal processing, etc. need little or no change for a new platform. Thus, while a sensor network application is not typically directly portable, TinyOS should make it easy to port applications to new platforms by minimizing the extent of the necessary changes.

Portability and the hardware abstraction architecture

TinyOS's main tool to maximize portability while maintaining easy access to platform-specific features is a multi-level hardware abstraction architecture (HAA), shown in Figure 12.1. The device driver components that give access to a mote's various hardware resources are divided into three categories:

• The hardware interface layer (HIL): a device driver is part of the HIL if it provides access to a device (radio, storage, timers, etc.) in a platform-independent way, using only hardware independent interfaces.

• […]

This chapter presents TinyOS 's execution model, which is based on split-phase operations, run-to-completion tasks and interrupt handlers. Chapter 3 introduced components and modules, Chapter 4 introduced how to connect components together through wiring. This chapter goes into how these components execute, and how you can manage the concurrency between them in order to keep a system responsive. This chapter focuses on tasks, the basic concurrency mechanism in nesC and TinyOS. We defer discussion of concurrency issues relating to interrupt handlers and resource sharing to Chapter 11, as these typically only arise in very high-performance applications and low-level drivers.

Overview

As we saw in Section 3.4, all TinyOS I/O (and long-running) operations are split-phase, avoiding the need for threads and allowing TinyOS programs to execute on a single stack. In place of threads, all code in a TinyOS program is executed either by a task or an interrupt handler. A task is in effect a lightweight deferred procedure call: a task can be posted at anytime and posted tasks are executed later, one-at-a-time, by the TinyOS scheduler. Interrupts, in contrast can occur at any time, interrupting tasks or other interrupt handlers (except when interrupts are disabled).

While a task or interrupt handler is declared within a particular module, its execution may cross component boundaries when it calls a command or signals an event (Figure 5.1).As a result, it isn't always immediately clear whether a piece of code is only executed by tasks or if it can also be executed from an interrupt handler.

This chapter describes components, the building blocks of nesC programs. Every component has a signature, which describes the functions it needs to call as well as the functions that others can call on it. A component declares its signature with interfaces, which are sets of functions for a complete service or abstraction. Modules are components that implement and call functions in C-like code. Configurations connect components into larger abstractions. This chapter focuses on modules, and covers configurations only well enough to modify and extend existing applications: Chapter 4 covers writing new configurations from scratch.

Component signatures

A nesC program is a collection of components. Every component is in its own source file, and there is a one-to-one mapping between component and source file names. For example, the file LedsC.nc contains the nesC code for the component LedsC, while the component PowerupC can be found in the file PowerupC.nc. Components in nesC reside in a global namespace: there is only one PowerupC definition, and so the nesC compiler loads only one file named PowerupC.nc.

There are two kinds of components: modules and configurations. Modules and configurations can be used interchangeably when combining components into larger services or abstractions. The two types of components differ in their implementation sections. Module implementation sections consist of nesC code that looks like C. Module code declares variables and functions, calls functions, and compiles to assembly code. Configuration implementation sections consist of nesC wiring code, which connects components together. Configurations are the major difference between nesC and C (and other C derivatives).

In this chapter, we look at the design and implementation of SoundLocalizer, a somewhat more complex sensor network application. SoundLocalizer implements a coordinated event detection system where a group of motes detect a particular event – a loud sound – and then communicate amongst themselves to figure out which mote detected the event first and is therefore presumed closest to where the event occurs. To ensure timely event detection, and accurately compare event detection times, this application needs to use some low-level interfaces from the platform's hardware abstraction and hardware presentation layers (HAL, HPL, as described in the previous chapter). As a result, this application is not directly portable – we implement it here for micaz motes with an mts300 sensor board. In the design and implementation descriptions below, we discuss how the application and code are designed to simplify portability and briefly describe what would be involved in porting this application to another platform.

The HAL and HPL components used by SoundLocalizer offer lower-level interfaces (interrupt-driven, controlled by a Resource interface, etc.) than the high-level HIL components we used to build the AntiTheft application of Chapter 6. As a result, SoundLocalizer's implementation must use atomic statements and arbitration to prevent concurrency-induced problems, as we saw in Chapter 11.

The complete code for SoundLocalizer is available from TinyOS's contributed code directory (under “TinyOS Programming”).

Sound Localizer design

Figure 13.1 shows a typical setup for the SoundLocalizer application. A number of detector motes are placed on a surface a couple of feet apart. When the single coordinator mote is switched on, it sends a series of radio packets that let the detector motes synchronize their clocks.

This book is about writing TinyOS systems and applications in the nesC language. This chapter gives a brief overview of TinyOS and its intended uses. TinyOS is an open-source project which a large number of research universities and companies contribute to. The main TinyOS website, www.tinyos.net, has instructions for downloading and installing the TinyOS programming environment. The website has a great deal of useful information which this book doesn't cover, such as common hardware platforms and how to install code on a node.

Networked, embedded sensors

TinyOS is designed to run on small, wireless sensors. Networks of these sensors have the potential to revolutionize a wide range of disciplines, fields, and technologies. Recent example uses of these devices include:

Golden Gate Bridge safety High-speed accelerometers collect synchonizedd ata on the movement of and oscillations within the structure of San Francisco's Golden Gate Bridge. This data allows the maintainers of the bridge to easily observe the structural health of the bridge in response to events such as high winds or traffic, as well as quickly assess possible damage after an earthquake [10]. Being wireless avoids the need for installing and maintaining miles of wires.

Volcanic monitoring Accelerometers and microphones observe seismic events on the Reventador and Tungurahua volcanoes in Ecuador. Nodes locally compare when they observe events to determine their location, and report aggregate data to a camp several kilometers away using a long-range wireless link. Small, wireless nodes allow geologists and geophysicists to install dense, remote scientific instruments [30], obtaining data that answers other questions about unapproachable environments.

To quote the Gang of Four, design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” [3] In the components we've seen so far, we see several recurring patterns, such as the use of parameterized interfaces to implement services with multiple clients (VirtualizeTimerC, Section 9.1.3), or one component wrapping another (RandomC, Section 4.2). In this chapter, in the spirit of the Gang of Four's original design patterns work, we attempt to formalize a number of these patterns, based on our observations during TinyOS's development.

This chapter presents eight nesC design patterns: three behavioral (relating to component interaction): Dispatcher, Decorator, and Adapter, three structural (relating to how applications are structured): Service Instance, Placeholder, and Facade and two namespace (management of identifiers such as message types): Keyspace and Keymap. Each pattern's presentation follows the model of the Design Patterns book. Each one has an Intent, which briefly describes its purpose. A more in-depth Motivation follows, providing an example drawn from TinyOS. Applicable When provides a succinct list of conditions for use and a component diagram shows the Structure of how components in the pattern interact.1 In addition to our usual conventions for component diagrams, we attach folded sub-boxes to components to show relevant code snippets (a floating folded box represents source code in some other, unnamed, component). The diagram is followed by a Participants list explaining the role of each component. Sample Code shows an example nesC implementation, and Known Uses points to some uses of the pattern in TinyOS. Consequences describes how the pattern achieves its goals, and notes issues to consider when using it.