Software Issues in Wireless Sensor Networks - Application and Multidisciplinary Aspects of Wireless Sensor Networks - page 32

node, some compromises are required, most notably the need to conserve energy
resources by providing an implicitly energy-efficient programming model.
The first obstacle we have to overcome when using this approach is to choose
the right operating system for the sensor node. All conventional OSes for embedded
systems (such as Windows CE or PalmOS) require a ROM capacity of a 100 kb or
more; sensor nodes, however, typically have only a few kilobytes. The most popular
solution today is the TinyOS, developed by U.C. Berkeley. Another option is the
Java Squawk virtual machine, developed by Sun Microsystems for their Sun SPOT
project.

3.2.1 The TinyOS Operating System

In order to facilitate the “scaled traditional” approach, a specialized operating sys-
tem had to be devised; one that would provide the necessary primitives to operate
the sensor node hardware, but would also cope with the quite limited resources of
a sensor node. These limitations include

• Not enough memory for stack . All TinyOS programs have to operate within a
single context, as it is impossible to perform traditional context switching, due
to a very small amount of memory available for stack. This also means that
TinyOS programs cannot rely on registers to save state.
• Limited amount of memory . This means that what available memory there is
has to be allocated carefully. Dynamic allocation of memory is prohibited; the
TinyOS components are arranged into a configuration at compile-time, and indi-
vidual components each get their preassigned portion of memory, the memory
frame.
• Limited amount of energy . Special care is taken to ensure that the battery power
is conserved as much as possible. Busy waiting and interrupt polling is prohibited
in all TinyOS compatible devices. TinyOS programs execute only in response to
events ; this is called the event-driven programming model.

3.2.1.1 TinyOS Component Model

To address these issues, the TinyOS Component Model was devised [ 1 ]. The parts of
code in this model are organized into distinct entities based on functionality. For
example, there may be an entity for operating the integrated radio-transceiver unit. (In
fact, there is such an entity in TinyOS, the rfm system component.) These entities are
associated with a statically allocated memory portion (called memory frame) and
interconnected with other such entities through interfaces. Such completely described
entities are called components (Fig. 3.2 ) .
The memory frame is allocated at compile-time, based on total memory require-
ments of the component.