[Tinyos-2-commits] CVS: tinyos-2.x/doc/html overview.html, 1.9, 1.10 porting.html, 1.7, 1.8 tep1.html, 1.11, 1.12 tep101.html, 1.10, 1.11 tep102.html, 1.12, 1.13 tep103.html, 1.8, 1.9 tep105.html, 1.1, 1.2 tep106.html, 1.10, 1.11 tep107.html, 1.14, 1.15 tep108.html, 1.11, 1.12 tep109.html, 1.12, 1.13 tep110.html, 1.8, 1.9 tep111.html, 1.11, 1.12 tep112.html, 1.10, 1.11 tep113.html, 1.12, 1.13 tep114.html, 1.12, 1.13 tep115.html, 1.13, 1.14 tep116.html, 1.17, 1.18 tep117.html, 1.9, 1.10 tep118.html, 1.11, 1.12 tep119.html, 1.14, 1.15 tep120.html, 1.10, 1.11 tep121.html, 1.8, 1.9 tep122.html, 1.1, 1.2 tep123.html, 1.10, 1.11 tep124.html, 1.4, 1.5 tep125.html, 1.6, 1.7 tep126.html, 1.3, 1.4 tep127.html, 1.1, 1.2 tep128.html, 1.1, 1.2 tep129.html, 1.1, 1.2 tep130.html, 1.1, 1.2 tep131.html, 1.1, 1.2 tep132.html, 1.1, 1.2 tep133.html, 1.1, 1.2 tep134.html, 1.1, 1.2 tep135.html, 1.1, 1.2 tep2.html, 1.13, 1.14 tep3.html, 1.8, 1.9 tep4.html, 1.1, 1.2
Phil Levis
scipio at users.sourceforge.net
Tue Feb 3 15:07:39 PST 2009
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv19972
Modified Files:
overview.html porting.html tep1.html tep101.html tep102.html
tep103.html tep105.html tep106.html tep107.html tep108.html
tep109.html tep110.html tep111.html tep112.html tep113.html
tep114.html tep115.html tep116.html tep117.html tep118.html
tep119.html tep120.html tep121.html tep122.html tep123.html
tep124.html tep125.html tep126.html tep127.html tep128.html
tep129.html tep130.html tep131.html tep132.html tep133.html
tep134.html tep135.html tep2.html tep3.html tep4.html
Log Message:
Make sure they are all up to date
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep102.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** tep102.html 5 Sep 2007 20:06:00 -0000 1.12
--- tep102.html 3 Feb 2009 23:07:32 -0000 1.13
***************
*** 4,8 ****
<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>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" />
***************
*** 279,282 ****
--- 279,283 ----
</head>
<body>
+ <div class="document" id="timers">
<h1 class="title">Timers</h1>
<table class="docinfo" frame="void" rules="none">
***************
*** 298,302 ****
</tbody>
</table>
- <div class="document" id="timers">
<div class="note">
<p class="first admonition-title">Note</p>
--- 299,302 ----
***************
*** 306,311 ****
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This TEP proposes a Timer design that supports common timing
requirements both in precision and width across common hardware
--- 306,311 ----
TEP 1.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This TEP proposes a Timer design that supports common timing
requirements both in precision and width across common hardware
***************
*** 313,318 ****
with the three-layer Hardware Abstraction Architecture (HAA).</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Most microcontrollers offer a rich timer system, with features like:</p>
<ul class="simple">
--- 313,318 ----
with the three-layer Hardware Abstraction Architecture (HAA).</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Most microcontrollers offer a rich timer system, with features like:</p>
<ul class="simple">
***************
*** 328,332 ****
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
--- 328,332 ----
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
***************
*** 337,341 ****
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
--- 337,341 ----
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
***************
*** 345,355 ****
timer subsystem implementation.</p>
</div>
! <div class="section" id="interfaces">
! <h1><a name="interfaces">2. Interfaces</a></h1>
<p>Before presenting the interfaces (2.2), we start with a general
discussion of the issues of precision, width and accuracy in
timer interfaces (2.1).</p>
! <div class="section" id="precision-width-and-accuracy">
! <h2><a name="precision-width-and-accuracy">2.1 Precision, Width and Accuracy</a></h2>
<p>Three fundamental properties of timers are <em>precision</em>, <em>width</em> and
<em>accuracy</em>.</p>
--- 345,355 ----
timer subsystem implementation.</p>
</div>
! <div class="section">
! <h1><a id="interfaces" name="interfaces">2. Interfaces</a></h1>
<p>Before presenting the interfaces (2.2), we start with a general
discussion of the issues of precision, width and accuracy in
timer interfaces (2.1).</p>
! <div class="section">
! <h2><a id="precision-width-and-accuracy" name="precision-width-and-accuracy">2.1 Precision, Width and Accuracy</a></h2>
<p>Three fundamental properties of timers are <em>precision</em>, <em>width</em> and
<em>accuracy</em>.</p>
***************
*** 360,364 ****
This TEP emphasizes millisecond and 32kHz tick precisions while
reasonably accommodating other precisions. The use of "binary" units
! is motivated by the common availability of hardware clocks driven
by a 32768Hz crystal.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
--- 360,364 ----
This TEP emphasizes millisecond and 32kHz tick precisions while
reasonably accommodating other precisions. The use of "binary" units
! is motivated by the common availability of hardware clocks driven
by a 32768Hz crystal.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
***************
*** 393,398 ****
period, whichever is convenient.</p>
</div>
! <div class="section" id="timer-interfaces">
! <h2><a name="timer-interfaces">2.2 Timer interfaces</a></h2>
<p>This TEP proposes these timer interfaces:</p>
<pre class="literal-block">
--- 393,398 ----
period, whichever is convenient.</p>
</div>
! <div class="section">
! <h2><a id="timer-interfaces" name="timer-interfaces">2.2 Timer interfaces</a></h2>
<p>This TEP proposes these timer interfaces:</p>
<pre class="literal-block">
***************
*** 408,413 ****
advanced user components.</p>
</div>
! <div class="section" id="counter">
! <h2><a name="counter">Counter</a></h2>
<p>The Counter interface returns the current time and provides commands
and an event for managing overflow conditions. These overflow
--- 408,413 ----
advanced user components.</p>
</div>
! <div class="section">
! <h2><a id="counter" name="counter">Counter</a></h2>
<p>The Counter interface returns the current time and provides commands
and an event for managing overflow conditions. These overflow
***************
*** 424,443 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending() </dt>
<dd>return TRUE if the overflow flag is set for this counter, i.e., if and
only if an overflow event will occur after the outermost atomic
block exits. Return FALSE otherwise. This command only returns the
state of the overflow flag and causes no side effect.</dd>
! <dt>clearOverflow() </dt>
<dd>cancel the pending overflow event clearing the overflow flag.</dd>
! <dt>overflow() </dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section" id="alarm">
! <h2><a name="alarm">Alarm</a></h2>
<p>Alarm components are extensions of Counters that signal an event
when their compare register detects the alarm time has been hit.
--- 424,443 ----
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending()</dt>
<dd>return TRUE if the overflow flag is set for this counter, i.e., if and
only if an overflow event will occur after the outermost atomic
block exits. Return FALSE otherwise. This command only returns the
state of the overflow flag and causes no side effect.</dd>
! <dt>clearOverflow()</dt>
<dd>cancel the pending overflow event clearing the overflow flag.</dd>
! <dt>overflow()</dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="alarm" name="alarm">Alarm</a></h2>
<p>Alarm components are extensions of Counters that signal an event
when their compare register detects the alarm time has been hit.
***************
*** 462,474 ****
</pre>
<dl class="docutils">
! <dt>start(dt) </dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop() </dt>
<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
or has not yet fired. FALSE is returned otherwise.</dd>
--- 462,474 ----
</pre>
<dl class="docutils">
! <dt>start(dt)</dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop()</dt>
<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
or has not yet fired. FALSE is returned otherwise.</dd>
***************
*** 486,492 ****
</blockquote>
<dl class="docutils">
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm() </dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire. getAlarm can
--- 486,492 ----
</blockquote>
<dl class="docutils">
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm()</dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire. getAlarm can
***************
*** 496,501 ****
</dl>
</div>
! <div class="section" id="busywait">
! <h2><a name="busywait">BusyWait</a></h2>
<p>The BusyWait interface allows for very short synchronous delays.
BusyWait should be used sparingly and when an Alarm would not be
--- 496,501 ----
</dl>
</div>
! <div class="section">
! <h2><a id="busywait" name="busywait">BusyWait</a></h2>
<p>The BusyWait interface allows for very short synchronous delays.
BusyWait should be used sparingly and when an Alarm would not be
***************
*** 517,522 ****
</dl>
</div>
! <div class="section" id="localtime">
! <h2><a name="localtime">LocalTime</a></h2>
<p>The LocalTime interface exposes a 32-bit counter without overflow
utilities. This is primarily for application code that does not
--- 517,522 ----
</dl>
</div>
! <div class="section">
! <h2><a id="localtime" name="localtime">LocalTime</a></h2>
<p>The LocalTime interface exposes a 32-bit counter without overflow
utilities. This is primarily for application code that does not
***************
*** 529,538 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
</dl>
</div>
! <div class="section" id="timer">
! <h2><a name="timer">Timer</a></h2>
<p>All commands and events of the Timer interface are synchronous (or
in "task context"). The Timer interface provides a set of "basic"
--- 529,538 ----
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="timer" name="timer">Timer</a></h2>
<p>All commands and events of the Timer interface are synchronous (or
in "task context"). The Timer interface provides a set of "basic"
***************
*** 559,582 ****
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop() </dt>
<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>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt) </dt>
<dd><p class="first">cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
--- 559,582 ----
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop()</dt>
<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>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt)</dt>
<dd><p class="first">cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
***************
*** 586,606 ****
<tt class="docutils literal"><span class="pre">getNow()</span></tt>) represents a time from before the last wraparound.</p>
</dd>
! <dt>startOneShotAt(t0,dt) </dt>
<dd><p class="first">cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</p>
<p class="last"><tt class="docutils literal"><span class="pre">t0</span></tt> is as in <tt class="docutils literal"><span class="pre">startPeriodicAt</span></tt>.</p>
</dd>
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0() </dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt() </dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section" id="hal-guidelines">
! <h1><a name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms SHOULD expose their relevant timing capabilities using
standard Alarm and Counter interfaces. The design pattern presented
--- 586,606 ----
<tt class="docutils literal"><span class="pre">getNow()</span></tt>) represents a time from before the last wraparound.</p>
</dd>
! <dt>startOneShotAt(t0,dt)</dt>
<dd><p class="first">cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</p>
<p class="last"><tt class="docutils literal"><span class="pre">t0</span></tt> is as in <tt class="docutils literal"><span class="pre">startPeriodicAt</span></tt>.</p>
</dd>
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0()</dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt()</dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section">
! <h1><a id="hal-guidelines" name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms SHOULD expose their relevant timing capabilities using
standard Alarm and Counter interfaces. The design pattern presented
***************
*** 647,652 ****
together.</p>
</div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
<p>The following component MUST be provided on all platforms</p>
<pre class="literal-block">
--- 647,652 ----
together.</p>
</div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
<p>The following component MUST be provided on all platforms</p>
<pre class="literal-block">
***************
*** 658,663 ****
other precisions (e.g., regular, non-binary milliseconds) MAY also be
provided.</p>
! <div class="section" id="hiltimermillic">
! <h2><a name="hiltimermillic">HilTimerMilliC</a></h2>
<pre class="literal-block">
configuration HilTimerMilliC
--- 658,663 ----
other precisions (e.g., regular, non-binary milliseconds) MAY also be
provided.</p>
! <div class="section">
! <h2><a id="hiltimermillic" name="hiltimermillic">HilTimerMilliC</a></h2>
<pre class="literal-block">
configuration HilTimerMilliC
***************
*** 674,679 ****
TimerMilliC generic component, both found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt></p>
</div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
--- 674,679 ----
TimerMilliC generic component, both found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt></p>
</div>
! <div class="section">
! <h2><a id="busywaitmicroc" name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
***************
*** 688,693 ****
</div>
</div>
! <div class="section" id="utility-components">
! <h1><a name="utility-components">5. Utility components</a></h1>
<p>A number of platform independent generic components are provided to
help implementers and advanced users of the TinyOS timer system:</p>
--- 688,693 ----
</div>
</div>
! <div class="section">
! <h1><a id="utility-components" name="utility-components">5. Utility components</a></h1>
<p>A number of platform independent generic components are provided to
help implementers and advanced users of the TinyOS timer system:</p>
***************
*** 702,707 ****
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section" id="alarmtotimerc">
! <h2><a name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
--- 702,707 ----
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section">
! <h2><a id="alarmtotimerc" name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
***************
*** 713,718 ****
</pre>
</div>
! <div class="section" id="busywaitcounterc">
! <h2><a name="busywaitcounterc">BusyWaitCounterC</a></h2>
<p>BusyWaitCounterC uses a Counter to block until a specified amount of
time elapses.</p>
--- 713,718 ----
</pre>
</div>
! <div class="section">
! <h2><a id="busywaitcounterc" name="busywaitcounterc">BusyWaitCounterC</a></h2>
<p>BusyWaitCounterC uses a Counter to block until a specified amount of
time elapses.</p>
***************
*** 726,731 ****
</pre>
</div>
! <div class="section" id="countertolocaltimec">
! <h2><a name="countertolocaltimec">CounterToLocalTimeC</a></h2>
<p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
<pre class="literal-block">
--- 726,731 ----
</pre>
</div>
! <div class="section">
! <h2><a id="countertolocaltimec" name="countertolocaltimec">CounterToLocalTimeC</a></h2>
<p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
<pre class="literal-block">
***************
*** 737,746 ****
</pre>
</div>
! <div class="section" id="transformalarmc">
! <h2><a name="transformalarmc">TransformAlarmC</a></h2>
<p>TransformAlarmC decreases precision and/or widens an Alarm. An
already widened Counter component is used to help.</p>
<pre class="literal-block">
! generic component TransformAlarmC(
typedef to_precision_tag,
typedef to_size_type @integer(),
--- 737,746 ----
</pre>
</div>
! <div class="section">
! <h2><a id="transformalarmc" name="transformalarmc">TransformAlarmC</a></h2>
<p>TransformAlarmC decreases precision and/or widens an Alarm. An
already widened Counter component is used to help.</p>
<pre class="literal-block">
! generic component TransformAlarmC(
typedef to_precision_tag,
typedef to_size_type @integer(),
***************
*** 770,775 ****
passed to TransformAlarmC are inconsistent.</p>
</div>
! <div class="section" id="transformcounterc">
! <h2><a name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
--- 770,775 ----
passed to TransformAlarmC are inconsistent.</p>
</div>
! <div class="section">
! <h2><a id="transformcounterc" name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
***************
*** 802,807 ****
</pre>
</div>
! <div class="section" id="virtualizetimerc">
! <h2><a name="virtualizetimerc">VirtualizeTimerC</a></h2>
<p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
timers.</p>
--- 802,807 ----
</pre>
</div>
! <div class="section">
! <h2><a id="virtualizetimerc" name="virtualizetimerc">VirtualizeTimerC</a></h2>
<p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
timers.</p>
***************
*** 816,821 ****
</div>
</div>
! <div class="section" id="implementation">
! <h1><a name="implementation">6. Implementation</a></h1>
<p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
<blockquote>
--- 816,821 ----
</div>
</div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
<p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
<blockquote>
***************
*** 857,861 ****
<li><tt class="docutils literal"><span class="pre">CounterMilli32C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<TMilli,uint32_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">GpioCaptureC.nc</span></tt></li>
! <li><tt class="docutils literal"><span class="pre">HilTimerMilliC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">LocalTime<TMilli></span></tt> and
<tt class="docutils literal"><span class="pre">Timer<TMilli></span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
<li><tt class="docutils literal"><span class="pre">Msp430AlarmC.nc</span></tt> is generic and converts an MSP430 timer to a 16-bit Alarm</li>
--- 857,861 ----
<li><tt class="docutils literal"><span class="pre">CounterMilli32C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<TMilli,uint32_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">GpioCaptureC.nc</span></tt></li>
! <li><tt class="docutils literal"><span class="pre">HilTimerMilliC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">LocalTime<TMilli></span></tt> and
<tt class="docutils literal"><span class="pre">Timer<TMilli></span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
<li><tt class="docutils literal"><span class="pre">Msp430AlarmC.nc</span></tt> is generic and converts an MSP430 timer to a 16-bit Alarm</li>
***************
*** 890,895 ****
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/pxa27x/timer</span></tt> respectively.</p>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Cory Sharp</div>
--- 890,895 ----
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/pxa27x/timer</span></tt> respectively.</p>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Cory Sharp</div>
***************
*** 919,924 ****
</div>
</div>
! <div class="section" id="appendix-a-timer-hardware-on-various-microcontrollers">
! <h1><a name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
--- 919,924 ----
</div>
</div>
! <div class="section">
! <h1><a id="appendix-a-timer-hardware-on-various-microcontrollers" name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
***************
*** 996,1001 ****
</blockquote>
</div>
! <div class="section" id="appendix-b-a-microcontroller-atmega-128-timer-subsystem">
! <h1><a name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
--- 996,1001 ----
</blockquote>
</div>
! <div class="section">
! <h1><a id="appendix-b-a-microcontroller-atmega-128-timer-subsystem" name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
***************
*** 1027,1031 ****
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
--- 1027,1031 ----
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
***************
*** 1058,1062 ****
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
--- 1058,1062 ----
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
***************
*** 1090,1094 ****
from the implementation of <tt class="docutils literal"><span class="pre">HplAtm128Timer1C</span></tt>)</p>
<pre class="literal-block">
! Compare[0] = HplAtm128Timer1P.CompareA;
Compare[1] = HplAtm128Timer1P.CompareB;
Compare[2] = HplAtm128Timer1P.CompareC;
--- 1090,1094 ----
from the implementation of <tt class="docutils literal"><span class="pre">HplAtm128Timer1C</span></tt>)</p>
<pre class="literal-block">
! Compare[0] = HplAtm128Timer1P.CompareA;
Compare[1] = HplAtm128Timer1P.CompareB;
Compare[2] = HplAtm128Timer1P.CompareC;
***************
*** 1134,1139 ****
to initialise the timer0 scaling factor.</p>
</div>
! <div class="section" id="appendix-c-a-mote-mica-family-timer-subsystem">
! <h1><a name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
<p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
--- 1134,1139 ----
to initialise the timer0 scaling factor.</p>
</div>
! <div class="section">
! <h1><a id="appendix-c-a-mote-mica-family-timer-subsystem" name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
<p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
***************
*** 1158,1162 ****
However, the set of dividers for timer 1 is limited to 1, 8,
64, 256 and 1024. So, when clocked at 2 or 4MHz, a divider of 1 is
! selected and timer 1 runs at 2 or 4MHz. To reflect this fact, the
HAL components exposing timer 1 are named <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> (rather than the <tt class="docutils literal"><span class="pre">CounterMicro16C</span></tt> <tt class="docutils literal"><span class="pre">AlarmMicro16C</span></tt>
--- 1158,1162 ----
However, the set of dividers for timer 1 is limited to 1, 8,
64, 256 and 1024. So, when clocked at 2 or 4MHz, a divider of 1 is
! selected and timer 1 runs at 2 or 4MHz. To reflect this fact, the
HAL components exposing timer 1 are named <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> (rather than the <tt class="docutils literal"><span class="pre">CounterMicro16C</span></tt> <tt class="docutils literal"><span class="pre">AlarmMicro16C</span></tt>
***************
*** 1164,1168 ****
<p>32-bit microsecond Counters and Alarms, named <tt class="docutils literal"><span class="pre">CounterMicro32C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt>, are created from <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
! <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> using the TransformAlarmC and TransformCounterC
utility components.</p>
<p>Three compare registers are available on timer1, so up to three instances
--- 1164,1168 ----
<p>32-bit microsecond Counters and Alarms, named <tt class="docutils literal"><span class="pre">CounterMicro32C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt>, are created from <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
! <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> using the TransformAlarmC and TransformCounterC
utility components.</p>
<p>Three compare registers are available on timer1, so up to three instances
***************
*** 1180,1184 ****
32768Hz, if possible. As with timer 1, the limited set of dividers makes
this impossible at some clock frequencies, so the 16-bit timer 3 HAL
! components are named <tt class="docutils literal"><span class="pre">CounterThree16C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt>. As
with timer 1, the rate of timer 3 is adjusted in software to
build 32-bit counter and 32-bit alarms, giving components
--- 1180,1184 ----
32768Hz, if possible. As with timer 1, the limited set of dividers makes
this impossible at some clock frequencies, so the 16-bit timer 3 HAL
! components are named <tt class="docutils literal"><span class="pre">CounterThree16C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt>. As
with timer 1, the rate of timer 3 is adjusted in software to
build 32-bit counter and 32-bit alarms, giving components
Index: tep115.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep115.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** tep115.html 21 Feb 2008 03:41:30 -0000 1.13
--- tep115.html 3 Feb 2009 23:07:32 -0000 1.14
***************
*** 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>Power Management of Non-Virtualised Devices</title>
<meta name="author" content="Kevin Klues, Vlado Handziski, Jan-Hinrich Hauer, Phil Levis" />
--- 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>Power Management of Non-Virtualised Devices</title>
<meta name="author" content="Kevin Klues, Vlado Handziski, Jan-Hinrich Hauer, Phil Levis" />
Index: tep116.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep116.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -C2 -d -r1.17 -r1.18
*** tep116.html 21 Feb 2008 05:05:04 -0000 1.17
--- tep116.html 3 Feb 2009 23:07:32 -0000 1.18
***************
*** 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>Packet Protocols</title>
<meta name="author" content="Philip Levis" />
--- 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>Packet Protocols</title>
<meta name="author" content="Philip Levis" />
Index: tep118.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep118.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** tep118.html 28 Mar 2008 17:17:01 -0000 1.11
--- tep118.html 3 Feb 2009 23:07:32 -0000 1.12
***************
*** 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>Dissemination of Small Values</title>
<meta name="author" content="Philip Levis and Gilman Tolle" />
--- 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>Dissemination of Small Values</title>
<meta name="author" content="Philip Levis and Gilman Tolle" />
Index: tep119.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep119.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -C2 -d -r1.14 -r1.15
*** tep119.html 15 Aug 2008 19:14:25 -0000 1.14
--- tep119.html 3 Feb 2009 23:07:32 -0000 1.15
***************
*** 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>Collection</title>
<meta name="author" content="Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis" />
--- 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>Collection</title>
<meta name="author" content="Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis" />
***************
*** 292,296 ****
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">> 2.1</td>
</tr>
--- 292,296 ----
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Final</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">> 2.1</td>
</tr>
***************
*** 313,321 ****
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>The memo documents the interfaces, components, and semantics used by
! collection protocol in TinyOS 2.x. Collection provides a best-effort,
! multihop delivery of packets to the root of a tree. There may be
! multiple tree roots in a network, and in this case the semantics
! are <em>anycast</em> delivery to at least one of the roots. A node sending
! a packet does not specify which root the packet is destined to.</p>
</div>
<div class="section">
--- 313,325 ----
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>The memo documents the interfaces, components, and semantics used by
! the collection protocols in TinyOS 2.x. Collection provides
! best-effort, multihop delivery of packets to one of a set of
! collection points. There may be multiple collection points in a
! network, and in this case the semantics are <em>anycast</em> delivery to at
! least one of the collection points. A node sending a packet does not
! specify which of the collection points the packet is destined to. The
! union of the paths from each node to one or more of the collection
! points forms a set of trees, and in this document we assume that
! collection points are the roots of these trees.</p>
</div>
<div class="section">
***************
*** 329,342 ****
to be able to inspect packets as they go by, either to gather
statistics, compute aggregates, or suppress redundant transmissions.</p>
! <p>Collection provides a best-effort, multihop delivery of packets to one
! of a network's tree roots: it is an <em>anycast</em> protocol. The semantics
! is that the protocol will make a reasonable effort to deliver the
! message to at least one of the roots in the network. By picking a
! parent node, a collection protocol inductively joins the tree its
! parent has joined. Delivery is best effort, and there can be
! duplicates delivered to one or more roots. Collection provides no
! ordering guarantees. Collection does not provide real-time guarantees,
! although specific implementations may extend the basic functionality
! to do so.</p>
<p>Given the limited state that nodes can store and a general need for
distributed tree building algorithms, collection protocols encounter
--- 333,346 ----
to be able to inspect packets as they go by, either to gather
statistics, compute aggregates, or suppress redundant transmissions.</p>
! <p>Collection provides best-effort, multihop delivery of packets to one
! of a network's tree roots: it is an <em>anycast</em> protocol. The
! semantics are that the protocol will make a reasonable effort to
! deliver the message to at least one of the roots in the network. By
! picking a parent node, a node implementing the collection protocol
! inductively joins the tree its parent has joined. Delivery is best
! effort, and there can be duplicates delivered to one or more roots.
! Collection provides no ordering or real-time guarantees, although
! specific implementations may extend the basic functionality to do
! so.</p>
<p>Given the limited state that nodes can store and a general need for
distributed tree building algorithms, collection protocols encounter
***************
*** 349,354 ****
a next hop.</li>
<li>Duplicate suppression, detecting and dealing with lost
! acknowledgments causing packets to replicate in the network,
! wasting capacity.</li>
<li>Link estimation, evaluating the link quality to single-hop
neighbors.</li>
--- 353,358 ----
a next hop.</li>
<li>Duplicate suppression, detecting and dealing with lost
! acknowledgments that can cause packets to replicate in the
! network, wasting capacity.</li>
<li>Link estimation, evaluating the link quality to single-hop
neighbors.</li>
***************
*** 364,375 ****
<div class="section">
<h1><a id="collection-interfaces" name="collection-interfaces">2. Collection interfaces</a></h1>
! <p>A node can perform four different roles in collection: sender,
! snooper, in-network processor, and receiver/root. Depending on their
! role, the nodes use different interfaces to interact with the
! collection component.</p>
<p>The collection infrastructure can be multiplexed among independent
! applications, by means of a collection identifier. While data traffic
! in the protocol is multiplexed through these identifiers, control
! traffic is not: all data traffic uses the same routing topology.</p>
<p>The nodes that generate data to be sent to the root are <em>senders</em>.
Senders use the Send interface [<a class="reference" href="#id1">1</a>] to send data to the root of
--- 368,381 ----
<div class="section">
<h1><a id="collection-interfaces" name="collection-interfaces">2. Collection interfaces</a></h1>
! <p>A node can perform four different roles in collection: sender (or
! source), snooper, in-network processor, and receiver (or
! root). Depending on their role, the nodes use different interfaces to
! interact with the collection component.</p>
<p>The collection infrastructure can be multiplexed among independent
! applications, by means of a collection identifier. The collection
! identifier is used to identify different data traffic at the sender,
! intermediate-nodes, or the receiver, much like port number in TCP. All
! data traffic, regardless of the collection identifier, use the same
! routing topology.</p>
<p>The nodes that generate data to be sent to the root are <em>senders</em>.
Senders use the Send interface [<a class="reference" href="#id1">1</a>] to send data to the root of
***************
*** 380,384 ****
message. The collection identifier is specified as a parameter
to Receive during instantiation.</p>
! <p>The nodes can process a packet that are in transit. These in-network
<em>processors</em> use the Intercept interface to receive and update a
packet. The collection identifier is specified as a parameter to
--- 386,390 ----
message. The collection identifier is specified as a parameter
to Receive during instantiation.</p>
! <p>The nodes can process a packet that is in transit. These in-network
<em>processors</em> use the Intercept interface to receive and update a
packet. The collection identifier is specified as a parameter to
***************
*** 404,412 ****
collection. The collection identifier is specified as a parameter to
Receive during instantiation.</p>
! <p>The set of all roots and the paths that
! lead to them form the collection routing infrastructure in the network.
! For any connected set of nodes implementing the collection protocol
! there is only one collection infrastructure, <em>i.e.</em>, all roots in this
! set active at the same time are part of the same infrastructure.</p>
<p>The RootControl interface configures whether a node is a
root:</p>
--- 410,418 ----
collection. The collection identifier is specified as a parameter to
Receive during instantiation.</p>
! <p>The set of all roots and the paths that lead to them form the
! collection routing infrastructure in the network. For any connected
! set of nodes implementing the collection protocol there is only one
! collection infrastructure, <em>i.e.</em>, all roots in this set active at the
! same time are part of the same infrastructure.</p>
<p>The RootControl interface configures whether a node is a
root:</p>
***************
*** 418,427 ****
}
</pre>
! <p>Both commands MUST return SUCCESS if the node is now in the specified
! state, and FAIL otherwise. For example, if a node is already a root
! and an application calls RootControl.setRoot(), the call will
return SUCCESS. If setRoot() returns SUCCESS, then a subsequent call
! to isRoot() MUST return TRUE. If unsetRoot() returns SUCCESS, then
! a subsequent call to isRoot() MUST return FALSE.</p>
</div>
<div class="section">
--- 424,433 ----
}
</pre>
! <p>The first two commands MUST return SUCCESS if the node is now in the
! specified state, and FAIL otherwise. For example, if a node is already
! a root and an application calls RootControl.setRoot(), the call will
return SUCCESS. If setRoot() returns SUCCESS, then a subsequent call
! to isRoot() MUST return TRUE. If unsetRoot() returns SUCCESS, then a
! subsequent call to isRoot() MUST return FALSE.</p>
</div>
<div class="section">
***************
*** 446,453 ****
}
</pre>
! <p>CollectionC MAY have additional interfaces. These additional
! interfaces MUST have default functions on all outgoing invocations
! (commands for uses, events for provides) of those interfaces so that
! it can operate properly if they are not wired.</p>
<p>Components SHOULD NOT wire to CollectionC.Send. The generic
component CollectionSenderC (described in section 3.1) provides
--- 452,459 ----
}
</pre>
! <p>CollectionC MAY have additional interfaces. All outgoing invocations
! (commands for uses, events for provides) of those interfaces MUST have
! default functions. Those default functions enable CollectionC to
! operate properly even when the additional interfaces are not wired.</p>
<p>Components SHOULD NOT wire to CollectionC.Send. The generic
component CollectionSenderC (described in section 3.1) provides
***************
*** 458,474 ****
different am_id_t values represent different protocols operating on
top of active messages. All packets sent with a particular
! collection_id_t generally have the same payload format, so that
snoopers, intercepters, and receivers can parse them properly.</p>
<p>ColletionC MUST NOT signal Receive.receive on non-root
! nodes. CollectionC MAY signal Receive.receive on a root node when a
! data packet successfully arrives at that node. If a root node calls
! Send, CollectionC MUST treat it as it if were a received packet. Note
! that the buffer swapping semantics of Receive.receive, when combined
! with the pass semantics of Send, require that CollectionC make a copy
! of the buffer if it signals Receive.receive.</p>
<p>If CollectionC receives a data packet to forward and it is not a root
! node, it MAY signal Intercept.forward.</p>
! <p>If CollectionC receives a data packet that a different node
! is supposed to forward, it MAY signal Snoop.receive.</p>
<p>RootControl allows a node to be made a collection tree root.
CollectionC SHOULD NOT configure a node as a root by default.</p>
--- 464,484 ----
different am_id_t values represent different protocols operating on
top of active messages. All packets sent with a particular
! collection_id_t generally SHOULD have the same payload format, so that
snoopers, intercepters, and receivers can parse them properly.</p>
<p>ColletionC MUST NOT signal Receive.receive on non-root
! nodes. CollectionC MUST signal Receive.receive on a root node when a
! unique (non-duplicate) data packet successfully arrives at that
! node. It MAY signal Receive.receive when a duplicate data packet
! successfully arrives. If a root node calls Send, CollectionC MUST
! treat it as it if were a received packet. Note that the buffer
! swapping semantics of Receive.receive, when combined with the pass
! semantics of Send, require that CollectionC make a copy of the buffer
! if it signals Receive.receive.</p>
<p>If CollectionC receives a data packet to forward and it is not a root
! node, it MAY signal Intercept.forward. CollectionC MAY signal
! Snoop.receive when it hears a packet which a different node is
! supposed to forward. For any given packet it receives, CollectionC
! MUST NOT signal more than one of the Snoop.receive, Receive.receive,
! and Intercept.forward events.</p>
<p>RootControl allows a node to be made a collection tree root.
CollectionC SHOULD NOT configure a node as a root by default.</p>
Index: tep121.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep121.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** tep121.html 14 Aug 2007 18:58:00 -0000 1.8
--- tep121.html 3 Feb 2009 23:07:32 -0000 1.9
***************
*** 819,823 ****
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 København Ø</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
--- 819,823 ----
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 K¯benhavn ÿ</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
***************
*** 825,829 ****
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 København Ø</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
--- 825,829 ----
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 K¯benhavn ÿ</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
***************
*** 833,837 ****
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 København Ø</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
--- 833,837 ----
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 K¯benhavn ÿ</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
Index: tep123.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep123.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** tep123.html 14 Aug 2007 18:57:59 -0000 1.10
--- tep123.html 3 Feb 2009 23:07:32 -0000 1.11
***************
*** 292,297 ****
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Draft</td></tr>
! <tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
--- 292,297 ----
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Final</td></tr>
! <tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">> 2.1</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">3-Aug-2006</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-02-28</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">3-Aug-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.15</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2009-01-16</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 322,325 ****
--- 322,337 ----
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
+ <p>A collection protocol delivers data to one of possibly several data
+ sinks, providing a many-to-one network layer. Collection is a
+ fundamental component of most sensor network applications. The
+ Collection Tree Protocol (CTP) is a reference Collection protocol in
+ TinyOS 2.x. The users use Collection interfaces described in TEP 119
+ <a class="footnote-reference" href="#id8" id="id1" name="id1">[3]</a> to use CTP in their applications.</p>
+ <p>In this TEP, after a brief discussion of Collection and CTP, we
+ specify the CTP routing and data frames. CTP uses routing frames to
+ update and build collection tree in the network. CTP uses data frames
+ to deliver application payload to the sink and to probe topology
+ inconsistencies.</p>
+ <p>All fields in this specification are in network byte order.</p>
</div>
<div class="section">
***************
*** 338,342 ****
<li>Provides a protocol dispatch field to support multiple higher-level
protocols.</li>
! <li>Has single-hop source and destination fields.</li>
</ol>
</blockquote>
--- 350,354 ----
<li>Provides a protocol dispatch field to support multiple higher-level
protocols.</li>
! <li>Has single-hop 16-bit source and destination fields.</li>
</ol>
</blockquote>
***************
*** 345,354 ****
takes for the node to send a unicast packet whose acknowledgment is
successfully received.</p>
! <p>CTP has several mechanisms in order to improve delivery reliability,
! but it does not promise 100% reliable delivery. It is best effort, but
! a best effort that <em>tries very hard.</em></p>
! <p>CTP is designed for relatively low traffic rates. Bandwidth-limited systems
! might benefit from a different protocol, which can, for example, pack
! multiple small frames into a single data-link packet.</p>
</div>
<div class="section">
--- 357,370 ----
takes for the node to send a unicast packet whose acknowledgment is
successfully received.</p>
! <p>CTP has several mechanisms in order to achieve high delivery
! reliability, but it does not promise 100% reliable delivery. It is a
! best effort protocol.</p>
! <p>CTP is designed for relatively low traffic rates such that there is
! enough space in the channel to transmit and receive routing frames
! even when the network is forwarding collection data
! frames. Bandwidth-limited systems or high data rate applications might
! benefit from a different protocol, which can, for example, pack
! multiple small frames into a single data-link packet or employ rate
! control mechanisms.</p>
</div>
<div class="section">
***************
*** 359,365 ****
nodes use link-level retransmissions. Given a choice of valid routes,
CTP SHOULD choose the one with the lowest ETX value. CTP represents
! ETX values as 16-bit fixed-point real numbers with a precision of
! hundredths. An ETX value of 451, for example, represents an ETX of
! 4.51, while an ETX value of 109 represents an ETX of 1.09.</p>
<p>Routing loops are a problem that can emerge in a CTP network. Routing
loops generally occur when a node choose a new route that has a
--- 375,381 ----
nodes use link-level retransmissions. Given a choice of valid routes,
CTP SHOULD choose the one with the lowest ETX value. CTP represents
! ETX values as 16-bit decimal fixed-point real numbers with a precision
! of tenths. An ETX value of 45, for example, represents an ETX of 4.5,
! while an ETX value of 10 represents an ETX of 1.</p>
<p>Routing loops are a problem that can emerge in a CTP network. Routing
loops generally occur when a node choose a new route that has a
***************
*** 378,388 ****
The value of this constant is implementation dependent.</p>
<p>Packet duplication is an additional problem that can occur in CTP.
! Packet duplication occurs when a node receives a data frame successfully
! and transmits an ACK, but the ACK is not received. The sender retransmits
! the packet, and the receiver receives it a second time. This can have
! disasterous effects over multiple hops, as the duplication is exponential.
! For example, if each hop on average produces one duplicate, then on the
! first hop there will be two packets, on the second there will be four,
! on the third there will be eight, etc.</p>
<p>Routing loops complicate duplicate suppression, as a routing loop may
cause a node to legitimately receive a packet more than once. Therefore,
--- 394,408 ----
The value of this constant is implementation dependent.</p>
<p>Packet duplication is an additional problem that can occur in CTP.
! Packet duplication occurs when a node receives a data frame
! successfully and transmits an ACK, but the ACK is not received. The
! sender retransmits the packet, and the receiver receives it a second
! time. This can have disasterous effects over multiple hops, as the
! duplication is exponential. For example, if each hop on average
! produces one duplicate, then on the first hop there will be two
! packets, on the second there will be four, on the third there will be
! eight, etc. CTP keeps a small cache of packet signature for the
! packets it has seen to detect packet duplicates. When a new packet
! arrives, if its signature results in cache hit, CTP drops the packet
! because it is a duplicate.</p>
<p>Routing loops complicate duplicate suppression, as a routing loop may
cause a node to legitimately receive a packet more than once. Therefore,
***************
*** 399,419 ****
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | THL |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | ETX |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | origin |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | seqno | collect_id |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data ...
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p>Field definitions are as follows:</p>
<blockquote>
<ul class="simple">
! <li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If a node with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.</li>
<li>THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0.</li>
--- 419,439 ----
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | THL |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | ETX |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | origin |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | seqno | collect_id |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data ...
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p>Field definitions are as follows:</p>
<blockquote>
<ul class="simple">
! <li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If the unicast destination of the data frame with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future. Nodes other than the link-layer destination of the data frame MAY respond to the P bit in the data frame.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.</li>
<li>THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0.</li>
***************
*** 422,426 ****
<li>seqno: Origin sequence number. The originating node sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
<li>collect_id: Higher-level protocol identifier. The origin sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
! <li>data: the data payload, of zero or more bytes. A node forwarding a data frame MUST NOT modify the data payload.</li>
</ul>
</blockquote>
--- 442,446 ----
<li>seqno: Origin sequence number. The originating node sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
<li>collect_id: Higher-level protocol identifier. The origin sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
! <li>data: the data payload, of zero or more bytes. A node forwarding a data frame MUST NOT modify the data payload. The length of the data field is computed by subtracting the size of the CTP header from the size of the link layer payload provided by the link layer.</li>
</ul>
</blockquote>
***************
*** 432,436 ****
asked to forward the same packet twice due to a routing loop, it will
drop the packet. However, if it suppresses packet instances, then it
! will route succesfully in the presence of transient loops unless the
THL happens to wrap around to a forwarded packet instance.</p>
<p>A node MUST send CTP data frames as unicast messages with link-layer
--- 452,456 ----
asked to forward the same packet twice due to a routing loop, it will
drop the packet. However, if it suppresses packet instances, then it
! will route successfully in the presence of transient loops unless the
THL happens to wrap around to a forwarded packet instance.</p>
<p>A node MUST send CTP data frames as unicast messages with link-layer
***************
*** 442,451 ****
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | parent |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | parent | ETX |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+
--- 462,471 ----
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | parent |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | parent | ETX |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+
***************
*** 454,458 ****
<blockquote>
<ul class="simple">
! <li>P: Same as data frame.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.</li>
<li>parent: The node's current parent.</li>
--- 474,478 ----
<blockquote>
<ul class="simple">
! <li>P: Same as data frame with one difference: Routing frames are broadcast so multiple nodes respond to the P bit in the routing frame.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.</li>
<li>parent: The node's current parent.</li>
***************
*** 469,472 ****
--- 489,493 ----
own, it MUST schedule a routing frame for transmission in the near
future.</p>
+ <p>A node MUST send CTP routing frames as broadcast messages.</p>
</div>
<div class="section">
***************
*** 488,496 ****
<h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
<p>The implementation uses two mechanisms to estimate the quality of a link:
! periodic LEEP <a class="footnote-reference" href="#id4" id="id1" name="id1">[1]</a> packets and data packets. The implementation sends
routing beacons as LEEP packets. These packets seed the neighbor table
with bidirectional ETX values. The implementation adapts its beaconing
rate based on network dynamics using an algorithm similar to the
! trickle dissemination protocol <a class="footnote-reference" href="#id5" id="id2" name="id2">[2]</a>. Beacons are sent on an exponentially
increasing randomized timer. The implementation resets the timer to a
small value when one or more of the following conditions are met:</p>
--- 509,517 ----
<h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
<p>The implementation uses two mechanisms to estimate the quality of a link:
! periodic LEEP <a class="footnote-reference" href="#id6" id="id2" name="id2">[1]</a> packets and data packets. The implementation sends
routing beacons as LEEP packets. These packets seed the neighbor table
with bidirectional ETX values. The implementation adapts its beaconing
rate based on network dynamics using an algorithm similar to the
! trickle dissemination protocol <a class="footnote-reference" href="#id7" id="id3" name="id3">[2]</a>. Beacons are sent on an exponentially
increasing randomized timer. The implementation resets the timer to a
small value when one or more of the following conditions are met:</p>
***************
*** 498,502 ****
<ol class="arabic simple">
<li>The routing table is empty (this also sets the P bit)</li>
! <li>The node's routing ETX increases by >= 1 trasmission</li>
<li>The node hears a packet with the P bit set</li>
</ol>
--- 519,523 ----
<ol class="arabic simple">
<li>The routing table is empty (this also sets the P bit)</li>
! <li>The node's routing ETX increases by >= 1 transmission</li>
<li>The node hears a packet with the P bit set</li>
</ol>
***************
*** 504,508 ****
<p>The implementation augments the LEEP link estimates with data
transmissions. This is a direct measure of ETX. Whenever the data path
! transmits a packet, it tells the link estimator the destimation and
whether it was successfully acknowledged. The estimator produces an
ETX estimate every 5 such transmissions, where 0 successes has an ETX
--- 525,529 ----
<p>The implementation augments the LEEP link estimates with data
transmissions. This is a direct measure of ETX. Whenever the data path
! transmits a packet, it tells the link estimator the destination and
whether it was successfully acknowledged. The estimator produces an
ETX estimate every 5 such transmissions, where 0 successes has an ETX
***************
*** 516,521 ****
the transmission rate, then it can quickly detect a broken link and
switch to another candidate neighbor.</p>
! <p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/le/LinkEstimatorP</span></tt> implements the
! link estimator. It couples LEEP-based and data-based estimates.</p>
</div>
<div class="section">
--- 537,543 ----
the transmission rate, then it can quickly detect a broken link and
switch to another candidate neighbor.</p>
! <p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/4bitle/LinkEstimatorP</span></tt> implements the
! link estimator. It couples LEEP-based and data-based estimates as
! described in <a class="footnote-reference" href="#id9" id="id4" name="id4">[4]</a>.</p>
</div>
<div class="section">
***************
*** 532,536 ****
<h2><a id="forwarding-engine" name="forwarding-engine">6.3 Forwarding Engine</a></h2>
<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpForwardingEngineP</span></tt> implements the
! forwarding engine. It has five repsonsibilities:</p>
<blockquote>
<ol class="arabic simple">
--- 554,558 ----
<h2><a id="forwarding-engine" name="forwarding-engine">6.3 Forwarding Engine</a></h2>
<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpForwardingEngineP</span></tt> implements the
! forwarding engine. It has five responsibilities:</p>
<blockquote>
<ol class="arabic simple">
***************
*** 607,624 ****
<div class="line">phone - +1 650 725 9046</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">
! <h1><a id="id3" name="id3">8. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id1" name="id4">[1]</a></td><td>TEP 124: Link Estimation Extension Protocol</td></tr>
</tbody>
</table>
! <table class="docutils footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="id5">[2]</a></td><td>Philip Levis, Neil Patel, David Culler and Scott Shenker. "A
Self-Regulating Algorithm for Code Maintenance and Propagation
in Wireless Sensor Networks." In Proceedings of the First USENIX
--- 629,664 ----
<div class="line">phone - +1 650 725 9046</div>
<div class="line">email - <a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a></div>
+ <div class="line"><br /></div>
+ <div class="line"><br /></div>
+ <div class="line">Alec Woo</div>
+ <div class="line">Arch Rock Corporation</div>
+ <div class="line">501 2nd St. Ste 410</div>
+ <div class="line">San Francisco, CA 94107-4132</div>
+ <div class="line"><br /></div>
+ <div class="line">email - <a class="reference" href="mailto:awoo@archrock.com">awoo@archrock.com</a></div>
+ <div class="line"><br /></div>
+ <div class="line"><br /></div>
+ <div class="line">Sukun Kim</div>
+ <div class="line">Samsung Electronics</div>
+ <div class="line">416 Maetan-3-dong, Yeongtong-Gu</div>
+ <div class="line">Suwon, Gyeonggi 443-742</div>
+ <div class="line">Korea, Republic of</div>
+ <div class="line"><br /></div>
+ <div class="line">phone - +82 10 3065 6836</div>
+ <div class="line">email - <a class="reference" href="mailto:sukun.kim@samsung.com">sukun.kim@samsung.com</a></div>
</div>
</div>
<div class="section">
! <h1><a id="id5" name="id5">8. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[1]</a></td><td>TEP 124: Link Estimation Extension Protocol</td></tr>
</tbody>
</table>
! <table class="docutils footnote" frame="void" id="id7" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[2]</a></td><td>Philip Levis, Neil Patel, David Culler and Scott Shenker. "A
Self-Regulating Algorithm for Code Maintenance and Propagation
in Wireless Sensor Networks." In Proceedings of the First USENIX
***************
*** 626,629 ****
--- 666,683 ----
</tbody>
</table>
+ <table class="docutils footnote" frame="void" id="id8" rules="none">
+ <colgroup><col class="label" /><col /></colgroup>
+ <tbody valign="top">
+ <tr><td class="label"><a class="fn-backref" href="#id1" name="id8">[3]</a></td><td>TEP 119: Collection.</td></tr>
+ </tbody>
+ </table>
+ <table class="docutils footnote" frame="void" id="id9" rules="none">
+ <colgroup><col class="label" /><col /></colgroup>
+ <tbody valign="top">
+ <tr><td class="label"><a class="fn-backref" href="#id4" name="id9">[4]</a></td><td>Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis.
+ "Four Bit Wireless Link Estimation." In Proceedings of the Sixth Workshop
+ on Hot Topics in Networks (HotNets VI), November 2007.</td></tr>
+ </tbody>
+ </table>
</div>
</div>
Index: tep124.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep124.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** tep124.html 14 Aug 2007 18:58:00 -0000 1.4
--- tep124.html 3 Feb 2009 23:07:32 -0000 1.5
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">05-Feb-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.4</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-02-28</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">05-Feb-2006</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">2009-01-31</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 328,356 ****
packet reception rate (PRR) estimates to packets. Other nodes hearing
these packets can combine the in-bound PRR values with their own
! in-bound values to compute bi-directional link quality.</p>
</div>
<div class="section">
<h1><a id="definitions" name="definitions">2. Definitions</a></h1>
<div class="section">
! <h2><a id="link-quality" name="link-quality">2.1 Link Quality</a></h2>
! <p>The link quality between a directed node pair (A,B) is the probability
! that a packet transmitted by A will be successfully received by B. The
! bidirectional link quality of an undirected node pair (A,B) is the
! product of the link quality of (A,B) and (B,A). This definition
! assumes independent link losses. It also includes the case when
! the link quality of (A,B) and (B,A) are different; this can occur
! due to local interference or noise.</p>
! </div>
! <div class="section">
! <h2><a id="in-bound-link-quality" name="in-bound-link-quality">2.2 In-bound Link Quality</a></h2>
<p>In a node pair (A,B), with B as the node of reference, in-bound link
quality is a value in the range of 0 to 255 that describes the quality
of the link from A to B estimated by B by counting the successfully
! received packets from A among all the transmitted packets or using
! link quality indicators such as LQI and RSSI provided by the radio on
! the node B, or some other methods.</p>
</div>
<div class="section">
! <h2><a id="out-bound-link-quality" name="out-bound-link-quality">2.3 Out-bound Link Quality</a></h2>
<p>In a node pair (A,B), with B as the node of reference, out-bound link
quality is defined as the quality of the link from B to A. B can
--- 328,353 ----
packet reception rate (PRR) estimates to packets. Other nodes hearing
these packets can combine the in-bound PRR values with their own
! in-bound values to compute bi-directional link quality. Thus, LEEP is
! a discovery and link table bootstrapping mechanism. The link quality
! is often fine-tuned using different mechanisms.</p>
! <p>Link quality estimates obtained using LEEP are often used as a
! bootstrapping values in the link quality table; data transmission
! statistics can later be used to make these estimates more accurate.</p>
</div>
<div class="section">
<h1><a id="definitions" name="definitions">2. Definitions</a></h1>
<div class="section">
! <h2><a id="in-bound-link-quality" name="in-bound-link-quality">2.1 In-bound Link Quality</a></h2>
<p>In a node pair (A,B), with B as the node of reference, in-bound link
quality is a value in the range of 0 to 255 that describes the quality
of the link from A to B estimated by B by counting the successfully
! received packets from A among all the packets transmitted by A. Thus,
! in-bound link quality is the empirical probability that a packet will
! be successfully received on a given link. A value of 255 represents a
! probability of 1 and a value of 0 represents a probability of 0 of
! successfully receiving a packet on a given link.</p>
</div>
<div class="section">
! <h2><a id="out-bound-link-quality" name="out-bound-link-quality">2.2 Out-bound Link Quality</a></h2>
<p>In a node pair (A,B), with B as the node of reference, out-bound link
quality is defined as the quality of the link from B to A. B can
***************
*** 360,363 ****
--- 357,372 ----
</div>
<div class="section">
+ <h2><a id="bi-directional-link-quality" name="bi-directional-link-quality">2.3 Bi-directional Link Quality</a></h2>
+ <p>LEEP does not define or compute bi-directional link quality. LEEP
+ provides a way to exchange sufficient information to compute in-bound
+ and out-bound link qualities. These two link qualities can be used to
+ compute the bi-directional link quality. One popular way to define the
+ bi-directional link quality between a node pair (A,B) as the
+ probability that a packet transmitted by A will be successfully
+ received and acknowledged by B. This approach computes the
+ bi-directional link quality of a node pair (A,B) as the product of the
+ link quality of (A,B) and (B,A).</p>
+ </div>
+ <div class="section">
<h2><a id="link-information-entry" name="link-information-entry">2.4 Link Information Entry</a></h2>
<p>Link Information Entry created by node k is a tuple (n,q) where q is
***************
*** 386,390 ****
neighbors. The Link Information entry on the LEEP frame allows the
receiver node to find the out-bound link quality to the transmitter
! node identified by the data link source address.</p>
</div>
<div class="section">
--- 395,406 ----
neighbors. The Link Information entry on the LEEP frame allows the
receiver node to find the out-bound link quality to the transmitter
! node identified by the data link source address. Thus, LEEP is also a
! way for nodes to discover new nodes and links in the network.</p>
! <p>Link quality estimation is inherently imperfect - data transmission
! and link quality estimation might be done at different timescales. The
! PRR for LEEP frames (broadcast) and data frames (unicast) might be
! different. So LEEP is better used as a link quality bootstrapping
! mechanism. The link quality estimate can be made more accurate later
! using data transmission statistics.</p>
</div>
<div class="section">
***************
*** 409,416 ****
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |nentry | rsrvd | seqno |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p>Field definitions:</p>
--- 425,432 ----
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |nentry | rsrvd | seqno |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p>Field definitions:</p>
***************
*** 428,435 ****
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | node id |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link quality |
+-+-+-+-+-+-+-+-+
--- 444,451 ----
<pre class="literal-block">
1
! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | node id |
! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link quality |
+-+-+-+-+-+-+-+-+
***************
*** 461,466 ****
the Link Information entries, it uses a round-robin policy to select
the entries to be exchanged that could not fit in the previous LEEP
! frame. The LEEP frames are transmitted whenever the CTP <a class="footnote-reference" href="#id4" id="id3" name="id3">[1]</a> beacons,
sent as a LEEP payload, are sent.</p>
</div>
<div class="section">
--- 477,485 ----
the Link Information entries, it uses a round-robin policy to select
the entries to be exchanged that could not fit in the previous LEEP
! frame. The LEEP frames are transmitted whenever the CTP <a class="footnote-reference" href="#id5" id="id3" name="id3">[1]</a> beacons,
sent as a LEEP payload, are sent.</p>
+ <p>Another reference implementation resides in
+ <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/net/4bitle</span></tt>. This implementation is described in
+ detail in <a class="footnote-reference" href="#id6" id="id4" name="id4">[2]</a>.</p>
</div>
<div class="section">
***************
*** 479,486 ****
<div class="section">
<h1><a id="citations" name="citations">6. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="id4">[1]</a></td><td>TEP 123: The Collection Tree Protocol.</td></tr>
</tbody>
</table>
--- 498,513 ----
<div class="section">
<h1><a id="citations" name="citations">6. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="id5">[1]</a></td><td>TEP 123: The Collection Tree Protocol.</td></tr>
! </tbody>
! </table>
! <table class="docutils footnote" frame="void" id="id6" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id4" name="id6">[2]</a></td><td>Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis.
! "Four Bit Wireless Link Estimation." In Proceedings of the Sixth Workshop
! on Hot Topics in Networks (HotNets VI), November 2007.</td></tr>
</tbody>
</table>
Index: tep125.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep125.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep125.html 16 Jun 2008 23:07:36 -0000 1.6
--- tep125.html 3 Feb 2009 23:07:32 -0000 1.7
***************
*** 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>TinyOS 802.15.4 Frames</title>
<meta name="author" content="Jonathan Hui, Philip Levis, and David Moss" />
--- 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>TinyOS 802.15.4 Frames</title>
<meta name="author" content="Jonathan Hui, Philip Levis, and David Moss" />
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">2-Feb-2007</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-16</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">2-Feb-2007</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.6</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-20</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 362,368 ****
+-------------------+---------+------------------------------+--------------+
</pre>
! <p>AM type is the same as in a T-frame. 6lowpan is the NALP code to identify
! this as a TinyOS packet. NALP codes must be in the range of 0-63.
! TinyOS uses code 63.</p>
<p>The AM type 63 is reserved for both T-Frames and I-Frames. A TinyOS
program MUST NOT use it.</p>
--- 362,368 ----
+-------------------+---------+------------------------------+--------------+
</pre>
! <p>AM type is the same as in a T-frame. 6lowpan is the NALP code to
! identify this as a TinyOS packet. NALP codes must be in the range of
! 0-63. TinyOS uses code 63 (0x3F).</p>
<p>The AM type 63 is reserved for both T-Frames and I-Frames. A TinyOS
program MUST NOT use it.</p>
Index: tep131.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep131.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep131.html 6 Nov 2007 10:32:53 -0000 1.1
--- tep131.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 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>Creating a New Platform for TinyOS 2.x</title>
<meta name="author" content="Martin Leopold" />
--- 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>Creating a New Platform for TinyOS 2.x</title>
<meta name="author" content="Martin Leopold" />
***************
*** 12,39 ****
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
! :Date: $Date$
! :Revision: $Revision$
! :Copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
-
- See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
- customize this style sheet.
*/
!
! /* used to remove borders from tables and images */
! .borderless, table.borderless td, table.borderless th {
! border: 0 }
!
! table.borderless td, table.borderless th {
! /* Override padding for "table.docutils td" with "! important".
! The right padding separates the table cells. */
! padding: 0 0.5em 0 0 ! important }
.first {
- /* Override more specific margin styles with "! important". */
margin-top: 0 ! important }
! .last, .with-subtitle {
margin-bottom: 0 ! important }
--- 12,30 ----
: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 }
***************
*** 48,59 ****
margin: 2em 5em ; }
! dl.docutils dd {
margin-bottom: 0.5em }
- /* Uncomment (and remove this text!) to get bold-faced definition list terms
- dl.docutils dt {
- font-weight: bold }
- */
-
div.abstract {
margin: 2em 5em }
--- 39,45 ----
margin: 2em 5em ; }
! dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
***************
*** 63,78 ****
text-align: center }
! div.admonition, div.attention, div.caution, div.danger, div.error,
! div.hint, div.important, div.note, div.tip, div.warning {
margin: 2em ;
border: medium outset ;
padding: 1em }
- div.admonition p.admonition-title, div.hint p.admonition-title,
- div.important p.admonition-title, div.note p.admonition-title,
- div.tip p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
--- 49,58 ----
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,
***************
*** 82,93 ****
font-family: sans-serif }
! /* Uncomment (and remove this text!) to get reduced vertical space in
! compound paragraphs.
! div.compound .compound-first, div.compound .compound-middle {
! margin-bottom: 0.5em }
!
! div.compound .compound-last, div.compound .compound-middle {
! margin-top: 0.5em }
! */
div.dedication {
--- 62,70 ----
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 {
***************
*** 101,109 ****
div.figure {
! margin-left: 2em ;
! margin-right: 2em }
div.footer, div.header {
- clear: both;
font-size: smaller }
--- 78,84 ----
div.figure {
! margin-left: 2em }
div.footer, div.header {
font-size: smaller }
***************
*** 121,125 ****
margin-left: 1em ;
border: medium outset ;
! padding: 1em ;
background-color: #ffffee ;
width: 40% ;
--- 96,100 ----
margin-left: 1em ;
border: medium outset ;
! padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
***************
*** 148,169 ****
margin: 2em }
! h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
! h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
! margin-top: 0.4em }
h1.title {
! text-align: center }
h2.subtitle {
text-align: center }
! hr.docutils {
! width: 75% }
!
! img.align-left {
! clear: left }
! img.align-right {
! clear: right }
ol.simple, ul.simple {
--- 123,151 ----
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 {
***************
*** 223,230 ****
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 205,220 ----
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;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 242,245 ****
--- 232,238 ----
white-space: nowrap }
+ span.option-argument {
+ font-style: italic }
+
span.pre {
white-space: pre }
***************
*** 248,288 ****
color: red }
! span.section-subtitle {
! /* font-size relative to parent (h1..h6 element) */
! font-size: 80% }
table.citation {
! border-left: solid 1px gray;
! margin-left: 1px }
table.docinfo {
! margin: 2em 4em }
!
! table.docutils {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
table.footnote {
! border-left: solid 1px black;
! margin-left: 1px }
! table.docutils td, table.docutils th,
! table.docinfo td, table.docinfo th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
! table.docutils th.field-name, table.docinfo th.docinfo-name {
font-weight: bold ;
text-align: left ;
! white-space: nowrap ;
! padding-left: 0 }
! h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
! h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
font-size: 100% }
! tt.docutils {
! background-color: #eeeeee }
ul.auto-toc {
--- 241,275 ----
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 {}
ul.auto-toc {
***************
*** 1642,1646 ****
async command void setControl(msp430_compare_control_t control );
async command void setControlAsCompare();
! async command void setControlAsCapture(bool low_to_high);
async command void enableEvents();
--- 1629,1633 ----
async command void setControl(msp430_compare_control_t control );
async command void setControlAsCompare();
! async command void setControlAsCapture(uint8_t cm);
async command void enableEvents();
***************
*** 1841,1845 ****
<dt>..PXA27</dt>
<dd>Parametriseret m. HplPXA27xUARTP (Init && HplPXA27xUART)
! -> init sætter en masse registre og enabler interrupt
HalPXA27xSerialP: HplPXA27xUART, Init, noget DMA noget</dd>
</dl>
--- 1828,1832 ----
<dt>..PXA27</dt>
<dd>Parametriseret m. HplPXA27xUARTP (Init && HplPXA27xUART)
! -> init sÊtter en masse registre og enabler interrupt
HalPXA27xSerialP: HplPXA27xUART, Init, noget DMA noget</dd>
</dl>
***************
*** 1853,1857 ****
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 København Ø</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
--- 1840,1844 ----
<div class="line">University of Copenhagen, Dept. of Computer Science</div>
<div class="line">Universitetsparken 1</div>
! <div class="line">DK-2100 K¯benhavn ÿ</div>
<div class="line">Denmark</div>
<div class="line"><br /></div>
Index: tep132.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep132.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep132.html 17 Jun 2008 15:06:32 -0000 1.1
--- tep132.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">15-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.0</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-05-15</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">15-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-17</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
Index: tep133.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep133.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep133.html 17 Jun 2008 15:06:32 -0000 1.1
--- tep133.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">15-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.0</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-05-15</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">15-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-17</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
Index: tep134.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep134.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep134.html 12 Jun 2008 13:02:08 -0000 1.1
--- tep134.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 12,39 ****
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
! :Date: $Date$
! :Revision: $Revision$
! :Copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
-
- See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
- customize this style sheet.
*/
!
! /* used to remove borders from tables and images */
! .borderless, table.borderless td, table.borderless th {
! border: 0 }
!
! table.borderless td, table.borderless th {
! /* Override padding for "table.docutils td" with "! important".
! The right padding separates the table cells. */
! padding: 0 0.5em 0 0 ! important }
.first {
- /* Override more specific margin styles with "! important". */
margin-top: 0 ! important }
! .last, .with-subtitle {
margin-bottom: 0 ! important }
--- 12,30 ----
: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 }
***************
*** 48,59 ****
margin: 2em 5em ; }
! dl.docutils dd {
margin-bottom: 0.5em }
- /* Uncomment (and remove this text!) to get bold-faced definition list terms
- dl.docutils dt {
- font-weight: bold }
- */
-
div.abstract {
margin: 2em 5em }
--- 39,45 ----
margin: 2em 5em ; }
! dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
***************
*** 63,78 ****
text-align: center }
! div.admonition, div.attention, div.caution, div.danger, div.error,
! div.hint, div.important, div.note, div.tip, div.warning {
margin: 2em ;
border: medium outset ;
padding: 1em }
- div.admonition p.admonition-title, div.hint p.admonition-title,
- div.important p.admonition-title, div.note p.admonition-title,
- div.tip p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
--- 49,58 ----
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,
***************
*** 82,93 ****
font-family: sans-serif }
! /* Uncomment (and remove this text!) to get reduced vertical space in
! compound paragraphs.
! div.compound .compound-first, div.compound .compound-middle {
! margin-bottom: 0.5em }
!
! div.compound .compound-last, div.compound .compound-middle {
! margin-top: 0.5em }
! */
div.dedication {
--- 62,70 ----
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 {
***************
*** 101,109 ****
div.figure {
! margin-left: 2em ;
! margin-right: 2em }
div.footer, div.header {
- clear: both;
font-size: smaller }
--- 78,84 ----
div.figure {
! margin-left: 2em }
div.footer, div.header {
font-size: smaller }
***************
*** 121,125 ****
margin-left: 1em ;
border: medium outset ;
! padding: 1em ;
background-color: #ffffee ;
width: 40% ;
--- 96,100 ----
margin-left: 1em ;
border: medium outset ;
! padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
***************
*** 148,169 ****
margin: 2em }
! h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
! h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
! margin-top: 0.4em }
h1.title {
! text-align: center }
h2.subtitle {
text-align: center }
! hr.docutils {
! width: 75% }
!
! img.align-left {
! clear: left }
! img.align-right {
! clear: right }
ol.simple, ul.simple {
--- 123,151 ----
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 {
***************
*** 223,230 ****
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 205,220 ----
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;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 242,245 ****
--- 232,238 ----
white-space: nowrap }
+ span.option-argument {
+ font-style: italic }
+
span.pre {
white-space: pre }
***************
*** 248,288 ****
color: red }
! span.section-subtitle {
! /* font-size relative to parent (h1..h6 element) */
! font-size: 80% }
table.citation {
! border-left: solid 1px gray;
! margin-left: 1px }
table.docinfo {
! margin: 2em 4em }
!
! table.docutils {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
table.footnote {
! border-left: solid 1px black;
! margin-left: 1px }
! table.docutils td, table.docutils th,
! table.docinfo td, table.docinfo th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
! table.docutils th.field-name, table.docinfo th.docinfo-name {
font-weight: bold ;
text-align: left ;
! white-space: nowrap ;
! padding-left: 0 }
! h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
! h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
font-size: 100% }
! tt.docutils {
! background-color: #eeeeee }
ul.auto-toc {
--- 241,275 ----
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 {}
ul.auto-toc {
***************
*** 312,318 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">13-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-05-26</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">13-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-12</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
Index: tep135.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep135.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep135.html 20 Jun 2008 19:12:21 -0000 1.1
--- tep135.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 289,293 ****
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Network Protocol Working Group</td>
</tr>
! <tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
--- 289,293 ----
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Network Protocol Working Group</td>
</tr>
! <tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Informational</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">19-June-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-20</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">19-June-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-24</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 316,323 ****
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
! <p>In this TEP, we document the Active Message Type <a class="footnote-reference" href="#id4" id="id3" name="id3">[1]</a> allocations
! in TinyOS 2.1.</p>
<div class="section">
! <h2><a id="unreserved-pool-0x80-0xff" name="unreserved-pool-0x80-0xff">2. Unreserved pool (0x80 - 0xFF)</a></h2>
<p>The unreserved pool is in the range 128-255 (0x80-0xFF). Applications
distributed with TinyOS use AM IDs in this range. Protocols and
--- 316,326 ----
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
! <p>TinyOS network protocols use allocated Active Message Type <a class="citation-reference" href="#tep-116" id="id3" name="id3">[TEP_116]</a>
! to prevent AM ID conflict between different protocols. <a class="citation-reference" href="#tep-4" id="id4" name="id4">[TEP_4]</a>
! describes how AM IDs are allocated for a TinyOS network protocol. In
! this TEP, we document the AM ID allocations in TinyOS 2.1.</p>
! </div>
<div class="section">
! <h1><a id="unreserved-pool-128-255-0x80-0xff" name="unreserved-pool-128-255-0x80-0xff">2. Unreserved pool 128-255 (0x80 - 0xFF)</a></h1>
<p>The unreserved pool is in the range 128-255 (0x80-0xFF). Applications
distributed with TinyOS use AM IDs in this range. Protocols and
***************
*** 327,365 ****
</div>
<div class="section">
! <h2><a id="reserved-pool-0x00-0x7f" name="reserved-pool-0x00-0x7f">3. Reserved pool (0x00 - 0x7F)</a></h2>
<p>The reserved pool is in the range 0-127 (0x00-0x7F). The AM IDs in
this range are used by protocols distributed with TinyOS.</p>
<p>Here is a list of allocations for TinyOS 2.1:</p>
<pre class="literal-block">
! * 0x70 - 0x7F are reserved for collection protocols maintained by
! the Network Protocol Working Group.
! 0x70 - CTP routing beacon and LEEP (''tos/lib/net/ctp'', TEP 119, 123, and 124)
! 0x71 - CTP data packets (''tos/lib/net/ctp'', TEP 119, 123)
! 0x72 - CTP debug messages (''tos/lib/net/ctp'')
! 0x73 - MultiHopLQI routing beacon (''tos/lib/net/lqi'')
! 0x74 - MultiHopLQI data packets (''tos/lib/net/lqi'')
! 0x75 - MultiHopLQI debug messages (''tos/lib/net/lqi'')
! * 0x60 - 0x6F are reserved for dissemination protocols maintained by
! the Network Protocol Working Group.
! 0x60 - Drip (''tos/lib/net/drip'', TEP 118)
! 0x61 - DIP (''tos/lib/net/dip'', TEP 118)
! * 0x50 - 0x5F are reserved for Deluge (''tos/lib/net/Deluge'')
maintained by the Network Protocol Working Group.
! 0x50 - AM_DELUGEADVMSG (advertisements)
! 0x51 - AM_DELUGEREQMSG (requests)
! 0x52 - AM_DELUGEDATAMSG (data)
! 0x53 - DELUGE_AM_FLASH_VOL_MANAGER (flash volume manager)
! 0x54 - DELUGE_AM_DELUGE_MANAGER (deluge manger)
! * 0x3F - TinyOS NALP code (TEP 125) reserved by the Core Working
Group.
</pre>
</div>
- </div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">4. Author's Address</a></h1>
--- 330,377 ----
</div>
<div class="section">
! <h1><a id="reserved-pool-0-127-0x00-0x7f" name="reserved-pool-0-127-0x00-0x7f">3. Reserved pool 0-127 (0x00 - 0x7F)</a></h1>
<p>The reserved pool is in the range 0-127 (0x00-0x7F). The AM IDs in
this range are used by protocols distributed with TinyOS.</p>
<p>Here is a list of allocations for TinyOS 2.1:</p>
<pre class="literal-block">
! * 0x70 - 0x75 are reserved for collection protocols [TEP_119]_
! maintained by the Network Protocol Working Group.
! For CTP (''tos/lib/net/ctp'') [TEP_123]_ and LEEP [TEP_124]_
! 0x70 - AM_CTP_ROUTING CTP (Routing beacon)
! 0x71 - AM_CTP_DATA CTP (Data packets)
! 0x72 - AM_CTP_DEBUG CTP (Debug messages)
! For MultiHopLQI (''tos/lib/net/lqi'')
! 0x73 - AM_LQI_BEACON_MSG (Routing beacon)
! 0x74 - AM_LQI_DATA_MSG MultiHopLQI (Data packets)
! 0x75 - AM_LQI_DEBUG MultiHopLQI (Debug messages)
! * 0x60 - 0x62 are reserved for dissemination protocols [TEP_118]_
! maintained by the Network Protocol Working Group.
! For Drip (''tos/lib/net/drip'')
! 0x60 - AM_DISSEMINATION_MESSAGE
! 0x61 - AM_DISSEMINATION_PROBE_MESSAGE
!
! For DIP (''tos/lib/net/dip'')
! 0x62 - AM_DIP
!
! * 0x50 - 0x54 are reserved for Deluge (''tos/lib/net/Deluge'')
maintained by the Network Protocol Working Group.
! 0x50 - AM_DELUGEADVMSG (Advertisements)
! 0x51 - AM_DELUGEREQMSG (Requests)
! 0x52 - AM_DELUGEDATAMSG (Data)
! 0x53 - DELUGE_AM_FLASH_VOL_MANAGER (Flash volume manager)
! 0x54 - DELUGE_AM_DELUGE_MANAGER (Deluge manger)
! * 0x3E - AM_TIMESYNCMSG for FTSP (''tos/lib/ftsp'') reserved by the
! Core Working Group.
!
! * 0x3F - TinyOS NALP code [TEP_125]_ reserved by the Core Working
Group.
</pre>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">4. Author's Address</a></h1>
***************
*** 385,395 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="tep-4">[TEP_4]</a></td><td>TEP 4: Active Message ID Allocation for Network Protocols and Applications</td></tr>
</tbody>
</table>
! <table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="id4">[1]</a></td><td>TEP 116: Packet Protocols</td></tr>
</tbody>
</table>
--- 397,437 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep-4">[TEP_4]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> TEP 4: Active Message ID Allocation for Network Protocols and Applications</td></tr>
</tbody>
</table>
! <table class="docutils citation" frame="void" id="tep-116" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="tep-116">[TEP_116]</a></td><td>TEP 116: Packet Protocols</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-118" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="tep-118">[TEP_118]</a></td><td>TEP 118: Dissemination of Small Values</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-119" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="tep-119">[TEP_119]</a></td><td>TEP 119: Collection</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-123" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="tep-123">[TEP_123]</a></td><td>TEP 123: The Collection Tree Protocol (CTP)</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-124" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="tep-124">[TEP_124]</a></td><td>TEP 124: The Link Estimation Exchange Protocol (LEEP)</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-125" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="tep-125">[TEP_125]</a></td><td>TEP 125: TinyOS 802.15.4 Frames</td></tr>
</tbody>
</table>
Index: tep2.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep2.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** tep2.html 18 Jun 2008 19:04:43 -0000 1.13
--- tep2.html 3 Feb 2009 23:07:32 -0000 1.14
***************
*** 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>Hardware Abstraction Architecture</title>
<meta name="author" content="Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, Cory Sharp, Adam Wolisz, David Culler, 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>Hardware Abstraction Architecture</title>
<meta name="author" content="Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, Cory Sharp, Adam Wolisz, David Culler, David Gay" />
Index: tep4.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep4.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep4.html 20 Jun 2008 19:12:21 -0000 1.1
--- tep4.html 3 Feb 2009 23:07:32 -0000 1.2
***************
*** 292,297 ****
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Draft</td></tr>
! <tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
--- 292,297 ----
</tr>
<tr><th class="docinfo-name">Status:</th>
! <td>Final</td></tr>
! <tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">> 2.1</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
***************
*** 299,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">07-May-2008</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.6</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-20</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 299,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">07-May-2008</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">2008-11-04</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 316,320 ****
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
! <p>In order to document the Active Message Type <a class="footnote-reference" href="#id3" id="id2" name="id2">[1]</a>, also known as
Active Message Identifier (AM ID), used by the protocols and to
prevent AM ID conflicts between applications and protocols distributed
--- 316,320 ----
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
! <p>In order to document the Active Message Type <a class="citation-reference" href="#tep-116" id="id2" name="id2">[TEP_116]</a>, also known as
Active Message Identifier (AM ID), used by the protocols and to
prevent AM ID conflicts between applications and protocols distributed
***************
*** 358,364 ****
* Working Group responsible for the protocol
* Name of the protocol and relevant TEPs
! * Location of the protocol in TinyOS source tree</p>
! <p>Upon receiving this information, the chair of the Network Protocol
! Working Group will allocate an AM ID and document the allocation.</p>
</div>
<div class="section">
--- 358,368 ----
* Working Group responsible for the protocol
* Name of the protocol and relevant TEPs
! * Location of the protocol in TinyOS source tree
! * Number of AM IDs requested and description of each ID
! * Specific AM ID request (only if necessary)</p>
! <p>Upon receiving this request, the chair of the Network Protocol Working
! Group will allocate the AM ID(s) and document the allocation. If the
! request is made for a specific AM ID, the chair of the Network
! Protocol Work Group will try to accommodate that request.</p>
</div>
<div class="section">
***************
*** 374,378 ****
<p>For each TinyOS 2.x release that introduces a new protocol or use of a
new AM ID, the chair of the Network Protocol Working Group creates a
! new TEP that lists all the AM ID allocations for that release.</p>
</div>
<div class="section">
--- 378,384 ----
<p>For each TinyOS 2.x release that introduces a new protocol or use of a
new AM ID, the chair of the Network Protocol Working Group creates a
! new Informational TEP that lists all the AM ID allocations for that
! release. The TEP is finalized at the time of the release. <a class="citation-reference" href="#tep-135" id="id3" name="id3">[TEP_135]</a>
! documents the AM IDs allocated for TinyOS 2.1.</p>
</div>
<div class="section">
***************
*** 401,408 ****
</tbody>
</table>
! <table class="docutils footnote" frame="void" id="id3" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="id3">[1]</a></td><td>TEP 116: Packet Protocols</td></tr>
</tbody>
</table>
--- 407,420 ----
</tbody>
</table>
! <table class="docutils citation" frame="void" id="tep-116" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="tep-116">[TEP_116]</a></td><td>TEP 116: Packet Protocols</td></tr>
! </tbody>
! </table>
! <table class="docutils citation" frame="void" id="tep-135" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id3" name="tep-135">[TEP_135]</a></td><td>TEP 135: Active Message ID Allocation in TinyOS 2.1</td></tr>
</tbody>
</table>
More information about the Tinyos-2-commits
mailing list