[Tinyos-2-commits]
CVS: tinyos-2.x/doc/html overview.html, 1.1.2.10,
1.1.2.11 tep1.html, 1.1.2.8, 1.1.2.9 tep101.html, 1.1.2.13,
1.1.2.14 tep102.html, 1.1.2.10, 1.1.2.11 tep103.html, 1.1.2.9,
1.1.2.10 tep106.html, 1.1.2.9, 1.1.2.10 tep107.html, 1.1.2.10,
1.1.2.11 tep108.html, 1.1.2.11, 1.1.2.12 tep109.html, 1.1.2.6,
1.1.2.7 tep110.html, 1.1.2.6, 1.1.2.7 tep111.html, 1.1.2.11,
1.1.2.12 tep112.html, 1.1.2.6, 1.1.2.7 tep113.html, 1.1.2.8,
1.1.2.9 tep114.html, 1.1.2.5, 1.1.2.6 tep115.html, 1.1.2.8,
1.1.2.9 tep116.html, 1.1.2.9, 1.1.2.10 tep117.html, 1.1.2.5,
1.1.2.6 tep118.html, 1.1.2.3, 1.1.2.4 tep119.html, 1.1.2.3,
1.1.2.4 tep120.html, 1.1.2.3, 1.1.2.4 tep121.html, 1.1.2.4,
1.1.2.5 tep123.html, 1.1.2.1, 1.1.2.2 tep2.html, 1.1.2.6,
1.1.2.7 tep3.html, 1.1.2.7, 1.1.2.8
Phil Levis
scipio at users.sourceforge.net
Tue Oct 24 17:47:59 PDT 2006
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv22504
Modified Files:
Tag: tinyos-2_0_devel-BRANCH
overview.html tep1.html tep101.html tep102.html tep103.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 tep123.html tep2.html tep3.html
Log Message:
Regenerated TEPs.
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep101.html,v
retrieving revision 1.1.2.13
retrieving revision 1.1.2.14
diff -C2 -d -r1.1.2.13 -r1.1.2.14
*** tep101.html 12 Oct 2006 17:02:37 -0000 1.1.2.13
--- tep101.html 25 Oct 2006 00:47:56 -0000 1.1.2.14
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
<title>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, 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>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay" />
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">20-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.7</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-07-14</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>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">20-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-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: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep102.html,v
retrieving revision 1.1.2.10
retrieving revision 1.1.2.11
diff -C2 -d -r1.1.2.10 -r1.1.2.11
*** tep102.html 18 Oct 2006 17:27:17 -0000 1.1.2.10
--- tep102.html 25 Oct 2006 00:47:56 -0000 1.1.2.11
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.9: 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" />
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.6</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-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>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-18</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>
***************
*** 319,324 ****
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
--- 319,324 ----
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
***************
*** 326,331 ****
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">
--- 326,331 ----
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">
***************
*** 341,345 ****
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
--- 341,345 ----
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
***************
*** 350,354 ****
<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
--- 350,354 ----
<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
***************
*** 358,376 ****
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>
<p>Examples of precision are millisecond, a cycle of a 32kHz clock, and
! microseconds. All precisions are in "binary" units with respect to
! one second. That is, one second contains 1024 binary milliseconds,
! 32768 32kHz ticks, or 1048576 microseconds. This TEP emphasizes
! millisecond and 32kHz tick precisions while reasonably accommodating
! other precisions.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
for timer interfaces and components SHOULD be 32-bits. That is, for
--- 358,376 ----
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>
<p>Examples of precision are millisecond, a cycle of a 32kHz clock, and
! microseconds. All precisions presented in this TEP are in "binary"
! units with respect to one second. That is, one second contains 1024
! binary milliseconds, 32768 32kHz ticks, or 1048576 microseconds.
! This TEP emphasizes millisecond and 32kHz tick precisions while
! reasonably accommodating other precisions.</p>
<p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit. The width
for timer interfaces and components SHOULD be 32-bits. That is, for
***************
*** 398,410 ****
TMicro -- written in the standard Timer.h header like this:</p>
<pre class="literal-block">
! typedef struct { } TMilli;
! typedef struct { } T32khz;
! typedef struct { } TMicro;
</pre>
<p>Note that the precision names are expressed as either frequency or
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">
--- 398,410 ----
TMicro -- written in the standard Timer.h header like this:</p>
<pre class="literal-block">
! typedef struct { } TMilli; // 1024 ticks per second
! typedef struct { } T32khz; // 32768 ticks per second
! typedef struct { } TMicro; // 1048576 ticks per second
</pre>
<p>Note that the precision names are expressed as either frequency or
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">
***************
*** 420,426 ****
advanced user components.</p>
</div>
! <div class="section" id="counter">
! <h2><a name="counter">Counter</a></h2>
! <p>A Counter component will increase the width of a low-level hardware timer
by wrapping the overflow event and incrementing its higher order bits.
These higher order bits are considered extra state over the HPL register
--- 420,426 ----
advanced user components.</p>
</div>
! <div class="section">
! <h2><a id="counter" name="counter">Counter</a></h2>
! <p>A Counter component will increase the width of a low-level hardware timer
by wrapping the overflow event and incrementing its higher order bits.
These higher order bits are considered extra state over the HPL register
***************
*** 440,464 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
! </dl>
! <p>isOverflowPending()</p>
! <blockquote>
! return TRUE if the overflow flag is set for this counter, i.e., if and
only if an overflow interrupt 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. It is expected
! that the underlying hardware platforms sets the overflow flag when
! appropriate.</blockquote>
! <dl class="docutils">
! <dt>clearOverflow() </dt>
<dd>cancel the pending overflow interrupt 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.
--- 440,461 ----
</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 interrupt 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. It is expected
! that the underlying hardware platform sets the overflow flag when
! appropriate.</dd>
! <dt>clearOverflow()</dt>
<dd>cancel the pending overflow interrupt 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.
***************
*** 483,495 ****
</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 occurred.</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>
--- 480,492 ----
</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 occurred.</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>
***************
*** 503,509 ****
detecting when a short alarm elapses prematurely.</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
--- 500,506 ----
detecting when a short alarm elapses prematurely.</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
***************
*** 513,518 ****
</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
--- 510,515 ----
</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
***************
*** 534,539 ****
</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
--- 531,536 ----
</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
***************
*** 546,555 ****
</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"
--- 543,552 ----
</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"
***************
*** 576,617 ****
</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 occurred.</dd>
! <dt>isRunning() </dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot() </dt>
<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>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt) </dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</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
--- 573,614 ----
</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 occurred.</dd>
! <dt>isRunning()</dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot()</dt>
<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>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt)</dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</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
***************
*** 628,637 ****
}
! generic configuration Alarm${P}${W}C
{
provides interface Alarm< T${P}, uint${W}_t >;
}
</pre>
! <p>Instantiating a Alarm${P}${W}C component provides a new and
independent Alarm. If the platform presents a limited number of
Alarm resources, then allocating more Alarms in an application than
--- 625,634 ----
}
! generic configuration Alarm${P}${W}C()
{
provides interface Alarm< T${P}, uint${W}_t >;
}
</pre>
! <p>Instantiating an Alarm${P}${W}C component provides a new and
independent Alarm. If the platform presents a limited number of
Alarm resources, then allocating more Alarms in an application than
***************
*** 648,652 ****
}
! generic configuration Alarm32khz8C
{
provides interface Alarm< T32khz, uint8_t >;
--- 645,649 ----
}
! generic configuration Alarm32khz8C()
{
provides interface Alarm< T32khz, uint8_t >;
***************
*** 658,676 ****
together.</p>
</div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
! <dd>TimerMilliC
BusyWaitMicroC</dd>
</dl>
! <div class="section" id="timermillic">
! <h2><a name="timermillic">TimerMilliC</a></h2>
<pre class="literal-block">
! configuration TimerMilliC
{
provides interface Init;
! provides interface Timer<TMilli>[uint8_t num];
! provides interface LocalTime<TMilli>;
}
</pre>
--- 655,672 ----
together.</p>
</div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
! <dd>HilTimerMilliC
BusyWaitMicroC</dd>
</dl>
! <div class="section">
! <h2><a id="hiltimermillic" name="hiltimermillic">HilTimerMilliC</a></h2>
<pre class="literal-block">
! configuration HilTimerMilliC
{
provides interface Init;
! provides interface Timer<TMilli> as TimerMilli[ uint8_t num ];
}
</pre>
***************
*** 678,685 ****
new unique timer number. This timer number is used to index the
TimerMilli parameterised interface. UQ_TIMER_MILLI is defined in
! Timer.h.</p>
</div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
--- 674,682 ----
new unique timer number. This timer number is used to index the
TimerMilli parameterised interface. UQ_TIMER_MILLI is defined in
! Timer.h. HilTimerMilliC is used by the generic component
! TimerMilliC 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
***************
*** 694,699 ****
</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>
--- 691,696 ----
</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>
***************
*** 708,713 ****
<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">
--- 705,710 ----
<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">
***************
*** 719,724 ****
</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>
--- 716,721 ----
</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>
***************
*** 732,737 ****
</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">
--- 729,734 ----
</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">
***************
*** 743,752 ****
</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(),
--- 740,749 ----
</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(),
***************
*** 776,781 ****
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">
--- 773,778 ----
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">
***************
*** 808,813 ****
</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>
--- 805,810 ----
</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>
***************
*** 822,827 ****
</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>
--- 819,824 ----
</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>
***************
*** 853,864 ****
<blockquote>
<ul class="simple">
! <li><tt class="docutils literal"><span class="pre">Alarm32khzC.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<T32khz,uint16_t></span></tt>
! and <tt class="docutils literal"><span class="pre">Alarm<T32khz,uint32_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">AlarmMilliC.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<TMilli,uint32_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">BusyWait32khzC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">BusyWait<T32khz,uint16_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">BusyWaitMicroC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">BusyWait<TMicro,uint16_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">Counter32khzC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<T32khz,uint16_t></span></tt>,
! <tt class="docutils literal"><span class="pre">Counter<T32khz,uint32_t></span></tt>, and <tt class="docutils literal"><span class="pre">LocalTime<T32khz></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">CounterMilliC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<TMilli,uint32_t></span></tt> and <tt class="docutils literal"><span class="pre">LocalTime<TMilli></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">Timer<TMilli></span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
--- 850,863 ----
<blockquote>
<ul class="simple">
! <li><tt class="docutils literal"><span class="pre">Alarm32khz16C.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<T32khz,uint16_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">Alarm32khz32C.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<T32khz,uint32_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">AlarmMilli16C.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<TMilli,uint16_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">AlarmMilli32C.nc</span></tt> is generic and provides a new <tt class="docutils literal"><span class="pre">Alarm<TMilli,uint32_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">BusyWait32khzC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">BusyWait<T32khz,uint16_t></span></tt></li>
<li><tt class="docutils literal"><span class="pre">BusyWaitMicroC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">BusyWait<TMicro,uint16_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">Counter32khz16C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<T32khz,uint16_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">Counter32khz32C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<T32khz,uint32_t></span></tt></li>
! <li><tt class="docutils literal"><span class="pre">CounterMilli16C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter<TMilli,uint16_t></span></tt></li>
! <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">Timer<TMilli></span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
***************
*** 891,896 ****
</blockquote>
</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 ----
</blockquote>
</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>
***************
*** 920,925 ****
</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">
***************
*** 997,1002 ****
</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>
***************
*** 1028,1032 ****
/// 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
***************
*** 1059,1063 ****
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
***************
*** 1097,1102 ****
</pre>
</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,
--- 1096,1101 ----
</pre>
</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,
***************
*** 1120,1124 ****
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>
--- 1119,1123 ----
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>
***************
*** 1141,1145 ****
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 when
building the 32-bit counter and 32-bit alarms, giving components
--- 1140,1144 ----
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 when
building the 32-bit counter and 32-bit alarms, giving components
Index: tep106.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep106.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep106.html 27 Jun 2006 20:23:04 -0000 1.1.2.9
--- tep106.html 25 Oct 2006 00:47:56 -0000 1.1.2.10
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</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>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-08-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>
***************
*** 525,529 ****
<p>A scheduler MUST provide a parameterized TaskBasic interface.
If a call to TaskBasic.postTask() returns SUCCESS, the scheduler MUST run it
! eventually. The scheduler MUST return SUCCESS to a TaskBasic.postTask()
operation unless it is not the first call to TaskBasic.postTask() since
that task's TaskBasic.runTask() event has been signaled. The
--- 525,530 ----
<p>A scheduler MUST provide a parameterized TaskBasic interface.
If a call to TaskBasic.postTask() returns SUCCESS, the scheduler MUST run it
! eventually, so that starvation is not a concern. The scheduler MUST
! return SUCCESS to a TaskBasic.postTask()
operation unless it is not the first call to TaskBasic.postTask() since
that task's TaskBasic.runTask() event has been signaled. The
***************
*** 559,563 ****
}
</pre>
! <p>When a component declares a task with the task keyword in nesC, it
is implicitly declaring that it uses an instance of the TaskBasic
interface: the task body is the runTask event. When a component uses the
--- 560,564 ----
}
</pre>
! <p>When a component declares a task with the <tt class="docutils literal"><span class="pre">task</span></tt> keyword in nesC, it
is implicitly declaring that it uses an instance of the TaskBasic
interface: the task body is the runTask event. When a component uses the
***************
*** 583,591 ****
directory: this will replace the default. The scheduler component
provides a wire-through of the desired scheduler implementation. All
! scheduler implementations SHOULD provide a parameterize TaskBasic
interface, as SchedulerBasicP does; this supports nesC post statements
! and task declarations. If a scheduler does not provide the TaskBasic
! interface, compiling applications requires modifying the standard
! ncc scheduler parameters (as described in Appendix A). All scheduler
implementations MUST provide the Scheduler interface.</p>
<p>For example, imagine a hypothetical scheduler that provides earliest
--- 584,592 ----
directory: this will replace the default. The scheduler component
provides a wire-through of the desired scheduler implementation. All
! scheduler implementations MUST provide a parameterize TaskBasic
interface, as SchedulerBasicP does; this supports nesC post statements
! and task declarations and enables TinyOS core systems to operate
! properly. Generally, TinyOS core code needs to be able to run unchanged
! with new scheduler implementations. All scheduler
implementations MUST provide the Scheduler interface.</p>
<p>For example, imagine a hypothetical scheduler that provides earliest
***************
*** 664,672 ****
}
</pre>
<p>If the scheduler provides two instances of the same task interface,
their unique keys are based on the name of the interface as the
scheduler presents it (the "as" keyword). For example, imagine
a scheduler which provides two instances of TaskBasic: standard
! tasks and high-priority tasks. The scheduler always selects a task
for the high priority queue before the standard queue:</p>
<pre class="literal-block">
--- 665,677 ----
}
</pre>
+ <p>The requirement that basic tasks not be subject to starvation
+ requires that a scheduler supporting EDF tasks must ensure that
+ basic tasks run eventually even if there is an unending stream of
+ short deadline tasks to run.</p>
<p>If the scheduler provides two instances of the same task interface,
their unique keys are based on the name of the interface as the
scheduler presents it (the "as" keyword). For example, imagine
a scheduler which provides two instances of TaskBasic: standard
! tasks and high-priority tasks. The scheduler usually selects a task
for the high priority queue before the standard queue:</p>
<pre class="literal-block">
***************
*** 677,682 ****
}
</pre>
! <p>A component that uses a high priority task would then wire to
! TaskHighPriority with the key "TinySchedulerC.TaskHighPriority":</p>
<pre class="literal-block">
configuration SomethingElseC {}
--- 682,688 ----
}
</pre>
! <p>It cannot always select a high priority task because that could
! starve basic tasks. A component that uses a high priority task would
! wire to TaskHighPriority with the key "TinySchedulerC.TaskHighPriority":</p>
<pre class="literal-block">
configuration SomethingElseC {}
Index: tep108.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep108.html,v
retrieving revision 1.1.2.11
retrieving revision 1.1.2.12
diff -C2 -d -r1.1.2.11 -r1.1.2.12
*** tep108.html 7 Sep 2006 13:07:01 -0000 1.1.2.11
--- tep108.html 25 Oct 2006 00:47:56 -0000 1.1.2.12
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
<title>Resource Arbitration</title>
<meta name="authors" content="Kevin Klues Philip Levis David Gay David Culler Vlado Handziski" />
--- 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>Resource Arbitration</title>
<meta name="authors" content="Kevin Klues Philip Levis David Gay David Culler Vlado Handziski" />
***************
*** 11,39 ****
/*
:Author: David Goodger
! :Contact: goodger at python.org
! :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 }
--- 11,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,56 ****
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 }
*/
--- 39,47 ----
margin: 2em 5em ; }
! dd {
margin-bottom: 0.5em }
! /* Uncomment (& remove this text!) to get bold-faced definition list terms
! dt {
font-weight: bold }
*/
***************
*** 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,
--- 54,63 ----
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 {
--- 67,75 ----
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 }
--- 83,89 ----
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% ;
--- 101,105 ----
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 {
--- 128,156 ----
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,229 ****
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
! margin-right: 2em }
span.classifier {
--- 210,225 ----
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 {
***************
*** 241,244 ****
--- 237,243 ----
white-space: nowrap }
+ span.option-argument {
+ font-style: italic }
+
span.pre {
white-space: pre }
***************
*** 247,285 ****
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% }
ul.auto-toc {
list-style-type: none }
--- 246,281 ----
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 {
list-style-type: none }
***************
*** 312,318 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">28-Mar-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-21</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>
--- 308,314 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">28-Mar-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.11</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-09-08</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: tep109.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep109.html,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -C2 -d -r1.1.2.6 -r1.1.2.7
*** tep109.html 27 Jun 2006 20:23:04 -0000 1.1.2.6
--- tep109.html 25 Oct 2006 00:47:56 -0000 1.1.2.7
***************
*** 5,10 ****
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
! <title>Sensor Boards</title>
! <meta name="author" content="David Gay, Phil Levis, Wei Hong, and Joe Polastre" />
<style type="text/css">
--- 5,10 ----
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
! <title>Sensors and Sensor Boards</title>
[...995 lines suppressed...]
+ signal SplitControl.startDone( SUCCESS );
+ }
+
+ command error_t SplitControl.stop() {
+ call SCK.makeInput();
+ call SCK.clr();
+ call DATA.makeInput();
+ call DATA.clr();
+ call PWR.clr();
+ post stopTask();
+ return SUCCESS;
+ }
+
+ task void stopTask() {
+ signal SplitControl.stopDone( SUCCESS );
+ }
+ }
+ </pre>
</div>
</div>
Index: tep111.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep111.html,v
retrieving revision 1.1.2.11
retrieving revision 1.1.2.12
diff -C2 -d -r1.1.2.11 -r1.1.2.12
*** tep111.html 4 Oct 2006 20:01:45 -0000 1.1.2.11
--- tep111.html 25 Oct 2006 00:47:56 -0000 1.1.2.12
***************
*** 304,308 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jul-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.14</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-04</td>
--- 304,308 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jul-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.15</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-04</td>
Index: tep114.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep114.html,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -C2 -d -r1.1.2.5 -r1.1.2.6
*** tep114.html 27 Jun 2006 20:23:04 -0000 1.1.2.5
--- tep114.html 25 Oct 2006 00:47:56 -0000 1.1.2.6
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">30-Oct-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-09</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>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">30-Oct-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.4</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-08-30</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>
***************
*** 473,499 ****
</div>
<div class="section">
- <h2><a id="metadata-and-shifting" name="metadata-and-shifting">3.3 Metadata and Shifting</a></h2>
- <p>Generally, simple types are made up of octets. However, sensor values
- often have levels of precision besides a multiple of 8. Any value
- contained in a simple type MUST be left shifted so that it covers as
- much of the type's range as possible. For example, if a 12-bit ADC
- reading is presented as a 16-bit Read interface:</p>
- <pre class="literal-block">
- component DemoSensorC {
- provides interface Read<uint16_t>;
- }
- </pre>
- <p>then the 12-bit value MUST be shifted left so that its range is 0x0000
- - 0xfff0, rather than 0x0000 - 0x0fff. A device MAY specify the
- precision of one of its interfaces with the DeviceMetadata interface:</p>
- <pre class="literal-block">
- interface DeviceMetadata {
- command uint8_t getSignificantBits();
- }
- </pre>
- <p>The name of the instance of DeviceMetadata SHOULD clearly indicate
- which interface it corresponds to.</p>
- </div>
- <div class="section">
<h2><a id="single-phase-scalar-i-o" name="single-phase-scalar-i-o">3.4 Single-Phase Scalar I/O</a></h2>
<p>Some devices may have their state cached or readily available. In
--- 473,476 ----
Index: tep115.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep115.html,v
retrieving revision 1.1.2.8
retrieving revision 1.1.2.9
diff -C2 -d -r1.1.2.8 -r1.1.2.9
*** tep115.html 19 Sep 2006 06:18:51 -0000 1.1.2.8
--- tep115.html 25 Oct 2006 00:47:56 -0000 1.1.2.9
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.5: 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" />
***************
*** 11,39 ****
/*
:Author: David Goodger
! :Contact: goodger at python.org
! :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 }
--- 11,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,56 ****
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 }
*/
--- 39,47 ----
margin: 2em 5em ; }
! dd {
margin-bottom: 0.5em }
! /* Uncomment (& remove this text!) to get bold-faced definition list terms
! dt {
font-weight: bold }
*/
***************
*** 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,
--- 54,63 ----
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 {
--- 67,75 ----
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 }
--- 83,89 ----
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% ;
--- 101,105 ----
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 {
--- 128,156 ----
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,229 ****
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
! margin-right: 2em }
span.classifier {
--- 210,225 ----
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 {
***************
*** 241,244 ****
--- 237,243 ----
white-space: nowrap }
+ span.option-argument {
+ font-style: italic }
+
span.pre {
white-space: pre }
***************
*** 247,285 ****
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% }
ul.auto-toc {
list-style-type: none }
--- 246,281 ----
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 {
list-style-type: none }
***************
*** 308,314 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jan-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-05-16</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jan-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.4</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-09-19</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List
Index: tep116.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep116.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep116.html 27 Jun 2006 20:23:04 -0000 1.1.2.9
--- tep116.html 25 Oct 2006 00:47:56 -0000 1.1.2.10
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-22</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>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.11</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-27</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: tep120.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep120.html,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -C2 -d -r1.1.2.3 -r1.1.2.4
*** tep120.html 27 Jun 2006 20:23:04 -0000 1.1.2.3
--- tep120.html 25 Oct 2006 00:47:56 -0000 1.1.2.4
***************
*** 315,321 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">17-April-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-09</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Alliance <tinyos-alliance at mail.millennium.berkeley.edu></td>
--- 315,321 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">17-April-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-25</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Alliance <tinyos-alliance at mail.millennium.berkeley.edu></td>
***************
*** 759,771 ****
<div class="section">
<h1><a id="funding" name="funding">9. Funding</a></h1>
- <p>As with the IETF, individuals are responsible for their own costs,
- which primarily involve meetings, travel, and generation of work
- products. Membership participation will involve attendance at
- Alliance meetings. Registration fees will be charged to cover costs
- associated with adminstration of the meetings.</p>
- <p>Companies and institutions are encouraged to contribute financial and
- in-kind support. It will be essential that companies provide initial
- funding to create the legal structure and to establish basic IT
- capabilities to host the web site and working groups.</p>
<p>Initially, we expect that there are no full time employees in the
Alliance and that funding needs are limited to such items as lawyer's
--- 759,762 ----
***************
*** 773,785 ****
requires full time support personnel, the funding structure will have
to be re-visited.</p>
<p>To maintain the focus on technical excellence and meritocracy, we want
to avoid the heavy-handed quid-pro-quo seen in many industrial
consortiums where funding determines influence. The best use of funds
and the best form of influence is direct contribution to the work
! products of the Alliance. We will permit targeted contributions
! toward specific working groups or technical capabilities.</p>
! <p>We seek to keep overall structure lean, mostly volunteer.
! Focus on desired impact and recognition, rather than control.</p>
! <p>Institutional members
will pay an annual membership fee. In some cases, a
contributing corporate member may provide in-kind services
--- 764,788 ----
requires full time support personnel, the funding structure will have
to be re-visited.</p>
+ <p>As with the IETF, individuals are responsible for their own costs,
+ which primarily involve meetings, travel, and generation of work
+ products. The Alliance is predominantly a volunteer organization.
+ Membership participation will involve attendance at
+ Alliance meetings. Registration fees will be charged to cover costs
+ associated with adminstration of the meetings.</p>
<p>To maintain the focus on technical excellence and meritocracy, we want
to avoid the heavy-handed quid-pro-quo seen in many industrial
consortiums where funding determines influence. The best use of funds
and the best form of influence is direct contribution to the work
! products of the Alliance.
! To keep the structure of the Alliance and its operations minimalist
! and lean, membership focuses on desired impact and recognition, rather
! than control. We want the best way to influence the direction of the Alliance
! to be to contribute technical work and demonstrate leadership, rather than
! try to control what individuals can or cannot contribute.</p>
! <p>Companies and institutions are encouraged to contribute financial and
! in-kind support. It will be essential that companies provide initial
! funding to create the legal structure and to establish basic IT
! capabilities to host the web site and working groups.
! Institutional members
will pay an annual membership fee. In some cases, a
contributing corporate member may provide in-kind services
***************
*** 791,834 ****
where such a membership may be prohibited or unwanted.
The costs of meetings, such as the TinyOS
! technology exchange, will be covered through registration fees.</p>
! <p>Individuals are responsible
! for their own costs such as
! for travel, meeting costs, or costs for contributing
! software or documentation to the Alliance. The Alliance
! is primarily a volunteer organization.</p>
</div>
<div class="section">
<h1><a id="work-products" name="work-products">10. Work Products</a></h1>
! <p>Code base
! Stable, robust core release
! Rapidly evolving, innovative extensions
! Reference Implementations
! Tools
! Data
! Documentation
! Standard proposals
! Marketing and Promotion
! Testing and Compliance
! Assessments
! Applications and uses of technology
! Educational Materials</p>
</div>
<div class="section">
<h1><a id="conclusions" name="conclusions">11. Conclusions</a></h1>
! <p>The time has come to create an organizational structure to allow the effort to grow
! Beyond the Berkeley + Others
! It is a balancing act
! Stability vs Innovation
! Broad Participation vs Strong Requirements
! Uniform Licensing vs Institutional Differences
! Goal is to help to community to work together
! Not a forum for maneuvering and intrigue
! Focus on consensus building and technical soundness
! Minimal mechanism to resolve rare differences
! Focus on working groups and individual contributions
! with architectural and organization oversight
! Be pragmatic on participation
! DonÂ’t have to make deep commitments to participate
! CanÂ’t expect broad guarantees in return</p>
</div>
<div class="section">
--- 794,864 ----
where such a membership may be prohibited or unwanted.
The costs of meetings, such as the TinyOS
! technology exchange, will be covered through registration fees and
! not by institutional membership fees.</p>
</div>
<div class="section">
<h1><a id="work-products" name="work-products">10. Work Products</a></h1>
! <p>The broad mission of the Alliance calls for a broad range of
! work products.</p>
! <p>Foremost among these are a set of TEPs documenting
! systems and protocols as well as TEPs that provide guidance
! and knowledge to the community. Technical documentation will have
! robust and open reference implementations for the community to
! use, refine, improve, and discuss. These reference implementations
! will not preclude alternative, compatibile implementations which may
! have additional features or optimizations. The Alliance Working Groups
! will periodically produce periodic releases of these reference
! implementations for the community to use and improve.</p>
! <p>The Alliance will support community contributions
! of innovative extensions and systems by providing a CVS repository
! to store them.
! In order to keep these contributions organized for users, the
! Steering Committee may nominate one or more people to caretake
! the repository by setting minimal guidelines for the use of
! the directory structure and migrating code as it joins the core
! or falls into disuse.</p>
! <p>To make these technological resources more accessible and useful
! to a broad embedded networks community, the Alliance will be
! dedicated to providing a set of educational materials. This
! includes introductory tutorials, documentation of core systems,
! simple and complex example applications, and user guides.</p>
! <p>In addition to educational sample applications, whose purpose
! is to teach new developers about the internals and workings of
! the technology, the Alliance will develop and make available
! several end-user applications and tools. The goal is to improve
! the accessibility of the technology to end-users while
! demonstrating its effectiveness. Historical examples of such applications
! include Surge and TinyDB. An important part of this effort is
! good documentation for users who are not expert programmers, as well
! as tools and graphical environments.</p>
</div>
<div class="section">
<h1><a id="conclusions" name="conclusions">11. Conclusions</a></h1>
! <p>By focusing on consensus building and technical excellence, the
! Alliance seeks to avoid being a forum for political and economic
! positioning. It will achieve this by focusing on working groups
! and the contributions of individuals, while not taking strong
! positions on the benefits or drawbacks of different approaches.
! The variety of application domains sensornets are used in and
! the huge differences in requirements mean that having a suite
! of solutions, rather than a single one, is often not only
! desirable but essential.</p>
! <p>Over the past five years, low-power embedded sensor networks have
! grown from research prototypes to working systems that are being
! actively deployed. Furthermore, there is a vibrant research community
! that actively works to deploy these systems and collaborate with
! industry, making advances quickly accessible and usable. A great
! catalyst to this growth has been the presence of a large community
! around a shared, free code base.</p>
! <p>The time has come to create an organizational structure to
! allow the effort to grow further. As sensornets become more widespread,
! contributions and advancements will be from an increasingly broad
! demographic of users, and bringing them all together will speed
! progress and improve the potential benefit these systems can bring
! to society. This focus on bringing disparate groups together lies
! at the heart of the Alliance. Rather than depend on strong requirements,
! it depends on broad collaboration and participation, placing a minimalist
! set of expectations that will encourage the exchange of ideas and
! technology.</p>
</div>
<div class="section">
***************
*** 837,840 ****
--- 867,871 ----
<div class="line">Philippe Bonnet <<a class="reference" href="mailto:bonnet.p@gmail.com">bonnet.p@gmail.com</a>></div>
<div class="line">David Culler <<a class="reference" href="mailto:culler@cs.berkeley.edu">culler@cs.berkeley.edu</a>></div>
+ <div class="line">David Culler <dculler at archrock.com>,</div>
<div class="line">Deborah Estrin <<a class="reference" href="mailto:destrin@cs.ucla.edu">destrin@cs.ucla.edu</a>></div>
<div class="line">Ramesh Govindan <<a class="reference" href="mailto:ramesh@usc.edu">ramesh@usc.edu</a>></div>
***************
*** 848,854 ****
<div class="line">Adam Wolisz <<a class="reference" href="mailto:awo@ieee.org">awo@ieee.org</a>></div>
</div>
- <div class="line-block">
- <div class="line">David Culler <dculler at archrock.com>,</div>
- </div>
</div>
</div>
--- 879,882 ----
Index: tep123.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep123.html,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -C2 -d -r1.1.2.1 -r1.1.2.2
*** tep123.html 15 Aug 2006 19:58:18 -0000 1.1.2.1
--- tep123.html 25 Oct 2006 00:47:56 -0000 1.1.2.2
***************
*** 304,310 ****
<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.2</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-07-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>
--- 304,310 ----
<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.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-25</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>
***************
*** 419,424 ****
<blockquote>
<ul class="simple">
! <li>C: Congestion notification. If a node is receiving packets faster than it can forward them, it MAY set the C field to notify other nodes. If a node hears a packet from node N with the C bit set, it MUST NOT transmit CTP data frames to N until it hears a packet from N with the C bit cleared.</li>
! <li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If a node hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future if it has a valid route.</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>
<li>ETX: The ETX routing metric of the single-hop sender. When a node transmits a CTP data frame, it MUST put the ETX value of its route through the single-hop destination in the ETX field. If a node receives a packet with a lower gradient than its own, then it MUST schedule a routing frame in the near future.</li>
--- 419,424 ----
<blockquote>
<ul class="simple">
! <li>C: Congestion notification. If a node is receiving packets faster than it can forward them, it MAY set the C field to notify other nodes. If a node hears a packet from node <em>N</em> with the C bit set, it MUST NOT transmit CTP data frames to <em>N</em> until it hears a packet from N with the C bit cleared.</li>
! <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>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>
<li>ETX: The ETX routing metric of the single-hop sender. When a node transmits a CTP data frame, it MUST put the ETX value of its route through the single-hop destination in the ETX field. If a node receives a packet with a lower gradient than its own, then it MUST schedule a routing frame in the near future.</li>
***************
*** 426,430 ****
<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.</li>
</ul>
</blockquote>
--- 426,430 ----
<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>
***************
*** 435,441 ****
of routing loops. If a node suppresses origin packets, then if
asked to forward the same packet twice due to a routing loop, it will
! drop the packet. However, if it suppresses packet instances, then
! unless the THL has wrapped around to the identical value it had
! on previous times around.</p>
<p>A node MUST send CTP data frames as unicast messages with link-layer
acknowledgments enabled.</p>
--- 435,441 ----
of routing loops. If a node suppresses origin packets, then if
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
acknowledgments enabled.</p>
***************
*** 448,454 ****
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |C|P| reserved | address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | address | ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
--- 448,454 ----
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |C|P| reserved | parent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | parent | ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
***************
*** 460,464 ****
<li>C: Same as data frame.</li>
<li>P: Same as data frame.</li>
! <li>address: The node's active message address.</li>
<li>metric: The node's current routing metric value.</li>
</ul>
--- 460,464 ----
<li>C: Same as data frame.</li>
<li>P: Same as data frame.</li>
! <li>parent: The node's current parent.</li>
<li>metric: The node's current routing metric value.</li>
</ul>
***************
*** 467,471 ****
reflect the address' new metric. If a node's ETX value changes
significantly, then CTP SHOULD transmit a broadcast frame soon thereafter
! to notify other nodes, which might change their routes.</p>
</div>
</div>
--- 467,549 ----
reflect the address' new metric. If a node's ETX value changes
significantly, then CTP SHOULD transmit a broadcast frame soon thereafter
! to notify other nodes, which might change their routes. The parent
! field acts as a surrogate for the single-hop destination field of
! a data packet: a parent can detect when a child's ETX is significantly
! below its own. When a parent hears a child advertise an ETX below its
! own, it MUST schedule a routing frame for transmission in the near
! future.</p>
! </div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
! <p>An implementation of CTP can be found in the tos/lib/net/ctp directory
! of TinyOS 2.0. This section describes the structure of that implementation
! and is not in any way part of the specification of CTP.</p>
! <p>This implementation has three major subcomponents:</p>
! <p>1) A <strong>link estimator</strong>, which is responsible for estimating the
! single-hop ETX of communication with single-hop neighbors.</p>
! <p>2) A <strong>routing engine</strong>, which uses link estimates as well as
! network-level information to decide which neighbor is the next
! routing hop.</p>
! <p>3) A <strong>forwarding engine</strong>, which maintains a queue of packets
! to send. It decides when and if to send them. The name is a little
! misleading: the forwarding engine is responsible for forwarded traffic
! as well as traffic generated on the node.</p>
! <div class="section">
! <h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
! <p>The link estimator estimates the ETX to single-hop neighbors.
! The implementation uses two mechanisms to estimate the quality of a link:
! periodic broadcast packets and data packets. The estimator itself
! only generates broadcast packets. For data traffic, it depends on
! other components telling it about acknowledged and unacknowledged
! transmissions.</p>
! <p>The periodic broadcast packets have sequence numbers, which the
! estimator uses to estimate the sender-to-receiver packet reception
! rate (PRR). The data payload of periodic broadcast packets contain
! these estimates. Therefore, when node A receives a link estimation
! broadcast message from node B, it can use the packet header to
! estimate the B-to-A PRR and the packet payload to update B's
! estimate of the A-to-B PRR.</p>
! <p>Multiplying these two values gives a <em>bidirectional</em> PRR, or
! an estimate of the probability that if A transmits a packet to B,
! B will successfully hear and acknowledge the packet and A will
! hear the acknowledgment. The inverse of the bidirecitonal PRR
! is the ETX.</p>
! <p>CTP link estimation adapts its beaconing rate to be slow when
! its routing table is stable and faster when changes occur.
! It adjusts the beaconing interval using an algorithm similar
! to the trickle dissemination protocol[<a href="#id1" name="id2"><span class="problematic" id="id2">2_</span></a>]. CTP sends beacons
! more often when one of three conditions occurs:</p>
! <blockquote>
! <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>
! </blockquote>
! <p>CTP also estimates link quality using 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 of 6.</p>
! <p>The estimator combines the beacon and data estimates by incorporating
! them into an exponentially weighted moving average. Beacon-based
! estimates seed the neighbor table. The expectation is that the low
! beacon rate in a stable network means that for a selected route,
! data estimates will outweigh beacon estimates. Additionally, as
! the rate at which CTP collects data estimates is proportional to
! the transmission rate, then it can quickly detect a broken link and
! switch to another candidate neighbor.</p>
! </div>
! <div class="section">
! <h2><a id="routing-engine" name="routing-engine">6.2 Routing Engine</a></h2>
! <p>The</p>
! </div>
! </div>
! <div class="system-messages section">
! <h1>Docutils System Messages</h1>
! <div class="system-message" id="id1">
! <p class="system-message-title">System Message: <a name="id1">ERROR/3</a> (<tt class="docutils">txt/tep123.txt</tt>, line 232); <em><a href="#id2">backlink</a></em></p>
! Unknown target name: "2".</div>
</div>
</div>
More information about the Tinyos-2-commits
mailing list