[Tinyos-2-commits] CVS: tinyos-2.x/doc/html overview.html, 1.1.2.7,
1.1.2.8 tep1.html, 1.1.2.4, 1.1.2.5 tep101.html, 1.1.2.7,
1.1.2.8 tep102.html, 1.1.2.5, 1.1.2.6 tep103.html, 1.1.2.1,
1.1.2.2 tep106.html, 1.1.2.5, 1.1.2.6 tep107.html, 1.1.2.6,
1.1.2.7 tep108.html, 1.1.2.5, 1.1.2.6 tep109.html, 1.1.2.4,
1.1.2.5 tep110.html, 1.1.2.4, 1.1.2.5 tep111.html, 1.1.2.6,
1.1.2.7 tep112.html, 1.1.2.4, 1.1.2.5 tep113.html, 1.1.2.4,
1.1.2.5 tep114.html, 1.1.2.3, 1.1.2.4 tep115.html, 1.1.2.5,
1.1.2.6 tep116.html, 1.1.2.5, 1.1.2.6 tep117.html, 1.1.2.1,
1.1.2.2 tep118.html, 1.1.2.1, 1.1.2.2 tep119.html, 1.1.2.1,
1.1.2.2 tep120.html, 1.1.2.1, 1.1.2.2 tep121.html, 1.1.2.2,
1.1.2.3 tep2.html, 1.1.2.4, 1.1.2.5 tep3.html, 1.1.2.5, 1.1.2.6
Phil Levis
scipio at users.sourceforge.net
Fri Jun 9 14:12:22 PDT 2006
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv16293/html
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 tep2.html tep3.html
Log Message:
Regenerated HTML with new CSS.
Fixed formatting in 120, 116.
Index: overview.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/overview.html,v
retrieving revision 1.1.2.7
retrieving revision 1.1.2.8
diff -C2 -d -r1.1.2.7 -r1.1.2.8
*** overview.html 18 May 2006 23:08:14 -0000 1.1.2.7
--- overview.html 9 Jun 2006 21:12:17 -0000 1.1.2.8
***************
*** 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>TinyOS 2.0 Overview</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>TinyOS 2.0 Overview</title>
<meta name="author" content="Philip Levis" />
***************
*** 302,308 ****
is detailed in TEP (TinyOS Enhancement Proposal) documents.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
! <p>TinyOS 2.0 is a clear slate redesign and re-implementation of TinyOS.
Its development was motivated by our belief that many aspects of 1.x
strain to meet requirements and uses that were not foreseen
--- 302,308 ----
is detailed in TEP (TinyOS Enhancement Proposal) documents.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
! <p>TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS.
Its development was motivated by our belief that many aspects of 1.x
strain to meet requirements and uses that were not foreseen
***************
*** 324,329 ****
document and describe these abstractions.</p>
</div>
! <div class="section" id="platforms-hardware-abstraction">
! <h1><a name="platforms-hardware-abstraction">2. Platforms/Hardware Abstraction</a></h1>
<p>Platforms exist in the <tt class="docutils literal"><span class="pre">tos/platforms</span></tt> subdirectory. In TinyOS 2.0, a
<em>platform</em> is a collection of <em>chips</em> and some glue code that connects
--- 324,329 ----
document and describe these abstractions.</p>
</div>
! <div class="section">
! <h1><a id="platforms-hardware-abstraction" name="platforms-hardware-abstraction">2. Platforms/Hardware Abstraction</a></h1>
<p>Platforms exist in the <tt class="docutils literal"><span class="pre">tos/platforms</span></tt> subdirectory. In TinyOS 2.0, a
<em>platform</em> is a collection of <em>chips</em> and some glue code that connects
***************
*** 369,379 ****
<li>intelmote2</li>
<li>mica2</li>
<li>micaZ</li>
<li>telosb</li>
</ul>
</blockquote>
</div>
! <div class="section" id="scheduler">
! <h1><a name="scheduler">3. Scheduler</a></h1>
<p>As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO
policy. However, tasks in 2.0 operate slightly differently than in
--- 369,382 ----
<li>intelmote2</li>
<li>mica2</li>
+ <li>mica2dot</li>
<li>micaZ</li>
<li>telosb</li>
+ <li>tinynode</li>
+ <li>btnode3</li>
</ul>
</blockquote>
</div>
! <div class="section">
! <h1><a id="scheduler" name="scheduler">3. Scheduler</a></h1>
<p>As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO
policy. However, tasks in 2.0 operate slightly differently than in
***************
*** 403,408 ****
in TEP 106: Schedulers and Tasks[<a class="reference" href="#tep106">TEP106</a>].</p>
</div>
! <div class="section" id="booting-initialization">
! <h1><a name="booting-initialization">4. Booting/Initialization</a></h1>
<p>TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface
<tt class="docutils literal"><span class="pre">StdControl</span></tt> has been split into two interfaces: <tt class="docutils literal"><span class="pre">Init</span></tt> and
--- 406,411 ----
in TEP 106: Schedulers and Tasks[<a class="reference" href="#tep106">TEP106</a>].</p>
</div>
! <div class="section">
! <h1><a id="booting-initialization" name="booting-initialization">4. Booting/Initialization</a></h1>
<p>TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface
<tt class="docutils literal"><span class="pre">StdControl</span></tt> has been split into two interfaces: <tt class="docutils literal"><span class="pre">Init</span></tt> and
***************
*** 413,427 ****
initializing the scheduler, hardware, and software, the boot sequence
signals the <tt class="docutils literal"><span class="pre">Boot.booted</span></tt> event. The top-level application component
! should handle this event and start services accordingly. Details on
the new boot sequence can be found in TEP 107: TinyOS 2.x Boot
Sequence[<a class="reference" href="#tep107">TEP107</a>].</p>
</div>
! <div class="section" id="virtualization">
! <h1><a name="virtualization">5. Virtualization</a></h1>
<p>TinyOS 2.0 is written with nesC 1.2, which introduces the concept
of a 'generic' or instantiable component. Generic modules allow
TinyOS to have reusable data structures, such as bit vectors and
queues, which simplify development. More importantly, generic
! configurations allow services to encapsulate complex wiring
relationships for clients that need them.</p>
<p>In practice, this means that many basic TinyOS services are now
--- 416,430 ----
initializing the scheduler, hardware, and software, the boot sequence
signals the <tt class="docutils literal"><span class="pre">Boot.booted</span></tt> event. The top-level application component
! handles this event and start services accordingly. Details on
the new boot sequence can be found in TEP 107: TinyOS 2.x Boot
Sequence[<a class="reference" href="#tep107">TEP107</a>].</p>
</div>
! <div class="section">
! <h1><a id="virtualization" name="virtualization">5. Virtualization</a></h1>
<p>TinyOS 2.0 is written with nesC 1.2, which introduces the concept
of a 'generic' or instantiable component. Generic modules allow
TinyOS to have reusable data structures, such as bit vectors and
queues, which simplify development. More importantly, generic
! configurations allow services to encapsulate complex wiring
relationships for clients that need them.</p>
<p>In practice, this means that many basic TinyOS services are now
***************
*** 433,438 ****
mistakes and simplifying use of the abstraction.</p>
</div>
! <div class="section" id="timers">
! <h1><a name="timers">6. Timers</a></h1>
<p>TinyOS 2.0 provides a much richer set of timer interfaces than
1.x. Experience has shown that timers are one of the most critical
--- 436,441 ----
mistakes and simplifying use of the abstraction.</p>
</div>
! <div class="section">
! <h1><a id="timers" name="timers">6. Timers</a></h1>
<p>TinyOS 2.0 provides a much richer set of timer interfaces than
1.x. Experience has shown that timers are one of the most critical
***************
*** 444,448 ****
keyword). Components can query their timers for how much time
remainins before they fire, and can start timers in the future (e.g.,
! 'start firing a timer at 1Hz starting 31ms from now'). TEP 102:
Timers[<a class="reference" href="#tep102">TEP102</a>] defines what HIL components a platform must provide
in order to support standard TinyOS timers. Platforms are
--- 447,451 ----
keyword). Components can query their timers for how much time
remainins before they fire, and can start timers in the future (e.g.,
! 'start firing a timer at 1Hz starting 31ms from now'). TEP 102:
Timers[<a class="reference" href="#tep102">TEP102</a>] defines what HIL components a platform must provide
in order to support standard TinyOS timers. Platforms are
***************
*** 461,466 ****
</pre>
</div>
! <div class="section" id="communication">
! <h1><a name="communication">7. Communication</a></h1>
<p>In TinyOS 2.0, the message buffer type is <tt class="docutils literal"><span class="pre">message_t</span></tt>, and it is a
buffer that is large enough to hold a packet from any of a node's
--- 464,469 ----
</pre>
</div>
! <div class="section">
! <h1><a id="communication" name="communication">7. Communication</a></h1>
<p>In TinyOS 2.0, the message buffer type is <tt class="docutils literal"><span class="pre">message_t</span></tt>, and it is a
buffer that is large enough to hold a packet from any of a node's
***************
*** 483,488 ****
SerialActiveMessageC, which provides active message communication over
the serial port.</p>
! <p>Active message communication is virtualized through four generic
! components, which take the AM type as a parameter: AMSenderC,
AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is
virtualized in that the call to send() does not fail if some
--- 486,491 ----
SerialActiveMessageC, which provides active message communication over
the serial port.</p>
! <p>Active message communication is virtualized through four generic
! components, which take the AM type as a parameter: AMSenderC,
AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is
virtualized in that the call to send() does not fail if some
***************
*** 492,504 ****
the active message system queues and sends these outstanding packets.
This is different than the QueuedSendC approach of 1.x, in which there
! is an N-deep queue that is shared among all senders. With N AMSenderC
components, there is an N-deep queue where each sender has a single
! reserved entry.</p>
<p>Further information on message_t can be found in TEP 111:
message_t[<a class="reference" href="#tep111">TEP111</a>], while further information on AM can be
found in TEP 116: Packet Protocoks[<a class="reference" href="#tep116">TEP116</a>].</p>
</div>
! <div class="section" id="sensors">
! <h1><a name="sensors">8. Sensors</a></h1>
<p>In TinyOS 2.0, named sensor components comprise the HIL of a
platform's sensors. TEP 114 describes a set of HIL data acquisition
--- 495,512 ----
the active message system queues and sends these outstanding packets.
This is different than the QueuedSendC approach of 1.x, in which there
! is an N-deep queue that is shared among all senders. With N AMSenderC
components, there is an N-deep queue where each sender has a single
! reserved entry. This means that each AMSenderC receives
! 1/n of the available post-MAC transmission opportunities, where
! n is the number of AMSenderC components with outstanding packets.
! In the worst case, n is the number of components; even when every
! protocol and component that sends packets is trying to send a packet,
! each one will receive its fair share of transmission opportunities.</p>
<p>Further information on message_t can be found in TEP 111:
message_t[<a class="reference" href="#tep111">TEP111</a>], while further information on AM can be
found in TEP 116: Packet Protocoks[<a class="reference" href="#tep116">TEP116</a>].</p>
</div>
! <div class="section">
! <h1><a id="sensors" name="sensors">8. Sensors</a></h1>
<p>In TinyOS 2.0, named sensor components comprise the HIL of a
platform's sensors. TEP 114 describes a set of HIL data acquisition
***************
*** 518,523 ****
can be found in TEP 114: Source and Sink Independent Drivers[<a class="reference" href="#tep114">TEP114</a>].</p>
</div>
! <div class="section" id="error-codes">
! <h1><a name="error-codes">9. Error Codes</a></h1>
<p>The standard TinyOS 1.x return code is <tt class="docutils literal"><span class="pre">result_t</span></tt>, whose value is
either SUCCESS (a non-zero value) or FAIL (a zero value). While this
--- 526,531 ----
can be found in TEP 114: Source and Sink Independent Drivers[<a class="reference" href="#tep114">TEP114</a>].</p>
</div>
! <div class="section">
! <h1><a id="error-codes" name="error-codes">9. Error Codes</a></h1>
<p>The standard TinyOS 1.x return code is <tt class="docutils literal"><span class="pre">result_t</span></tt>, whose value is
either SUCCESS (a non-zero value) or FAIL (a zero value). While this
***************
*** 531,535 ****
<pre class="literal-block">
if (call X.y()) {
! busy = TRUE;
}
</pre>
--- 539,543 ----
<pre class="literal-block">
if (call X.y()) {
! busy = TRUE;
}
</pre>
***************
*** 543,550 ****
</pre>
</div>
! <div class="section" id="arbitration">
! <h1><a name="arbitration">10. Arbitration</a></h1>
<p>While basic abstractions, such as packet communication and timers,
! can be virtualized, experiences with 1.x showed that some cannot
without either adding significant complexity or limiting the system.
The most pressing example of this is a shared bus on a microcontroller.
--- 551,558 ----
</pre>
</div>
! <div class="section">
! <h1><a id="arbitration" name="arbitration">10. Arbitration</a></h1>
<p>While basic abstractions, such as packet communication and timers,
! can be virtualized, experiences with 1.x showed that some cannot
without either adding significant complexity or limiting the system.
The most pressing example of this is a shared bus on a microcontroller.
***************
*** 552,558 ****
to use the bus at the same time, so some way of arbitrating access
is needed.</p>
! <p>To support these kinds of abstractions, TinyOS 2.0 introduces
the Resource interface, which components use to request and
! acquire shared resources, and arbiters, which provide a policy for
arbitrating access between multiple clients. For some abstractions,
the arbiter also provides a power management policy, as it can tell
--- 560,566 ----
to use the bus at the same time, so some way of arbitrating access
is needed.</p>
! <p>To support these kinds of abstractions, TinyOS 2.0 introduces
the Resource interface, which components use to request and
! acquire shared resources, and arbiters, which provide a policy for
arbitrating access between multiple clients. For some abstractions,
the arbiter also provides a power management policy, as it can tell
***************
*** 561,576 ****
and how arbiters work.</p>
</div>
! <div class="section" id="power-management">
! <h1><a name="power-management">11. Power Management</a></h1>
<p>Power management in 2.0 is divided into two parts: the power state
of the microcontroller and the power state of devices. The former,
discussed in TEP 112: Microcontroller Power Management[<a class="reference" href="#tep112">TEP112</a>],
! is computed in a chip-specific manner by examining which devices
and interrupt souces are active. The latter, discussed in
! TEP 115: Power Management of Non-Virtualised Devices, is handled
! through resource abiters.</p>
</div>
! <div class="section" id="conclusion">
! <h1><a name="conclusion">12. Conclusion</a></h1>
<p>TinyOS 2.0 represents the next step of TinyOS development. Building on
user experiences over the past few years, it has taken the basic
--- 569,595 ----
and how arbiters work.</p>
</div>
! <div class="section">
! <h1><a id="power-management" name="power-management">11. Power Management</a></h1>
<p>Power management in 2.0 is divided into two parts: the power state
of the microcontroller and the power state of devices. The former,
discussed in TEP 112: Microcontroller Power Management[<a class="reference" href="#tep112">TEP112</a>],
! is computed in a chip-specific manner by examining which devices
and interrupt souces are active. The latter, discussed in
! TEP 115: Power Management of Non-Virtualised Devices{<a class="reference" href="#tep115">TEP115</a>], is handled
! through resource abiters. Fully virtualized services have their
! own, individual power management policies.</p>
</div>
! <div class="section">
! <h1><a id="network-protocols" name="network-protocols">12. Network Protocols</a></h1>
! <p>TinyOS 2.0 provides simple reference implementations of two of
! the most basic protocols used in mote networks: dissemination
! and collection. Dissemination reliably delivers small (fewer
! than 20 byte) data items to every node in a network, while
! collection builds a routing tree rooted at a sink node. Together,
! these two protocols enable a wide range of data collection
! applications.</p>
! </div>
! <div class="section">
! <h1><a id="conclusion" name="conclusion">12. Conclusion</a></h1>
<p>TinyOS 2.0 represents the next step of TinyOS development. Building on
user experiences over the past few years, it has taken the basic
***************
*** 581,594 ****
dissemination), and further power management abstractions.</p>
</div>
! <div class="section" id="acknowledgments">
! <h1><a name="acknowledgments">13. Acknowledgments</a></h1>
<p>TinyOS 2.0 is the result of a lot of hard work from a lot of people,
! including (but not limited to) David Gay, Cory Sharp, Vlado Handziski,
! Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui, Prabal Dutta,
! Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler,
! Kristin Wright, Ion Yannopoulos, and Phil Levis.</p>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">14. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
--- 600,616 ----
dissemination), and further power management abstractions.</p>
</div>
! <div class="section">
! <h1><a id="acknowledgments" name="acknowledgments">13. Acknowledgments</a></h1>
<p>TinyOS 2.0 is the result of a lot of hard work from a lot of people,
! including (but not limited to) David Gay, Philip Levis, Cory Sharp,
! Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui,
! Prabal Dutta,
! Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler,
! Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel,
! Robert Szewczyk, Rodrigo Fonseca, Kyle Jamieson, Omprakash Gnawali,
! and Kristin Wright.</p>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">14. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
***************
*** 603,612 ****
</div>
</div>
! <div class="section" id="citations">
! <h1><a name="citations">15. Citations</a></h1>
<table class="docutils citation" frame="void" id="tep1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep1">[TEP1]</a></td><td>TEP 1: TEP Structure and Keywords</td></tr>
</tbody>
</table>
--- 625,634 ----
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">15. Citations</a></h1>
<table class="docutils citation" frame="void" id="tep1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep1">[TEP1]</a></td><td>TEP 1: TEP Structure and Keywords. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep1.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 614,618 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep2">[TEP2]</a></td><td>TEP 2: Hardware Abstraction Architecture.</td></tr>
</tbody>
</table>
--- 636,640 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep2">[TEP2]</a></td><td>TEP 2: Hardware Abstraction Architecture. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep2.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 620,624 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep3">[TEP3]</a></td><td>TEP 3: Coding Standard</td></tr>
</tbody>
</table>
--- 642,646 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep3">[TEP3]</a></td><td>TEP 3: Coding Standard. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep3.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 626,630 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep101">[TEP101]</a></td><td>TEP 101: Analog-to-Digital Converters. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep101.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep101.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 648,652 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep101">[TEP101]</a></td><td>TEP 101: Analog-to-Digital Converters. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep101.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 632,636 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep102">[TEP102]</a></td><td>TEP 102: Timers. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep102.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep102.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 654,658 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep102">[TEP102]</a></td><td>TEP 102: Timers. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep102.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 638,642 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep106">[TEP106]</a></td><td>TEP 106: Schedulers and Tasks. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep106.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep106.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 660,664 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep106">[TEP106]</a></td><td>TEP 106: Schedulers and Tasks. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep106.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 644,648 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep107">[TEP107]</a></td><td>TEP 107: Boot Sequence. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep107.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep107.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 666,670 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep107">[TEP107]</a></td><td>TEP 107: Boot Sequence. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep107.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 650,654 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep108">[TEP108]</a></td><td>TEP 108: message_t. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep108.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep108.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 672,676 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep108">[TEP108]</a></td><td>TEP 108: message_t. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep108.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 656,660 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep109">[TEP109]</a></td><td>TEP 109: Sensorboards. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep109.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep109.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 678,682 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep109">[TEP109]</a></td><td>TEP 109: Sensorboards. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep109.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 662,666 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep110">[TEP110]</a></td><td>TEP 110: Service Distributions. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep110.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep110.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 684,688 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep110">[TEP110]</a></td><td>TEP 110: Service Distributions. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep110.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 668,672 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep111">[TEP111]</a></td><td>TEP 111: message_t. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep111.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep111.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 690,694 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep111">[TEP111]</a></td><td>TEP 111: message_t. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep111.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 674,678 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep112">[TEP112]</a></td><td>TEP 112: Microcontroller Power Management. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep112.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep112.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 696,700 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep112">[TEP112]</a></td><td>TEP 112: Microcontroller Power Management. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep112.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 680,684 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep113">[TEP113]</a></td><td>TEP 113: Serial Communication. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep113.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep113.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 702,706 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep113">[TEP113]</a></td><td>TEP 113: Serial Communication. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep113.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 686,690 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep114">[TEP114]</a></td><td>TEP 114: SIDs: Source and Sink Independent Drivers. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep114.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep114.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 708,712 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep114">[TEP114]</a></td><td>TEP 114: SIDs: Source and Sink Independent Drivers. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep114.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 692,696 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep115">[TEP115]</a></td><td>TEP 115: Power Management of Non-Virtualised Devices. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep115.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep115.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 714,718 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep115">[TEP115]</a></td><td>TEP 115: Power Management of Non-Virtualised Devices. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep115.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
***************
*** 698,702 ****
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep116">[TEP116]</a></td><td>TEP 116: Packet Protocols. <a class="reference" href="http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep116.txt?view=markup">http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-2.x/doc/txt/tep116.txt?view=markup</a></td></tr>
</tbody>
</table>
--- 720,724 ----
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a name="tep116">[TEP116]</a></td><td>TEP 116: Packet Protocols. <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep116.html?pathrev=tinyos-2_0_devel-BRANCH</td></tr>
</tbody>
</table>
Index: tep1.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep1.html,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -C2 -d -r1.1.2.4 -r1.1.2.5
*** tep1.html 18 May 2006 23:08:14 -0000 1.1.2.4
--- tep1.html 9 Jun 2006 21:12:17 -0000 1.1.2.5
***************
*** 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>TEP Structure and Keywords</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>TEP Structure and Keywords</title>
<meta name="author" content="Philip Levis" />
***************
*** 217,221 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 217,225 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 272,277 ****
font-size: 100% }
! tt {
! background-color: #eeeeee }
ul.auto-toc {
--- 276,280 ----
font-size: 100% }
! tt {}
ul.auto-toc {
***************
*** 315,326 ****
improvements. Distribution of this memo is unlimited.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This memo describes the structure all TinyOS Extension Proposal (TEP)
documents follow, and defines the meaning of several key words in
those documents.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>In order to simplify management, reading, and tracking development,
all TinyOS Extension Proposals (TEPs) MUST have a particular
--- 318,329 ----
improvements. Distribution of this memo is unlimited.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo describes the structure all TinyOS Extension Proposal (TEP)
documents follow, and defines the meaning of several key words in
those documents.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>In order to simplify management, reading, and tracking development,
all TinyOS Extension Proposals (TEPs) MUST have a particular
***************
*** 330,335 ****
describes and follows both.</p>
</div>
! <div class="section" id="keywords">
! <h1><a name="keywords">2. Keywords</a></h1>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
--- 333,338 ----
describes and follows both.</p>
</div>
! <div class="section">
! <h1><a id="keywords" name="keywords">2. Keywords</a></h1>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
***************
*** 337,352 ****
<p>Note that the force of these words is modified by the requirement
level of the document in which they are used.</p>
! <div class="section" id="must">
! <h2><a name="must">2.1 MUST</a></h2>
<p>MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.</p>
</div>
! <div class="section" id="must-not">
! <h2><a name="must-not">2.2 MUST NOT</a></h2>
<p>MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.</p>
</div>
! <div class="section" id="should">
! <h2><a name="should">2.3 SHOULD</a></h2>
<p>SHOULD: This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
--- 340,355 ----
<p>Note that the force of these words is modified by the requirement
level of the document in which they are used.</p>
! <div class="section">
! <h2><a id="must" name="must">2.1 MUST</a></h2>
<p>MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.</p>
</div>
! <div class="section">
! <h2><a id="must-not" name="must-not">2.2 MUST NOT</a></h2>
<p>MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.</p>
</div>
! <div class="section">
! <h2><a id="should" name="should">2.3 SHOULD</a></h2>
<p>SHOULD: This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
***************
*** 354,359 ****
carefully weighed before choosing a different course.</p>
</div>
! <div class="section" id="should-not">
! <h2><a name="should-not">2.4 SHOULD NOT</a></h2>
<p>SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
--- 357,362 ----
carefully weighed before choosing a different course.</p>
</div>
! <div class="section">
! <h2><a id="should-not" name="should-not">2.4 SHOULD NOT</a></h2>
<p>SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
***************
*** 362,367 ****
before implementing any behavior described with this label.</p>
</div>
! <div class="section" id="may">
! <h2><a name="may">2.5 MAY</a></h2>
<p>MAY: This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One implementer may choose to include the item
--- 365,370 ----
before implementing any behavior described with this label.</p>
</div>
! <div class="section">
! <h2><a id="may" name="may">2.5 MAY</a></h2>
<p>MAY: This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One implementer may choose to include the item
***************
*** 376,381 ****
course, for the feature the option provides.)</p>
</div>
! <div class="section" id="guidance-in-the-use-of-these-imperatives">
! <h2><a name="guidance-in-the-use-of-these-imperatives">2.6 Guidance in the use of these Imperatives</a></h2>
<p>Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
--- 379,384 ----
course, for the feature the option provides.)</p>
</div>
! <div class="section">
! <h2><a id="guidance-in-the-use-of-these-imperatives" name="guidance-in-the-use-of-these-imperatives">2.6 Guidance in the use of these Imperatives</a></h2>
<p>Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
***************
*** 387,400 ****
</div>
</div>
! <div class="section" id="tep-structure">
! <h1><a name="tep-structure">3. TEP Structure</a></h1>
<p>TEPs have two major parts, a header and a body. The header states
! document metadata, for management and status. The body contains the
content of the proposal.</p>
! <p>All TEPs MUST follow the TEP docutils template, and conform to
! reStructuredText standards <a class="citation-reference" href="#rst" id="id1" name="id1">[rst]</a>, to enable translation from
reStructuredText to HTML and Latex.</p>
! <div class="section" id="tep-header">
! <h2><a name="tep-header">3.1 TEP Header</a></h2>
<p>The TEP header has several fields which MUST be included, as well as
others which MAY be included. The first six header fields MUST be
--- 390,403 ----
</div>
</div>
! <div class="section">
! <h1><a id="tep-structure" name="tep-structure">3. TEP Structure</a></h1>
<p>TEPs have two major parts, a header and a body. The header states
! document metadata, for management and status. The body contains the
content of the proposal.</p>
! <p>All TEPs MUST follow the TEP docutils template, and conform to
! reStructuredText standards <a class="citation-reference" href="#rst" id="id1" name="id1">[rst]</a>, to enable translation from
reStructuredText to HTML and Latex.</p>
! <div class="section">
! <h2><a id="tep-header" name="tep-header">3.1 TEP Header</a></h2>
<p>The TEP header has several fields which MUST be included, as well as
others which MAY be included. The first six header fields MUST be
***************
*** 450,455 ****
have these fields, which are for Drafts only.</p>
</div>
! <div class="section" id="tep-body">
! <h2><a name="tep-body">3.2 TEP Body</a></h2>
<p>The first element of the TEP body MUST be the title of the document. A
TEP SHOULD follow the title with an Abstract, which gives a brief
--- 453,458 ----
have these fields, which are for Drafts only.</p>
</div>
! <div class="section">
! <h2><a id="tep-body" name="tep-body">3.2 TEP Body</a></h2>
<p>The first element of the TEP body MUST be the title of the document. A
TEP SHOULD follow the title with an Abstract, which gives a brief
***************
*** 469,483 ****
</div>
</div>
! <div class="section" id="reference">
! <h1><a name="reference">4. Reference</a></h1>
<p>The reference use of this document is TEP 1 (itself).</p>
</div>
! <div class="section" id="acknowledgments">
! <h1><a name="acknowledgments">5. Acknowledgments</a></h1>
<p>The definitions of the compliance terms are a direct copy of
definitions taken from IETF RFC 2119.</p>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">6. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
--- 472,486 ----
</div>
</div>
! <div class="section">
! <h1><a id="reference" name="reference">4. Reference</a></h1>
<p>The reference use of this document is TEP 1 (itself).</p>
</div>
! <div class="section">
! <h1><a id="acknowledgments" name="acknowledgments">5. Acknowledgments</a></h1>
<p>The definitions of the compliance terms are a direct copy of
definitions taken from IETF RFC 2119.</p>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">6. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
***************
*** 491,496 ****
</div>
</div>
! <div class="section" id="citations">
! <h1><a name="citations">7. Citations</a></h1>
<table class="docutils citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
--- 494,499 ----
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">7. Citations</a></h1>
<table class="docutils citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep101.html,v
retrieving revision 1.1.2.7
retrieving revision 1.1.2.8
diff -C2 -d -r1.1.2.7 -r1.1.2.8
*** tep101.html 18 May 2006 23:08:14 -0000 1.1.2.7
--- tep101.html 9 Jun 2006 21:12:17 -0000 1.1.2.8
***************
*** 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>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" />
***************
*** 217,221 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 217,225 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 272,277 ****
font-size: 100% }
! tt {
! background-color: #eeeeee }
ul.auto-toc {
--- 276,280 ----
font-size: 100% }
! tt {}
ul.auto-toc {
***************
*** 316,321 ****
<a class="citation-reference" href="#tep1" id="id1" name="id1">[TEP1]</a>.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This TEP proposes a hardware abstraction for TinyOS 2.x analog-to-digital
converters (ADCs). It focuses on aligning the ADC abstraction with the
--- 319,324 ----
<a class="citation-reference" href="#tep1" id="id1" name="id1">[TEP1]</a>.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This TEP proposes a hardware abstraction for TinyOS 2.x analog-to-digital
converters (ADCs). It focuses on aligning the ADC abstraction with the
***************
*** 324,329 ****
ADC is platform-dependent.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Analog-to-digital converters (ADCs) are devices that convert analog input
signals to discrete digital output signals, typically voltage to a digital
--- 327,332 ----
ADC is platform-dependent.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Analog-to-digital converters (ADCs) are devices that convert analog input
signals to discrete digital output signals, typically voltage to a digital
***************
*** 384,389 ****
implementation for the TI MSP430 MCU.</p>
</div>
! <div class="section" id="interfaces">
! <h1><a name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes to adopt the following three generic, source-independent
data collection interfaces from <a class="citation-reference" href="#tep114" id="id6" name="id6">[TEP114]</a> for the collection of ADC conversion
--- 387,392 ----
implementation for the TI MSP430 MCU.</p>
</div>
! <div class="section">
! <h1><a id="interfaces" name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes to adopt the following three generic, source-independent
data collection interfaces from <a class="citation-reference" href="#tep114" id="id6" name="id6">[TEP114]</a> for the collection of ADC conversion
***************
*** 403,414 ****
are specified in <a class="citation-reference" href="#tep114" id="id7" name="id7">[TEP114]</a>, in the following their usage is explained with
respect to ADCs.</p>
! <div class="section" id="read">
! <h2><a name="read">Read</a></h2>
<p>The Read interface can be used to sample an ADC channel and return a single
conversion result. It provides no guarantees about when exactly the sampling
occurs (the request may be buffered).</p>
</div>
! <div class="section" id="readnow">
! <h2><a name="readnow">ReadNow</a></h2>
<p>The ReadNow interface provides more precise control over the time of the
sampling: If a call to ReadNow.read() succeeds, the ADC starts to sample the
--- 406,417 ----
are specified in <a class="citation-reference" href="#tep114" id="id7" name="id7">[TEP114]</a>, in the following their usage is explained with
respect to ADCs.</p>
! <div class="section">
! <h2><a id="read" name="read">Read</a></h2>
<p>The Read interface can be used to sample an ADC channel and return a single
conversion result. It provides no guarantees about when exactly the sampling
occurs (the request may be buffered).</p>
</div>
! <div class="section">
! <h2><a id="readnow" name="readnow">ReadNow</a></h2>
<p>The ReadNow interface provides more precise control over the time of the
sampling: If a call to ReadNow.read() succeeds, the ADC starts to sample the
***************
*** 419,424 ****
release access via the Resource interface when it is finished (see <a class="citation-reference" href="#tep108" id="id8" name="id8">[TEP108]</a>).</p>
</div>
! <div class="section" id="readstream">
! <h2><a name="readstream">ReadStream</a></h2>
<p>The ReadStream interface can be used to sample an ADC channel multiple times
with a specified sampling period. It provides no guarantees about when exactly
--- 422,427 ----
release access via the Resource interface when it is finished (see <a class="citation-reference" href="#tep108" id="id8" name="id8">[TEP108]</a>).</p>
</div>
! <div class="section">
! <h2><a id="readstream" name="readstream">ReadStream</a></h2>
<p>The ReadStream interface can be used to sample an ADC channel multiple times
with a specified sampling period. It provides no guarantees about when exactly
***************
*** 427,432 ****
</div>
</div>
! <div class="section" id="hal1-guidelines">
! <h1><a name="hal1-guidelines">3. HAL1 guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL of an ADC abstraction consists of
two sublayers, HAL1 and HAL2. In the ADC component stack the HAL1 resides
--- 430,435 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal1-guidelines" name="hal1-guidelines">3. HAL1 guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL of an ADC abstraction consists of
two sublayers, HAL1 and HAL2. In the ADC component stack the HAL1 resides
***************
*** 438,443 ****
facilitate the mapping to platform-independent interfaces on the level of
HAL2. Appendix B shows the HAL1 specification for the TI MSP430 MCU.</p>
! <div class="section" id="resource-reservation">
! <h2><a name="resource-reservation">Resource reservation</a></h2>
<p>As the ADC hardware is a shared resource that is multiplexed between several
clients, it requires access arbitration. Therefore the HAL1 configuration
--- 441,446 ----
facilitate the mapping to platform-independent interfaces on the level of
HAL2. Appendix B shows the HAL1 specification for the TI MSP430 MCU.</p>
! <div class="section">
! <h2><a id="resource-reservation" name="resource-reservation">Resource reservation</a></h2>
<p>As the ADC hardware is a shared resource that is multiplexed between several
clients, it requires access arbitration. Therefore the HAL1 configuration
***************
*** 452,457 ****
'Resource' interface (see <a class="citation-reference" href="#tep108" id="id11" name="id11">[TEP108]</a>).</p>
</div>
! <div class="section" id="configuration-and-sampling">
! <h2><a name="configuration-and-sampling">Configuration and sampling</a></h2>
<p>As the ADC hardware is a shared resource the HAL1 SHOULD support hardware
configuration and sampling on a per-client basis (although per-port
--- 455,460 ----
'Resource' interface (see <a class="citation-reference" href="#tep108" id="id11" name="id11">[TEP108]</a>).</p>
</div>
! <div class="section">
! <h2><a id="configuration-and-sampling" name="configuration-and-sampling">Configuration and sampling</a></h2>
<p>As the ADC hardware is a shared resource the HAL1 SHOULD support hardware
configuration and sampling on a per-client basis (although per-port
***************
*** 474,479 ****
HAL1 interfaces for the TI MSP430 MCU.</p>
</div>
! <div class="section" id="hal1-virtualization">
! <h2><a name="hal1-virtualization">HAL1 virtualization</a></h2>
<p>In order to hide wiring complexities and/or export only a subset of all ADC
functions generic ADC wrapper components MAY be provided on the level of HAL1
--- 477,482 ----
HAL1 interfaces for the TI MSP430 MCU.</p>
</div>
! <div class="section">
! <h2><a id="hal1-virtualization" name="hal1-virtualization">HAL1 virtualization</a></h2>
<p>In order to hide wiring complexities and/or export only a subset of all ADC
functions generic ADC wrapper components MAY be provided on the level of HAL1
***************
*** 481,491 ****
</div>
</div>
! <div class="section" id="hal2-requirements">
! <h1><a name="hal2-requirements">4. HAL2 requirements</a></h1>
<p>The following components MUST be provided on all platforms that have an ADC:</p>
<pre class="literal-block">
! AdcReadClient
! AdcReadNowClient
! AdcReadStreamClient
</pre>
<p>These generic components are instantiated and provide access to the ADC on a
--- 484,494 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal2-requirements" name="hal2-requirements">4. HAL2 requirements</a></h1>
<p>The following components MUST be provided on all platforms that have an ADC:</p>
<pre class="literal-block">
! AdcReadClient
! AdcReadNowClient
! AdcReadStreamClient
</pre>
<p>These generic components are instantiated and provide access to the ADC on a
***************
*** 500,505 ****
reference voltage - makes the HAL2 representation chip dependent. Therefore
the ADC abstraction does not include an HIL.</p>
! <div class="section" id="adcreadclient">
! <h2><a name="adcreadclient">AdcReadClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadClient() {
--- 503,508 ----
reference voltage - makes the HAL2 representation chip dependent. Therefore
the ADC abstraction does not include an HIL.</p>
! <div class="section">
! <h2><a id="adcreadclient" name="adcreadclient">AdcReadClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadClient() {
***************
*** 522,527 ****
resolution of the conversion results.</p>
</div>
! <div class="section" id="adcreadnowclient">
! <h2><a name="adcreadnowclient">AdcReadNowClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClient() {
--- 525,530 ----
resolution of the conversion results.</p>
</div>
! <div class="section">
! <h2><a id="adcreadnowclient" name="adcreadnowclient">AdcReadNowClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClient() {
***************
*** 548,553 ****
resolution of the conversion result.</p>
</div>
! <div class="section" id="adcreadstreamclient">
! <h2><a name="adcreadstreamclient">AdcReadStreamClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClient() {
--- 551,556 ----
resolution of the conversion result.</p>
</div>
! <div class="section">
! <h2><a id="adcreadstreamclient" name="adcreadstreamclient">AdcReadStreamClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClient() {
***************
*** 572,577 ****
</div>
</div>
! <div class="section" id="hal2-implementation-guidelines">
! <h1><a name="hal2-implementation-guidelines">5. HAL2 implementation guidelines</a></h1>
<p>The HAL2 implementation of an ADC stack has two main tasks: It translates a
platform-independent HAL2 request (from the 'Read', 'ReadNow' or 'ReadStream'
--- 575,580 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal2-implementation-guidelines" name="hal2-implementation-guidelines">5. HAL2 implementation guidelines</a></h1>
<p>The HAL2 implementation of an ADC stack has two main tasks: It translates a
platform-independent HAL2 request (from the 'Read', 'ReadNow' or 'ReadStream'
***************
*** 611,616 ****
ADC12 implementation in Appendix C).</p>
</div>
! <div class="section" id="appendix-a-hardware-differences-between-platforms">
! <h1><a name="appendix-a-hardware-differences-between-platforms">Appendix A: Hardware differences between platforms</a></h1>
<p>The following table compares the characteristics of two microcontrollers
commonly used in TinyOS platforms:</p>
--- 614,619 ----
ADC12 implementation in Appendix C).</p>
</div>
! <div class="section">
! <h1><a id="appendix-a-hardware-differences-between-platforms" name="appendix-a-hardware-differences-between-platforms">Appendix A: Hardware differences between platforms</a></h1>
<p>The following table compares the characteristics of two microcontrollers
commonly used in TinyOS platforms:</p>
***************
*** 741,746 ****
</table>
</div>
! <div class="section" id="appendix-b-an-hal1-representation-msp430-adc12">
! <h1><a name="appendix-b-an-hal1-representation-msp430-adc12">Appendix B: an HAL1 representation: MSP430 ADC12</a></h1>
<p>The following shows the HAL1 representation for the ADC12 of the TI MSP430
MCU. It reflects the four MSP430 ADC12 conversion modes as it lets a client
--- 744,749 ----
</table>
</div>
! <div class="section">
! <h1><a id="appendix-b-an-hal1-representation-msp430-adc12" name="appendix-b-an-hal1-representation-msp430-adc12">Appendix B: an HAL1 representation: MSP430 ADC12</a></h1>
<p>The following shows the HAL1 representation for the ADC12 of the TI MSP430
MCU. It reflects the four MSP430 ADC12 conversion modes as it lets a client
***************
*** 753,774 ****
implemented).:</p>
<pre class="literal-block">
! configuration Msp430Adc12C
! {
! provides interface Resource[uint8_t id];
! provides interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
! }
! interface Msp430Adc12SingleChannel
! {
async command error_t getSingleData(const msp430adc12_channel_config_t *config);
! async command error_t getSingleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t jiffies);
async command error_t getMultipleData( const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint16_t numSamples, uint16_t jiffies);
! async command error_t getMultipleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint8_t numSamples, uint16_t jiffies);
async event error_t singleDataReady(uint16_t data);
async event uint16_t* multipleDataReady(uint16_t *buffer, uint16_t
! numSamples);
}
</pre>
--- 756,777 ----
implemented).:</p>
<pre class="literal-block">
! configuration Msp430Adc12C
! {
! provides interface Resource[uint8_t id];
! provides interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
! }
! interface Msp430Adc12SingleChannel
! {
async command error_t getSingleData(const msp430adc12_channel_config_t *config);
! async command error_t getSingleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t jiffies);
async command error_t getMultipleData( const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint16_t numSamples, uint16_t jiffies);
! async command error_t getMultipleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint8_t numSamples, uint16_t jiffies);
async event error_t singleDataReady(uint16_t data);
async event uint16_t* multipleDataReady(uint16_t *buffer, uint16_t
! numSamples);
}
</pre>
***************
*** 777,782 ****
errors.</p>
</div>
! <div class="section" id="appendix-c-an-hal2-representation-msp430-adc12">
! <h1><a name="appendix-c-an-hal2-representation-msp430-adc12">Appendix C: an HAL2 representation: MSP430 ADC12</a></h1>
<p>The AdcReadClientC component for the MSP430 ADC12 is implemented as follows:</p>
<pre class="literal-block">
--- 780,785 ----
errors.</p>
</div>
! <div class="section">
! <h1><a id="appendix-c-an-hal2-representation-msp430-adc12" name="appendix-c-an-hal2-representation-msp430-adc12">Appendix C: an HAL2 representation: MSP430 ADC12</a></h1>
<p>The AdcReadClientC component for the MSP430 ADC12 is implemented as follows:</p>
<pre class="literal-block">
***************
*** 786,790 ****
} implementation {
components AdcC;
! #ifdef REF_VOLT_AUTO_CONFIGURE
components new Msp430Adc12RefVoltAutoClientC() as Msp430AdcClient;
#else
--- 789,793 ----
} implementation {
components AdcC;
! #ifdef REF_VOLT_AUTO_CONFIGURE
components new Msp430Adc12RefVoltAutoClientC() as Msp430AdcClient;
#else
***************
*** 802,806 ****
#ifdef REF_VOLT_AUTO_CONFIGURE
Msp430Adc12Config = Msp430AdcClient.Msp430Adc12Config;
! #endif
}
</pre>
--- 805,809 ----
#ifdef REF_VOLT_AUTO_CONFIGURE
Msp430Adc12Config = Msp430AdcClient.Msp430Adc12Config;
! #endif
}
</pre>
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep102.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
*** tep102.html 18 May 2006 23:08:14 -0000 1.1.2.5
--- tep102.html 9 Jun 2006 21:12:17 -0000 1.1.2.6
***************
*** 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" />
***************
*** 217,221 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 217,225 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 272,277 ****
font-size: 100% }
! tt {
! background-color: #eeeeee }
ul.auto-toc {
--- 276,280 ----
font-size: 100% }
! tt {}
ul.auto-toc {
***************
*** 316,321 ****
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
***************
*** 323,328 ****
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">
***************
*** 338,342 ****
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
***************
*** 347,351 ****
<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
***************
*** 355,365 ****
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>
--- 358,368 ----
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>
***************
*** 402,407 ****
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">
--- 405,410 ----
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">
***************
*** 417,423 ****
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
***************
*** 437,454 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending() </dt>
<dd>return TRUE if an overflow interrupt will occur after the outermost
atomic block is exits. FALSE otherwise.</dd>
! <dt>clearOverflow() </dt>
<dd>cancel the pending overflow interrupt.</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,457 ----
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending()</dt>
<dd>return TRUE if an overflow interrupt will occur after the outermost
atomic block is exits. FALSE otherwise.</dd>
! <dt>clearOverflow()</dt>
<dd>cancel the pending overflow interrupt.</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.
***************
*** 473,488 ****
</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>
! <dt>startAt(t0,dt) </dt>
<dd>cancel any previously running alarm and set to fire at time t1 =
t0+dt. This form allows a delay to be anchored to some time t0
--- 476,491 ----
</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>
! <dt>startAt(t0,dt)</dt>
<dd>cancel any previously running alarm and set to fire at time t1 =
t0+dt. This form allows a delay to be anchored to some time t0
***************
*** 491,503 ****
of an alarm while being able to detect if the alarm time for a short
alarm prematurely elapsed.</dd>
! <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.</dd>
</dl>
</div>
! <div class="section" id="busywait">
! <h2><a name="busywait">BusyWait</a></h2>
<p>The BusyWait interface replaces the TOSH_uwait macro from TinyOS
1.x.</p>
--- 494,506 ----
of an alarm while being able to detect if the alarm time for a short
alarm prematurely elapsed.</dd>
! <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.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="busywait" name="busywait">BusyWait</a></h2>
<p>The BusyWait interface replaces the TOSH_uwait macro from TinyOS
1.x.</p>
***************
*** 513,518 ****
</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
--- 516,521 ----
</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
***************
*** 525,534 ****
</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"
--- 528,537 ----
</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"
***************
*** 555,596 ****
</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 typically select a clocking option for each of their
hardware counters, based on their hardware design (e.g., the mica
--- 558,599 ----
</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 typically select a clocking option for each of their
hardware counters, based on their hardware design (e.g., the mica
***************
*** 607,611 ****
configuration CounterPW {
provides interface Counter<TP, uintW_t>;
! } ...
generic configuration AlarmPWC {
provides interface Alarm<TP,uintW_t>;
--- 610,614 ----
configuration CounterPW {
provides interface Counter<TP, uintW_t>;
! } ...
generic configuration AlarmPWC {
provides interface Alarm<TP,uintW_t>;
***************
*** 616,620 ****
configuration CounterP32 {
provides interface Counter<TP, uint32_t>;
! } ...
generic configuration AlarmP32C {
provides interface Alarm<TP,uint32_t>;
--- 619,623 ----
configuration CounterP32 {
provides interface Counter<TP, uint32_t>;
! } ...
generic configuration AlarmP32C {
provides interface Alarm<TP,uint32_t>;
***************
*** 632,637 ****
allowed).</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>
--- 635,640 ----
allowed).</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>
***************
*** 639,644 ****
BusyWaitMicroC</dd>
</dl>
! <div class="section" id="timermillic">
! <h2><a name="timermillic">TimerMilliC</a></h2>
<pre class="literal-block">
#define TIMERMILLIC_SERVICE ...
--- 642,647 ----
BusyWaitMicroC</dd>
</dl>
! <div class="section">
! <h2><a id="timermillic" name="timermillic">TimerMilliC</a></h2>
<pre class="literal-block">
#define TIMERMILLIC_SERVICE ...
***************
*** 654,659 ****
parameterised interface.</p>
</div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
--- 657,662 ----
parameterised interface.</p>
</div>
! <div class="section">
! <h2><a id="busywaitmicroc" name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
***************
*** 668,673 ****
</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>
--- 671,676 ----
</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>
***************
*** 682,687 ****
<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">
--- 685,690 ----
<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">
***************
*** 693,698 ****
</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>
--- 696,701 ----
</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>
***************
*** 706,711 ****
</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">
--- 709,714 ----
</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">
***************
*** 717,726 ****
</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(),
--- 720,729 ----
</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(),
***************
*** 746,751 ****
</pre>
</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">
--- 749,754 ----
</pre>
</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">
***************
*** 778,783 ****
</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>
--- 781,786 ----
</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>
***************
*** 792,797 ****
</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">
--- 795,800 ----
</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">
***************
*** 869,874 ****
</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>
--- 872,877 ----
</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>
***************
*** 900,904 ****
/// 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
--- 903,907 ----
/// 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
***************
*** 931,935 ****
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
--- 934,938 ----
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
***************
*** 969,974 ****
</pre>
</div>
! <div class="section" id="appendix-c-a-mote-mica2-timer-subsystem">
! <h1><a name="appendix-c-a-mote-mica2-timer-subsystem">Appendix C: a mote: Mica2 timer subsystem</a></h1>
<p>The mica2 HAL exposes its four timers as follows:</p>
<ul class="simple">
--- 972,977 ----
</pre>
</div>
! <div class="section">
! <h1><a id="appendix-c-a-mote-mica2-timer-subsystem" name="appendix-c-a-mote-mica2-timer-subsystem">Appendix C: a mote: Mica2 timer subsystem</a></h1>
<p>The mica2 HAL exposes its four timers as follows:</p>
<ul class="simple">
Index: tep103.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep103.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
*** tep103.html 18 May 2006 23:07:25 -0000 1.1.2.1
--- tep103.html 9 Jun 2006 21:12:17 -0000 1.1.2.2
***************
*** 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>Permanent Data Storage (Flash)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
--- 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>Permanent Data Storage (Flash)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
***************
*** 217,221 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 217,225 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 272,277 ****
font-size: 100% }
! tt {
! background-color: #eeeeee }
ul.auto-toc {
--- 276,280 ----
font-size: 100% }
! tt {}
ul.auto-toc {
***************
*** 301,307 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">27-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.2</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-02-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">27-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.8</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-07</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,333 ****
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This memo documents a set of hardware-independent, non-volatile
storage interfaces for TinyOS 2.x, and the HPL and HAL layers for
various flash chips.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>There are three different flash chip families under use or
consideration for TinyOS platforms: the Atmel AT45DB family (Mica
family, Telos rev. A), the ST M25P family (Telos rev. B, eyes) and the
! Intel Strataflash (imote2). All three are "NOR" flash chips, but the
! AT45DB has fairly different characteristics (see below). There also
! "NAND" flash chips which have rather different tradeoffs from NOR
flash. Compact flash/etc cards use NAND flash but present a disk-like
block interface.</p>
--- 319,336 ----
TEP 1.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo documents a set of hardware-independent, non-volatile
storage interfaces for TinyOS 2.x, and the HPL and HAL layers for
various flash chips.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>There are three different flash chip families under use or
consideration for TinyOS platforms: the Atmel AT45DB family (Mica
family, Telos rev. A), the ST M25P family (Telos rev. B, eyes) and the
! Intel Strataflash (Intel Mote2). All three are "NOR" flash chips, but
! the AT45DB has fairly different characteristics (see below). There
! also "NAND" flash chips which have rather different tradeoffs from NOR
flash. Compact flash/etc cards use NAND flash but present a disk-like
block interface.</p>
***************
*** 342,353 ****
Writes : Slow (100s kB/s) Slow (60kB/s) Fast (MBs/s)
Write unit : 1 bit 256B 100's of bytes
! Bit-errors : Low Low High (requires ECC,
bad-block mapping)
! Read : Fast* Slow+I/O bus Fast (but limited by
I/O bus)
Erase cycles : 10^4 - 10^5 10^4 ** 10^5 - 10^7
Intended use : Code storage Data storage Data storage
! * imote2 NOR flash is memory mapped (reads are very fast and can
directly execute code)
** Or infinite? Data sheet just says that every page within a sector
--- 345,356 ----
Writes : Slow (100s kB/s) Slow (60kB/s) Fast (MBs/s)
Write unit : 1 bit 256B 100's of bytes
! Bit-errors : Low Low High (requires ECC,
bad-block mapping)
! Read : Fast* Slow+I/O bus Fast (but limited by
I/O bus)
Erase cycles : 10^4 - 10^5 10^4 ** 10^5 - 10^7
Intended use : Code storage Data storage Data storage
! * Intel Mote2 NOR flash is memory mapped (reads are very fast and can
directly execute code)
** Or infinite? Data sheet just says that every page within a sector
***************
*** 363,616 ****
of the bus + processor.</p>
</div>
! <div class="section" id="non-volatile-storage-abstraction-in-tinyos-2-x">
! <h1><a name="non-volatile-storage-abstraction-in-tinyos-2-x">2. Non-Volatile Storage Abstraction in TinyOS 2.x</a></h1>
! <p>The very significant differences between the flash chips used in
! TinyOS preclude common, low-level HIL interfaces such as a disk-like
! block interface. Instead, we propose that the HIL interfaces
! correspond to high-level storage services useful for sensor network
! applications. We have identified three storage abstractions: large
! object, small objects, and logs. We envision separate implementations
! of these abstractions for each class of storage chip; these
! implementations will be found in the new tos/chips/CHIPNAME hierarchy.</p>
! <div class="section" id="large-objects">
! <h2><a name="large-objects">2.1 Large objects:</a></h2>
! <p>This scenario involves getting a large (100's bytes to kilobytes or
! more) free chunk (through alloc or erase), writing to each byte/block
! once in any arbitrary order, and "committing" when the chunk is
! filled.</p>
<blockquote>
! Size: large
! Reads: random
! Writes: random (minimum block size?), each block written once
! Failure model: no fault tolerance (crash before commit leads to
! object loss)
! Other: a commit operation terminates writes, a validate operation
! checks the object.</blockquote>
</div>
! <div class="section" id="large-sequential-objects-logs">
! <h2><a name="large-sequential-objects-logs">2.2 Large sequential objects (Logs)</a></h2>
! <p>Some applications (e.g., low-rate data collection) may want to log all
! their results in a reliable fashion, possibly in a circular buffer.</p>
<blockquote>
! <p>Size: large
! Reads: from memorized write points or beginning
! Writes: sequential, object is linear or circular</p>
! <p>Failure model: writes are atomic, failure during/between writes does
not lead to whole object loss, but may lead to loss of some entries
(but see sync)
! Note: failure during write may lead to (minor) capacity reduction
! Other: sync: guarantees already written data will not be lost to
! (crash-style) failure</p>
</blockquote>
</div>
! <div class="section" id="small-objects">
! <h2><a name="small-objects">2.3 Small objects:</a></h2>
! <p>This scenario involves keeping a small chunk (less than 100 some
! bytes). Requires multiple and random reads/writes.</p>
<blockquote>
! Size: small
! Reads: random
! Writes: random, no minimum block size, rewrite ok
! Failure model: writes are atomic, failure during/between writes
! does not lead to object loss</blockquote>
</div>
</div>
! <div class="section" id="hpl-hal-hil-architecture">
! <h1><a name="hpl-hal-hil-architecture">3. HPL/HAL/HIL Architecture</a></h1>
<p>The proposed architecture aligns with the three-layer Hardware
! Abstraction Architecture (HAA).</p>
! <div class="section" id="hardware-presentation-layer-hpl">
! <h2><a name="hardware-presentation-layer-hpl">3.1 Hardware Presentation Layer (HPL)</a></h2>
! <ol class="loweralpha">
! <li><p class="first">Implementation: system dependent</p>
! </li>
! <li><p class="first">Presentation: chip (family?) dependent (common HPL for same chip
! (family?) on different systems)</p>
! </li>
! <li><p class="first">Stateless</p>
! </li>
! <li><p class="first">Atmel 45DB family low-level interfaces</p>
! <p>select, send/receive SPI byte, idle detection
! (no commands, as efficiency dictates their integration in the HAL)
! See tos/platform/mica/HPLFlashM</p>
! </li>
! <li><p class="first">Intel Strataflash</p>
! <p>write data, erase, lock/unlock blocks, read config data, etc.
! details omitted - main interesting point is lack of reads, as
! device is memory mapped</p>
! </li>
! <li><p class="first">M25P family</p>
! <p>r/w data, erase (sector or chip), r/w status, etc
! (full details omitted)</p>
! </li>
! </ol>
! </div>
! <div class="section" id="hardware-adaptation-layer-hal">
! <h2><a name="hardware-adaptation-layer-hal">3.2 Hardware Adaptation Layer (HAL)</a></h2>
! <ol class="loweralpha">
! <li><p class="first">Implementation: chip dependent</p>
! </li>
! <li><p class="first">Presentation: chip dependent</p>
! </li>
! <li><p class="first">Atmel AT45DB: