message layer as ActiveMessageC, while the TMote defines the CC2420
active message layer as ActiveMessageC.

There is no longer a TOS_UART_ADDRESS for active message
communication.  Instead, a component should wire to
SerialActiveMessageC, which provides active message communication over
the serial port.

Active message communication is virtualized through four generic 
components, which take the AM type as a parameter: AMSenderC, 
AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is
virtualized in that the call to send() does not fail if some
other component is sending (as it does with GenericComm in 1.x). Instead,
it fails only if that particular AMSenderC already has a packet
outstanding or if the radio is not in a sending state. Underneath,
the active message system queues and sends these outstanding packets.
This is different than the QueuedSendC approach of 1.x, in which there
is an N-deep queue that is shared among all senders. With N AMSenderC 
components, there is an N-deep queue where each sender has a single
reserved entry. This means that each AMSenderC receives 
1/n of the available post-MAC transmission opportunities,  where
n is the number of AMSenderC components with outstanding packets.
In the worst case, n is the number of components; even when every
protocol and component that sends packets is trying to send a packet,
each one will receive its fair share of transmission opportunities.

Further information on message_t can be found in TEP 111:
message_t[TEP111_], while further information on AM can be
found in TEP 116: Packet Protocols[TEP116_].

The current TinyOS release has a low-power stack for the CC1000
radio (mica2 platform) and an experimental low-power stack for
the CC2420 radio (micaz, telosb, and intelmote2 platforms). 


8. Sensors
====================================================================

In TinyOS 2.0, named sensor components comprise the HIL of a
platform's sensors. TEP 114 describes a set of HIL data acquisition
interfaces, such as Read, ReadStream, and Get, which sensors
provide according to their acquisition capabilities.

If a component needs
high-frequency or very accurate sampling, it must use the HAL, which
gives it the full power of the underlying platform (highly accurate
platform-independent sampling is not really feasible, due to the
particulars of individual platforms). ``Read`` assumes that the
request can tolerate some latencies (for example, it might schedule
competing requests using a FIFO policy). 

Details on the ADC subsystem can be found in
TEP 101: Analog-to-Digital Converters[TEP101_]; details on
the organization of sensor boards can be found in TEP 109:
Sensorboards[TEP109_], and the details of the HIL sensor interfaces
can be found in TEP 114: Source and Sink Independent Drivers[TEP114_].


9. Error Codes
====================================================================

The standard TinyOS 1.x return code is ``result_t``, whose value is
either SUCCESS (a non-zero value) or FAIL (a zero value). While this
makes conditionals on calls very easy to write (e.g., ``if (call
A.b())``), it does not allow the callee to distinguish causes of error
to the caller. In TinyOS 2.0, ``result_t`` is replaced by ``error_t``,
whose values include SUCCESS, FAIL, EBUSY, and ECANCEL. Interface
commands and events define which error codes they may return and why.

From the perspective of porting code, this is the most significant
different in 2.0. Calls that were once::

  if (call X.y()) {
    busy = TRUE;  
  }


now have their meanings reversed. In 1.x, the busy statement will execute
if the call succeeds, while in 2.0 it will execute if the call fails.
This encourages a more portable, upgradable, and readable approach::

  if (call X.y() == SUCCESS) {
    busy = TRUE;
  }

10. Arbitration
====================================================================

While basic abstractions, such as packet communication and timers,
can be virtualized, experiences with 1.x showed that some cannot 
without either adding significant complexity or limiting the system.
The most pressing example of this is a shared bus on a microcontroller.
Many different systems -- sensors, storage, the radio -- might need
to use the bus at the same time, so some way of arbitrating access
is needed. 

To support these kinds of abstractions, TinyOS 2.0 introduces 
the Resource interface, which components use to request and
acquire shared resources, and arbiters, which provide a policy for 
arbitrating access between multiple clients. For some abstractions,
the arbiter also provides a power management policy, as it can tell
when the system is no longer needed and can be safely turned off.

TEP 108: Resource Arbitration[TEP108_] describes the Resource interface
and how arbiters work.

11. Power Management
====================================================================

Power management in 2.0 is divided into two parts: the power state
of the microcontroller and the power state of devices. The former,
discussed in TEP 112: Microcontroller Power Management[TEP112_],
is computed in a chip-specific manner by examining which devices 
and interrupt souces are active. The latter, discussed in
TEP 115: Power Management of Non-Virtualised Devices{TEP115_], is handled
through resource abiters. Fully virtualized services have their
own, individual power management policies.

TinyOS 2.0 provides low-power stacks for the CC1000 (mica2)
and CC2420 (micaz, telosb, imote2) radios. Both use a low-power
listening apporach, where transmitters send long preambles or
repeatedly send packets and receivers wake up periodically to 
sense the channel to hear if there is a packet being 
transmitted. The low-power stack CC1000 is standard, while
the CC2420 stack is experimental. That is, the default CC1000
stack (chips/cc1000) has low-power-listening, while the default 
CC2420 stack (chips/cc2420) does not. To use the low-power CC2420
stack, you must include chips/cc2420_lpl in your application Makefile.

12. Network Protocols
====================================================================

TinyOS 2.0 provides simple reference implementations of two of 
the most basic protocols used in mote networks: dissemination
and collection. Dissemination reliably delivers small (fewer 
than 20 byte) data items to every node in a network, while
collection builds a routing tree rooted at a sink node. Together,
these two protocols enable a wide range of data collection
applications. Collection has advanced significantly since the
most recent beta release; experimental tests in multiple 
network conditions have seen very high (>98%) deliver rates
as long as the network is not saturated.

13. Conclusion
====================================================================

TinyOS 2.0 represents the next step of TinyOS development. Building on
user experiences over the past few years, it has taken the basic
TinyOS architecture and pushed it forward in several directions,
hopefully leading to simpler and easier application development. It is
still under active development: future prereleases will include
non-volatile storage, basic multihop protocols (collection routing,
dissemination), and further power management abstractions.

14. Acknowledgments
====================================================================

TinyOS 2.0 is the result of a lot of hard work from a lot of people,
including (but not limited to) David Gay, Philip Levis, Cory Sharp, 
Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui, 
Prabal Dutta, 
Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler, 
Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel, 
Robert Szewczyk, Rodrigo Fonseca, Kyle Jamieson, Omprakash Gnawali,
David Moss, and Kristin Wright.


15. Author's Address
====================================================================

| Philip Levis
| 358 Gates
| Computer Systems Laboratory
| Stanford University
| Stanford, CA 94305
|
| phone - +1 650 725 9046
|
| email - pal@cs.stanford.edu

16. Citations
====================================================================

.. [TEP1] TEP 1: TEP Structure and Keywords. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep1.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP2] TEP 2: Hardware Abstraction Architecture. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep2.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP3] TEP 3: Coding Standard. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep3.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP101] TEP 101: Analog-to-Digital Converters. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep101.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP102] TEP 102: Timers. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep102.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP106] TEP 106: Schedulers and Tasks. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep106.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP107] TEP 107: Boot Sequence. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep107.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP108] TEP 108: message_t. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep108.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP109] TEP 109: Sensorboards. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep109.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP110] TEP 110: Service Distributions. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep110.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP111] TEP 111: message_t. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep111.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP112] TEP 112: Microcontroller Power Management. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep112.html?pathrev=tinyos-2_0_devel-BRANCH

.. [TEP113] TEP 113: Serial Communication. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep113.html?pathrev=tinyos-2_0_devel-BRANCH
 
.. [TEP114] TEP 114: SIDs: Source and Sink Independent Drivers. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep114.html?pathrev=tinyos-2_0_devel-BRANCH
 
.. [TEP115] TEP 115: Power Management of Non-Virtualised Devices. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep115.html?pathrev=tinyos-2_0_devel-BRANCH
 
.. [TEP116] TEP 116: Packet Protocols. http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep116.html?pathrev=tinyos-2_0_devel-BRANCH