-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-<meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
-<title>TinyOS 2.0 Overview</title>
-<meta name="author" content="Philip Levis" />
-<meta name="date" content="Oct 30 2006" />
-<style type="text/css">
-
-/*
-:Author: David Goodger
-:Contact: goodger@users.sourceforge.net
-:date: $Date$
-:version: $Revision$
-:copyright: This stylesheet has been placed in the public domain.
-
-Default cascading style sheet for the HTML output of Docutils.
-*/
-body {
- font-family: Times;
- font-size: 16px;
-}
-
-.first {
- margin-top: 0 ! important }
-
-.last {
- margin-bottom: 0 ! important }
-
-.hidden {
- display: none }
-
-a.toc-backref {
- text-decoration: none ;
- color: black }
-
-blockquote.epigraph {
- margin: 2em 5em ; }
-
-dd {
- margin-bottom: 0.5em }
-
-/* Uncomment (& remove this text!) to get bold-faced definition list terms
-dt {
- font-weight: bold }
-*/
-
-div.abstract {
- margin: 2em 5em }
-
-div.abstract p.topic-title {
- font-weight: bold ;
- text-align: center }
-
-div.attention, div.caution, div.danger, div.error, div.hint,
-div.important, div.note, div.tip, div.warning, div.admonition {
- margin: 2em ;
- border: medium outset ;
- padding: 1em }
-
-div.attention p.admonition-title, div.caution p.admonition-title,
-div.danger p.admonition-title, div.error p.admonition-title,
-div.warning p.admonition-title {
- color: red ;
- font-weight: bold ;
- font-family: sans-serif }
-
-div.hint p.admonition-title, div.important p.admonition-title,
-div.note p.admonition-title, div.tip p.admonition-title,
-div.admonition p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
-div.dedication {
- margin: 2em 5em ;
- text-align: center ;
- font-style: italic }
-
-div.dedication p.topic-title {
- font-weight: bold ;
- font-style: normal }
-
-div.figure {
- margin-left: 2em }
-
-div.footer, div.header {
- font-size: smaller }
-
-div.line-block {
- display: block ;
- margin-top: 1em ;
- margin-bottom: 1em }
-
-div.line-block div.line-block {
- margin-top: 0 ;
- margin-bottom: 0 ;
- margin-left: 1.5em }
-
-div.sidebar {
- margin-left: 1em ;
- border: medium outset ;
- padding: 0em 1em ;
- background-color: #ffffee ;
- width: 40% ;
- float: right ;
- clear: right }
-
-div.sidebar p.rubric {
- font-family: sans-serif ;
- font-size: medium }
-
-div.system-messages {
- margin: 5em }
-
-div.system-messages h1 {
- color: red }
-
-div.system-message {
- border: medium outset ;
- padding: 1em }
-
-div.system-message p.system-message-title {
- color: red ;
- font-weight: bold }
-
-div.topic {
- margin: 2em }
-
-h1 {
- font-family: Arial, sans-serif;
- font-size: 20px;
-}
-
-h1.title {
- text-align: center;
- font-size: 32px;
-}
-
-h2 {
- font-size: 16px;
- font-family: Arial, sans-serif;
-}
-
-h2.subtitle {
- text-align: center }
-
-h3 {
- font-size: 12px;
- font-family: Arial, sans-serif;
-}
-
-hr {
- width: 75% }
-
-ol.simple, ul.simple {
- margin-bottom: 1em }
-
-ol.arabic {
- list-style: decimal }
-
-ol.loweralpha {
- list-style: lower-alpha }
-
-ol.upperalpha {
- list-style: upper-alpha }
-
-ol.lowerroman {
- list-style: lower-roman }
-
-ol.upperroman {
- list-style: upper-roman }
-
-p.attribution {
- text-align: right ;
- margin-left: 50% }
-
-p.caption {
- font-style: italic }
-
-p.credits {
- font-style: italic ;
- font-size: smaller }
-
-p.label {
- white-space: nowrap }
-
-p.rubric {
- font-weight: bold ;
- font-size: larger ;
- color: maroon ;
- text-align: center }
-
-p.sidebar-title {
- font-family: sans-serif ;
- font-weight: bold ;
- font-size: larger }
-
-p.sidebar-subtitle {
- font-family: sans-serif ;
- font-weight: bold }
-
-p.topic-title {
- font-weight: bold }
-
-pre.address {
- margin-bottom: 0 ;
- margin-top: 0 ;
- font-family: serif ;
- font-size: 100% }
-
-pre.line-block {
- font-family: serif ;
- font-size: 100% }
-
-pre.literal-block, pre.doctest-block {
- margin-left: 2em ;
- margin-right: 2em ;
- background-color: #eeeeee }
-
-span.classifier {
- font-family: sans-serif ;
- font-style: oblique }
-
-span.classifier-delimiter {
- font-family: sans-serif ;
- font-weight: bold }
-
-span.interpreted {
- font-family: sans-serif }
-
-span.option {
- white-space: nowrap }
-
-span.option-argument {
- font-style: italic }
-
-span.pre {
- white-space: pre }
-
-span.problematic {
- color: red }
-
-table {
- margin-top: 0.5em ;
- margin-bottom: 0.5em }
-
-table.citation {
- border-left: solid thin gray ;
- padding-left: 0.5ex }
-
-table.docinfo {
- margin: 2em 4em;
-}
-
-table.footnote {
- border-left: solid thin black ;
- padding-left: 0.5ex }
-
-td, th {
- padding-left: 0.5em ;
- padding-right: 0.5em ;
- vertical-align: top }
-
-th.docinfo-name, th.field-name {
- font-weight: bold ;
- text-align: left ;
- white-space: nowrap;
- }
-
-h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
- font-size: 100% }
-
-tt {
- font: Courier,monospaced;
- font-size: 12px;
- background-color: #eeeeee }
-
-ul.auto-toc {
- list-style-type: none }
-
-</style>
-</head>
-<body>
-<h1 class="title">TinyOS 2.0 Overview</h1>
-<table class="docinfo" frame="void" rules="none">
-<col class="docinfo-name" />
-<col class="docinfo-content" />
-<tbody valign="top">
-<tr><th class="docinfo-name">Author:</th>
-<td>Philip Levis</td></tr>
-<tr><th class="docinfo-name">Date:</th>
-<td>Oct 30 2006</td></tr>
-</tbody>
-</table>
-<div class="document" id="tinyos-2-0-overview">
-<div class="note">
-<p class="first admonition-title">Note</p>
-<p class="last">This document gives a brief overview of TinyOS 2.0, highlighting how
-and where it departs from 1.1 and 1.0. Further detail on these changes
-is detailed in TEP (TinyOS Enhancement Proposal) documents.</p>
-</div>
-<div class="section" id="introduction">
-<h1><a name="introduction">1. Introduction</a></h1>
-<p>TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS.
-Its development was motivated by our belief that many aspects of 1.x
-strain to meet requirements and uses that were not foreseen
-when it was designed and implemented. The structure and interfaces 1.x
-defines have several fundamental limitations. While these limitations
-can be worked around, this practice has led to tightly coupled
-components, hard to find interactions, and a very steep learning curve
-for a newcomer to sensor network programming.</p>
-<p>TinyOS 2.0 is not backwards compatible with 1.x: code written for the
-latter will not compile for the former. However, one important aspect
-of 2.0's design is to minimize the difficulty of upgrading
-code. Therefore, while porting a 1.x application to 2.0 will require
-some work, it should not be very much.</p>
-<p>This document provides a high-level overview of 2.0 and describes some
-of the ways in which it departs from 1.x. It covers the basic TinyOS
-abstractions, such as hardware abstractions, communication, timers,
-the scheduler, booting and initialization. Further detail on each of
-these can be found in TEPs (TinyOS Enhancement Proposals), which
-document and describe these abstractions.</p>
-</div>
-<div class="section" id="platforms-hardware-abstraction">
-<h1><a name="platforms-hardware-abstraction">2. Platforms/Hardware Abstraction</a></h1>
-<p>Platforms exist in the <tt class="docutils literal"><span class="pre">tos/platforms</span></tt> subdirectory. In TinyOS 2.0, a
-<em>platform</em> is a collection of <em>chips</em> and some glue code that connects
-them together. For example, the mica2 platform is the CC1000 radio
-chip and the ATmega128 microcontroller, while the micaZ platform is
-the CC2420 radio and the ATmega128 microcontroller, and the Teloi
-platforms are the CC2420 radio and the MSP430 microcontroller. Chip
-code exists in <tt class="docutils literal"><span class="pre">tos/chips</span></tt>. A platform directory generally has a
-<tt class="docutils literal"><span class="pre">.platform</span></tt> file, which has options to pass to the nesC compiler. For
-example, the mica2 .platform file tells ncc to look in <tt class="docutils literal"><span class="pre">chips/cc1000</span></tt>
-and <tt class="docutils literal"><span class="pre">chips/atm128</span></tt> directories, as well as to use avr-gcc to compile a
-mote binary (Teloi platforms tell it to use msp430-gcc).</p>
-<p>Hardware abstractions in TinyOS 2.0 generally follow a three-level
-abstaction heirarchy, called the HAA (Hardware Abstraction
-Architecture).</p>
-<p>At the bottom of the HAA is the HPL (Hardware Presentation Layer). The
-HPL is a thin software layer on top of the raw hardware, presenting
-hardare such as IO pins or registers as nesC interfaces. The HPL
-generally has no state besides the hardware itself (it has no
-variables). HPL components usually have the prefix <tt class="docutils literal"><span class="pre">Hpl</span></tt>, followed by
-the name of the chip. For example, the HPL components of the CC1000
-begin with <tt class="docutils literal"><span class="pre">HplCC1000</span></tt>.</p>
-<p>The middle of the HAA is the HAL (Hardware Abstraction Layer). The HAL
-builds on top of the HPL and provides higher-level abstractions that
-are easier to use than the HPL but still provide the full
-functionality of the underlying hardware. The HAL components usually have
-a prefix of the chip name. For example, the HAL components of the CC1000
-begin with <tt class="docutils literal"><span class="pre">CC1000</span></tt>.</p>
-<p>The top of the HAA is the HIL (Hardware Independent Layer). The HIL
-builds on top of the HAL and provides abstractions that are hardware
-independent. This generalization means that the HIL usually does not
-provide all of the functionality that the HAL can. HIL components have
-no naming prefix, as they represent abstractions that applications can
-use and safely compile on multiple platforms. For example, the HIL
-component of the CC1000 on the mica2 is <tt class="docutils literal"><span class="pre">ActiveMessageC</span></tt>, representing
-a full active message communication layer.</p>
-<p>The HAA is described in TEP 2: Hardware Abstraction Architecture[<a class="reference" href="#tep2">TEP2</a>].</p>
-<p>Currently (as of the 2.0 release in November 2006), TinyOS 2.0 supports
-the following platforms:</p>
-<blockquote>
-<ul class="simple">
-<li>eyesIFXv2</li>
-<li>intelmote2</li>
-<li>mica2</li>
-<li>mica2dot</li>
-<li>micaZ</li>
-<li>telosb</li>
-<li>tinynode</li>
-<li>btnode3</li>
-</ul>
-</blockquote>
-<p>The btnode3 platform is not included in the RPM.</p>
-</div>
-<div class="section" id="scheduler">
-<h1><a name="scheduler">3. Scheduler</a></h1>
-<p>As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO
-policy. However, tasks in 2.0 operate slightly differently than in
-1.x.</p>
-<p>In TinyOS 1.x, there is a shared task queue for all tasks, and a
-component can post a task multiple times. If the task queue is full,
-the post operation fails. Experience with networking stacks showed
-this to be problematic, as the task might signal completion of a
-split-phase operation: if the post fails, the component above might
-block forever, waiting for the completion event.</p>
-<p>In TinyOS 2.x, every task has its own reserved slot in the task queue,
-and a task can only be posted once. A post fails if and only if the
-task has already been posted. If a component needs to post a task
-multiple times, it can set an internal state variable so that when
-the task executes, it reposts itself.</p>
-<p>This slight change in semantics greatly simplifies a lot of component
-code. Rather than test to see if a task is posted already before
-posting it, a component can just post the task. Components do not have
-to try to recover from failed posts and retry. The cost is one byte of
-state per task. Even in large systems such as TinyDB, this cost is
-under one hundred bytes (in TinyDB is is approximately 50).</p>
-<p>Applications can also replace the scheduler, if they wish. This allows
-programmers to try new scheduling policies, such as priority- or
-deadline-based. It is important to maintain non-preemptiveness,
-however, or the scheduler will break all nesC's static concurrency
-analysis. Details on the new scheduler and how to extend it can be found
-in TEP 106: Schedulers and Tasks[<a class="reference" href="#tep106">TEP106</a>].</p>
-</div>
-<div class="section" id="booting-initialization">
-<h1><a name="booting-initialization">4. Booting/Initialization</a></h1>
-<p>TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface
-<tt class="docutils literal"><span class="pre">StdControl</span></tt> has been split into two interfaces: <tt class="docutils literal"><span class="pre">Init</span></tt> and
-<tt class="docutils literal"><span class="pre">StdControl</span></tt>. The latter only has two commands: <tt class="docutils literal"><span class="pre">start</span></tt> and <tt class="docutils literal"><span class="pre">stop</span></tt>.
-In TinyOS 1.x, wiring components to the boot sequence would cause them
-to be powered up and started at boot. That is no longer the case: the
-boot sequence only initializes components. When it has completed
-initializing the scheduler, hardware, and software, the boot sequence
-signals the <tt class="docutils literal"><span class="pre">Boot.booted</span></tt> event. The top-level application component
-handles this event and start services accordingly. Details on
-the new boot sequence can be found in TEP 107: TinyOS 2.x Boot
-Sequence[<a class="reference" href="#tep107">TEP107</a>].</p>
-</div>
-<div class="section" id="virtualization">
-<h1><a name="virtualization">5. Virtualization</a></h1>
-<p>TinyOS 2.0 is written with nesC 1.2, which introduces the concept
-of a 'generic' or instantiable component. Generic modules allow
-TinyOS to have reusable data structures, such as bit vectors and
-queues, which simplify development. More importantly, generic
-configurations allow services to encapsulate complex wiring
-relationships for clients that need them.</p>
-<p>In practice, this means that many basic TinyOS services are now
-<em>virtualized.</em> Rather than wire to a component with a parameterized
-interface (e.g., GenericComm or TimerC in 1.x), a program instantiates
-a service component that provides the needed interface. This
-service component does all of the wiring underneath (e.g., in the
-case of timers, to a unique) automatically, reducing wiring
-mistakes and simplifying use of the abstraction.</p>
-</div>
-<div class="section" id="timers">
-<h1><a name="timers">6. Timers</a></h1>
-<p>TinyOS 2.0 provides a much richer set of timer interfaces than
-1.x. Experience has shown that timers are one of the most critical
-abstractions a mote OS can provide, and so 2.0 expands the fidelity
-and form that timers take. Depending on the hardware resources of a
-platform, a component can use 32KHz as well as millisecond granularity
-timers, and the timer system may provide one or two high-precision
-timers that fire asynchronously (they have the async
-keyword). Components can query their timers for how much time
-remainins before they fire, and can start timers in the future (e.g.,
-'start firing a timer at 1Hz starting 31ms from now'). TEP 102:
-Timers[<a class="reference" href="#tep102">TEP102</a>] defines what HIL components a platform must provide
-in order to support standard TinyOS timers. Platforms are
-required to provide millisecond granularity timers, and can provide
-finer granularity timers (e.g., 32kHz) if needed.</p>
-<p>Timers present a good example of virtualization in 2.0. In 1.x,
-a program instantiates a timer by wiring to TimerC:</p>
-<pre class="literal-block">
-components App, TimerC;
-App.Timer -> TimerC.Timer[unique("Timer")];
-</pre>
-<p>In 2.0, a program instantiates a timer:</p>
-<pre class="literal-block">
-components App, new TimerMilliC();
-App.Timer -> TimerMilliC;
-</pre>
-</div>
-<div class="section" id="communication">
-<h1><a name="communication">7. Communication</a></h1>
-<p>In TinyOS 2.0, the message buffer type is <tt class="docutils literal"><span class="pre">message_t</span></tt>, and it is a
-buffer that is large enough to hold a packet from any of a node's
-communication interfaces. The structure itself is completely opaque:
-components cannot reference its fields. Instead, all buffer accesses
-go through interfaces. For example, to get the destination address of
-an AM packet named <tt class="docutils literal"><span class="pre">msg</span></tt>, a component calls <tt class="docutils literal"><span class="pre">AMPacket.destination(msg)</span></tt>.</p>
-<p>Send interfaces distinguish the addressing mode of communication
-abstractions. For example, active message communication has the
-<tt class="docutils literal"><span class="pre">AMSend</span></tt> interface, as sending a packet require an AM destination
-address. In contrast, broadcasting and collection tree abstractions
-have the address-free <tt class="docutils literal"><span class="pre">Send</span></tt> interface.</p>
-<p>Active messages are the network HIL. A platform's <tt class="docutils literal"><span class="pre">ActiveMessageC</span></tt>
-component defines which network interface is the standard
-communication medium. For example, a mica2 defines the CC1000 active
-message layer as ActiveMessageC, while the TMote defines the CC2420
-active message layer as ActiveMessageC.</p>
-<p>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.</p>
-<p>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.</p>
-<p>Further information on message_t can be found in TEP 111:
-message_t[<a class="reference" href="#tep111">TEP111</a>], while further information on AM can be
-found in TEP 116: Packet Protocols[<a class="reference" href="#tep116">TEP116</a>].</p>
-<p>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).</p>
-</div>
-<div class="section" id="sensors">
-<h1><a name="sensors">8. Sensors</a></h1>
-<p>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.</p>
-<p>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). <tt class="docutils literal"><span class="pre">Read</span></tt> assumes that the
-request can tolerate some latencies (for example, it might schedule
-competing requests using a FIFO policy).</p>
-<p>Details on the ADC subsystem can be found in
-TEP 101: Analog-to-Digital Converters[<a class="reference" href="#tep101">TEP101</a>]; details on
-the organization of sensor boards can be found in TEP 109:
-Sensorboards[<a class="reference" href="#tep109">TEP109</a>], and the details of the HIL sensor interfaces
-can be found in TEP 114: Source and Sink Independent Drivers[<a class="reference" href="#tep114">TEP114</a>].</p>
-</div>
-<div class="section" id="error-codes">
-<h1><a name="error-codes">9. Error Codes</a></h1>
-<p>The standard TinyOS 1.x return code is <tt class="docutils literal"><span class="pre">result_t</span></tt>, 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., <tt class="docutils literal"><span class="pre">if</span> <span class="pre">(call</span>
-<span class="pre">A.b())</span></tt>), it does not allow the callee to distinguish causes of error
-to the caller. In TinyOS 2.0, <tt class="docutils literal"><span class="pre">result_t</span></tt> is replaced by <tt class="docutils literal"><span class="pre">error_t</span></tt>,
-whose values include SUCCESS, FAIL, EBUSY, and ECANCEL. Interface
-commands and events define which error codes they may return and why.</p>
-<p>From the perspective of porting code, this is the most significant
-different in 2.0. Calls that were once:</p>
-<pre class="literal-block">
-if (call X.y()) {
- busy = TRUE;
-}
-</pre>
-<p>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:</p>
-<pre class="literal-block">
-if (call X.y() == SUCCESS) {
- busy = TRUE;
-}
-</pre>
-</div>
-<div class="section" id="arbitration">
-<h1><a name="arbitration">10. Arbitration</a></h1>
-<p>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.</p>
-<p>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.</p>
-<p>TEP 108: Resource Arbitration[<a class="reference" href="#tep108">TEP108</a>] describes the Resource interface
-and how arbiters work.</p>
-</div>
-<div class="section" id="power-management">
-<h1><a name="power-management">11. Power Management</a></h1>
-<p>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[<a class="reference" href="#tep112">TEP112</a>],
-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{<a class="reference" href="#tep115">TEP115</a>], is handled
-through resource abiters. Fully virtualized services have their
-own, individual power management policies.</p>
-<p>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.</p>
-</div>
-<div class="section" id="network-protocols">
-<h1><a name="network-protocols">12. Network Protocols</a></h1>
-<p>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.</p>
-</div>
-<div class="section" id="conclusion">
-<h1><a name="conclusion">13. Conclusion</a></h1>
-<p>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.</p>
-</div>
-<div class="section" id="acknowledgments">
-<h1><a name="acknowledgments">14. Acknowledgments</a></h1>
-<p>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.</p>
-</div>
-<div class="section" id="author-s-address">
-<h1><a name="author-s-address">15. Author's Address</a></h1>
-<div class="line-block">
-<div class="line">Philip Levis</div>
-<div class="line">358 Gates</div>
-<div class="line">Computer Systems Laboratory</div>
-<div class="line">Stanford University</div>
-<div class="line">Stanford, CA 94305</div>
-<div class="line"><br /></div>
-<div class="line">phone - +1 650 725 9046</div>
-<div class="line"><br /></div>
-<div class="line">email - <a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a></div>
-</div>
-</div>
-<div class="section" id="citations">
-<h1><a name="citations">16. Citations</a></h1>
-<table class="docutils citation" frame="void" id="tep1" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep1">[TEP1]</a></td><td>TEP 1: TEP Structure and Keywords. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep1.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep2" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep2">[TEP2]</a></td><td>TEP 2: Hardware Abstraction Architecture. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep2.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep3" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep3">[TEP3]</a></td><td>TEP 3: Coding Standard. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep3.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep101" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep101">[TEP101]</a></td><td>TEP 101: Analog-to-Digital Converters. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep101.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep102" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep102">[TEP102]</a></td><td>TEP 102: Timers. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep102.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep106" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep106">[TEP106]</a></td><td>TEP 106: Schedulers and Tasks. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep106.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep107" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep107">[TEP107]</a></td><td>TEP 107: Boot Sequence. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep107.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep108" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep108">[TEP108]</a></td><td>TEP 108: message_t. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep108.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep109" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep109">[TEP109]</a></td><td>TEP 109: Sensorboards. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep109.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep110" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep110">[TEP110]</a></td><td>TEP 110: Service Distributions. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep110.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep111" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep111">[TEP111]</a></td><td>TEP 111: message_t. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep111.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep112" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep112">[TEP112]</a></td><td>TEP 112: Microcontroller Power Management. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep112.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep113" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep113">[TEP113]</a></td><td>TEP 113: Serial Communication. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep113.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep114" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep114">[TEP114]</a></td><td>TEP 114: SIDs: Source and Sink Independent Drivers. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep114.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep115" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep115">[TEP115]</a></td><td>TEP 115: Power Management of Non-Virtualised Devices. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep115.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-<table class="docutils citation" frame="void" id="tep116" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a name="tep116">[TEP116]</a></td><td>TEP 116: Packet Protocols. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep116.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
-</tbody>
-</table>
-</div>
-</div>
-</body>
-</html>
projects / tinyos-2.x.git / commitdiff