[Tinyos-2-commits] CVS: tinyos-2.x/doc/html overview.html, 1.7,
1.8 tep102.html, 1.8, 1.9
David Gay
idgay at users.sourceforge.net
Mon Jun 11 13:42:37 PDT 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv12879/html
Modified Files:
overview.html tep102.html
Log Message:
102 updates from Ben Greenstein
Index: overview.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/overview.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** overview.html 21 Apr 2007 07:04:39 -0000 1.7
--- overview.html 11 Jun 2007 20:42:35 -0000 1.8
***************
*** 1,745 ****
- <?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 at 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>
--- 0 ----
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep102.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** tep102.html 23 May 2007 21:41:57 -0000 1.8
--- tep102.html 11 Jun 2007 20:42:35 -0000 1.9
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4.1: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
***************
*** 217,225 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
--- 217,221 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
***************
*** 276,280 ****
font-size: 100% }
! tt {}
ul.auto-toc {
--- 272,279 ----
font-size: 100% }
! tt {
! font: Courier,monospaced;
! font-size: 12px;
! background-color: #eeeeee }
ul.auto-toc {
***************
*** 304,308 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.8</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-05-23</td>
--- 303,307 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.9</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-05-23</td>
***************
*** 376,384 ****
by a 32768Hz crystal.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
! for timer interfaces and components SHOULD be 32-bits. That is, for
! lack of a good reason, timer interfaces should expose a 32-bit
! interface. In a number of circumstances there are good reasons not
! to expose a 32-bit interface. This TEP emphasizes 32-bit widths
! while reasonably accommodating other widths.</p>
<p>Accuracy reflects how closely a component conforms to the precision it
claims to provide. Accuracy is affected by issues such as clock drift (much
--- 375,382 ----
by a 32768Hz crystal.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
! for timer interfaces and components SHOULD be 32-bits. This TEP
! emphasizes 32-bit widths while reasonably accommodating other widths -
! a particular platform may have good reasons not to expose a 32-bit
! interface.</p>
<p>Accuracy reflects how closely a component conforms to the precision it
claims to provide. Accuracy is affected by issues such as clock drift (much
***************
*** 483,487 ****
<dd>cancel any previously running alarm.</dd>
<dt>fired()</dt>
! <dd>signals that the alarm has occurred.</dd>
<dt>isRunning()</dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
--- 481,485 ----
<dd>cancel any previously running alarm.</dd>
<dt>fired()</dt>
! <dd>signals that the alarm has expired.</dd>
<dt>isRunning()</dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
***************
*** 518,522 ****
<p>BusyWait blocks for no less than the specified amount of time. No
explicit upper bound is imposed on the enacted delay, though it is
! expected the underlying implementation spins in a busy loop until
the specified amount of time has elapsed.</p>
<pre class="literal-block">
--- 516,520 ----
<p>BusyWait blocks for no less than the specified amount of time. No
explicit upper bound is imposed on the enacted delay, though it is
! expected that the underlying implementation spins in a busy loop until
the specified amount of time has elapsed.</p>
<pre class="literal-block">
***************
*** 584,591 ****
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
! <dd>signals that the timer has occurred.</dd>
<dt>isRunning()</dt>
<dd>return TRUE if the timer has been started and has not been cancelled
! and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
<dt>isOneShot()</dt>
--- 582,589 ----
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
! <dd>signals that the timer has expired (one-shot) or repeated (periodic).</dd>
<dt>isRunning()</dt>
<dd>return TRUE if the timer has been started and has not been cancelled
! and has not fired for the case of one-shot timers. Once a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
<dt>isOneShot()</dt>
***************
*** 656,661 ****
}
</pre>
! <p>This pattern MAY be used to defined components for the platform that
! are mutually incompatible in single application. Incompatible
components SHOULD produce compile-time errors when compiled
together.</p>
--- 654,659 ----
}
</pre>
! <p>This pattern MAY be used to define components for the platform that
! are mutually incompatible in a single application. Incompatible
components SHOULD produce compile-time errors when compiled
together.</p>
***************
*** 852,856 ****
</ul>
</blockquote>
! <p>The implementation of Timers for the MSP430 is in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430/timer</span></tt>:</p>
<blockquote>
--- 850,854 ----
</ul>
</blockquote>
! <p>The implementation of timers for the MSP430 is in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430/timer</span></tt>:</p>
<blockquote>
***************
*** 896,899 ****
--- 894,900 ----
</ul>
</blockquote>
+ <p>Implementation of timers for the ATmega128 and PXA27x may be found in
+ <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/atm128/timer</span></tt> and
+ <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/pxa27x/timer</span></tt> respectively.</p>
</div>
<div class="section">
More information about the Tinyos-2-commits
mailing list