[Tinyos-2-commits] CVS: tinyos-2.x/doc/html overview.html, 1.6,
1.7 porting.html, 1.5, 1.6 tep1.html, 1.6, 1.7 tep101.html,
1.8, 1.9 tep102.html, 1.6, 1.7 tep103.html, 1.6,
1.7 tep106.html, 1.8, 1.9 tep107.html, 1.12, 1.13 tep108.html,
1.9, 1.10 tep109.html, 1.7, 1.8 tep110.html, 1.6,
1.7 tep111.html, 1.9, 1.10 tep112.html, 1.8, 1.9 tep113.html,
1.8, 1.9 tep114.html, 1.7, 1.8 tep115.html, 1.8,
1.9 tep116.html, 1.11, 1.12 tep117.html, 1.6, 1.7 tep118.html,
1.6, 1.7 tep119.html, 1.9, 1.10 tep120.html, 1.6,
1.7 tep121.html, 1.6, 1.7 tep123.html, 1.8, 1.9 tep124.html,
1.2, 1.3 tep125.html, 1.2, 1.3 tep126.html, 1.1, 1.2 tep2.html,
1.10, 1.11 tep3.html, 1.6, 1.7
Phil Levis
scipio at users.sourceforge.net
Sat Apr 21 00:04:43 PDT 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv20891
Modified Files:
overview.html porting.html tep1.html tep101.html tep102.html
tep103.html tep106.html tep107.html tep108.html tep109.html
tep110.html tep111.html tep112.html tep113.html tep114.html
tep115.html tep116.html tep117.html tep118.html tep119.html
tep120.html tep121.html tep123.html tep124.html tep125.html
tep126.html tep2.html tep3.html
Log Message:
Regenerate for 2.0.1.
Index: overview.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/overview.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** overview.html 12 Dec 2006 18:22:53 -0000 1.6
--- overview.html 21 Apr 2007 07:04:39 -0000 1.7
***************
*** 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" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>TinyOS 2.0 Overview</title>
<meta name="author" content="Philip Levis" />
***************
*** 284,288 ****
</head>
<body>
- <div class="document" id="tinyos-2-0-overview">
<h1 class="title">TinyOS 2.0 Overview</h1>
<table class="docinfo" frame="void" rules="none">
--- 284,287 ----
***************
*** 296,299 ****
--- 295,299 ----
</tbody>
</table>
+ <div class="document" id="tinyos-2-0-overview">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 302,307 ****
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
--- 302,307 ----
is detailed in TEP (TinyOS Enhancement Proposal) documents.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS.
Its development was motivated by our belief that many aspects of 1.x
***************
*** 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
--- 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
***************
*** 378,383 ****
<p>The btnode3 platform is not included in the RPM.</p>
</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
--- 378,383 ----
<p>The btnode3 platform is not included in the RPM.</p>
</div>
! <div class="section" id="scheduler">
! <h1><a name="scheduler">3. Scheduler</a></h1>
<p>As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO
policy. However, tasks in 2.0 operate slightly differently than in
***************
*** 407,412 ****
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
--- 407,412 ----
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
***************
*** 421,431 ****
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
--- 421,431 ----
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
***************
*** 437,442 ****
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
--- 437,442 ----
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
***************
*** 448,452 ****
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
--- 448,452 ----
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
***************
*** 465,470 ****
</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
--- 465,470 ----
</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
***************
*** 487,492 ****
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
--- 487,492 ----
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
***************
*** 496,502 ****
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.
--- 496,502 ----
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.
***************
*** 511,516 ****
the CC2420 radio (micaz, telosb, and intelmote2 platforms).</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
--- 511,516 ----
the CC2420 radio (micaz, telosb, and intelmote2 platforms).</p>
</div>
! <div class="section" id="sensors">
! <h1><a name="sensors">8. Sensors</a></h1>
<p>In TinyOS 2.0, named sensor components comprise the HIL of a
platform's sensors. TEP 114 describes a set of HIL data acquisition
***************
*** 530,535 ****
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
--- 530,535 ----
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
***************
*** 543,547 ****
<pre class="literal-block">
if (call X.y()) {
! busy = TRUE;
}
</pre>
--- 543,547 ----
<pre class="literal-block">
if (call X.y()) {
! busy = TRUE;
}
</pre>
***************
*** 555,562 ****
</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.
--- 555,562 ----
</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.
***************
*** 564,570 ****
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
--- 564,570 ----
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
***************
*** 573,582 ****
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
--- 573,582 ----
and how arbiters work.</p>
</div>
! <div class="section" id="power-management">
! <h1><a name="power-management">11. Power Management</a></h1>
<p>Power management in 2.0 is divided into two parts: the power state
of the microcontroller and the power state of devices. The former,
discussed in TEP 112: Microcontroller Power Management[<a class="reference" href="#tep112">TEP112</a>],
! is computed in a chip-specific manner by examining which devices
and interrupt souces are active. The latter, discussed in
TEP 115: Power Management of Non-Virtualised Devices{<a class="reference" href="#tep115">TEP115</a>], is handled
***************
*** 586,612 ****
and CC2420 (micaz, telosb, imote2) radios. Both use a low-power
listening apporach, where transmitters send long preambles or
! repeatedly send packets and receivers wake up periodically to
! sense the channel to hear if there is a packet being
transmitted. The low-power stack CC1000 is standard, while
the CC2420 stack is experimental. That is, the default CC1000
! stack (chips/cc1000) has low-power-listening, while the default
CC2420 stack (chips/cc2420) does not. To use the low-power CC2420
stack, you must include chips/cc2420_lpl in your application Makefile.</p>
</div>
! <div class="section">
! <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. Collection has advanced significantly since the
! most recent beta release; experimental tests in multiple
network conditions have seen very high (>98%) deliver rates
as long as the network is not saturated.</p>
</div>
! <div class="section">
! <h1><a id="conclusion" name="conclusion">13. Conclusion</a></h1>
<p>TinyOS 2.0 represents the next step of TinyOS development. Building on
user experiences over the past few years, it has taken the basic
--- 586,612 ----
and CC2420 (micaz, telosb, imote2) radios. Both use a low-power
listening apporach, where transmitters send long preambles or
! repeatedly send packets and receivers wake up periodically to
! sense the channel to hear if there is a packet being
transmitted. The low-power stack CC1000 is standard, while
the CC2420 stack is experimental. That is, the default CC1000
! stack (chips/cc1000) has low-power-listening, while the default
CC2420 stack (chips/cc2420) does not. To use the low-power CC2420
stack, you must include chips/cc2420_lpl in your application Makefile.</p>
</div>
! <div class="section" id="network-protocols">
! <h1><a name="network-protocols">12. Network Protocols</a></h1>
! <p>TinyOS 2.0 provides simple reference implementations of two of
the most basic protocols used in mote networks: dissemination
! and collection. Dissemination reliably delivers small (fewer
than 20 byte) data items to every node in a network, while
collection builds a routing tree rooted at a sink node. Together,
these two protocols enable a wide range of data collection
applications. Collection has advanced significantly since the
! most recent beta release; experimental tests in multiple
network conditions have seen very high (>98%) deliver rates
as long as the network is not saturated.</p>
</div>
! <div class="section" id="conclusion">
! <h1><a name="conclusion">13. Conclusion</a></h1>
<p>TinyOS 2.0 represents the next step of TinyOS development. Building on
user experiences over the past few years, it has taken the basic
***************
*** 617,633 ****
dissemination), and further power management abstractions.</p>
</div>
! <div class="section">
! <h1><a id="acknowledgments" name="acknowledgments">14. Acknowledgments</a></h1>
<p>TinyOS 2.0 is the result of a lot of hard work from a lot of people,
! including (but not limited to) David Gay, Philip Levis, Cory Sharp,
! Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui,
! Prabal Dutta,
! Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler,
! Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel,
Robert Szewczyk, Rodrigo Fonseca, Kyle Jamieson, Omprakash Gnawali,
David Moss, and Kristin Wright.</p>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">15. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
--- 617,633 ----
dissemination), and further power management abstractions.</p>
</div>
! <div class="section" id="acknowledgments">
! <h1><a name="acknowledgments">14. Acknowledgments</a></h1>
<p>TinyOS 2.0 is the result of a lot of hard work from a lot of people,
! including (but not limited to) David Gay, Philip Levis, Cory Sharp,
! Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui,
! Prabal Dutta,
! Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler,
! Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel,
Robert Szewczyk, Rodrigo Fonseca, Kyle Jamieson, Omprakash Gnawali,
David Moss, and Kristin Wright.</p>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">15. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
***************
*** 642,647 ****
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">16. Citations</a></h1>
<table class="docutils citation" frame="void" id="tep1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
--- 642,647 ----
</div>
</div>
! <div class="section" id="citations">
! <h1><a name="citations">16. Citations</a></h1>
<table class="docutils citation" frame="void" id="tep1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
Index: porting.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/porting.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** porting.html 12 Dec 2006 18:22:53 -0000 1.5
--- porting.html 21 Apr 2007 07:04:39 -0000 1.6
***************
*** 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>Porting TinyOS 1.x Code to TinyOS 2.0</title>
<meta name="author" content="Tahir Azim and Philip Levis" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>Porting TinyOS 1.x Code to TinyOS 2.0</title>
<meta name="author" content="Tahir Azim and Philip Levis" />
***************
*** 285,289 ****
</head>
<body>
- <div class="document" id="porting-tinyos-1-x-code-to-tinyos-2-0">
<h1 class="title">Porting TinyOS 1.x Code to TinyOS 2.0</h1>
<table class="docinfo" frame="void" rules="none">
--- 285,288 ----
***************
*** 297,303 ****
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
! <p class="last">This document provides a few important points that describe
major steps required for porting TinyOS 1.x code to TinyOS 2.0.
It is based on Tahir Azim's experience porting Beacon Vector
--- 296,303 ----
</tbody>
</table>
+ <div class="document" id="porting-tinyos-1-x-code-to-tinyos-2-0">
<div class="note">
<p class="first admonition-title">Note</p>
! <p class="last">This document provides a few important points that describe
major steps required for porting TinyOS 1.x code to TinyOS 2.0.
It is based on Tahir Azim's experience porting Beacon Vector
***************
*** 306,311 ****
some help or guidance.</p>
</div>
! <div class="section">
! <h1><a id="porting-points" name="porting-points">1. Porting Points</a></h1>
<p>As these observations come from porting a network protocol, they are
rather protocol-centric and do not consider other abstractions such
--- 306,311 ----
some help or guidance.</p>
</div>
! <div class="section" id="porting-points">
! <h1><a name="porting-points">1. Porting Points</a></h1>
<p>As these observations come from porting a network protocol, they are
rather protocol-centric and do not consider other abstractions such
***************
*** 323,327 ****
<p>In TinyOS 2.x, SUCCESS is equal to a zero error code, while other error codes are non-zero. So calls like this should be changed to make sure they test the result for equality with SUCCESS:</p>
<pre class="literal-block">
! if (call Packet... () == SUCCESS ) {
//SUCCESS!: do this...
}
--- 323,327 ----
<p>In TinyOS 2.x, SUCCESS is equal to a zero error code, while other error codes are non-zero. So calls like this should be changed to make sure they test the result for equality with SUCCESS:</p>
<pre class="literal-block">
! if (call Packet... () == SUCCESS ) {
//SUCCESS!: do this...
}
***************
*** 343,348 ****
</blockquote>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">2. Author's Address</a></h1>
<div class="line-block">
<div class="line">Tahir Azim</div>
--- 343,348 ----
</blockquote>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">2. Author's Address</a></h1>
<div class="line-block">
<div class="line">Tahir Azim</div>
***************
*** 365,370 ****
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">3. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
--- 365,370 ----
</div>
</div>
! <div class="section" id="citations">
! <h1><a name="citations">3. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
Index: tep1.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep1.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep1.html 12 Dec 2006 18:22:53 -0000 1.6
--- tep1.html 21 Apr 2007 07:04:39 -0000 1.7
***************
*** 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" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>TEP Structure and Keywords</title>
<meta name="author" content="Philip Levis" />
***************
*** 284,288 ****
</head>
<body>
- <div class="document" id="tep-structure-and-keywords">
<h1 class="title">TEP Structure and Keywords</h1>
<table class="docinfo" frame="void" rules="none">
--- 284,287 ----
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">18-Oct-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-19</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>
--- 303,309 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">18-Oct-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-12-12</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 312,315 ****
--- 311,315 ----
</tbody>
</table>
+ <div class="document" id="tep-structure-and-keywords">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 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
--- 318,329 ----
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
***************
*** 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
--- 333,338 ----
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
***************
*** 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
--- 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" 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
***************
*** 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
--- 357,362 ----
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
***************
*** 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
--- 365,370 ----
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
***************
*** 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
--- 379,384 ----
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
***************
*** 390,408 ****
</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="footnote-reference" href="#id2" id="id1" name="id1">[1]</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
included in all TEPs, in the order stated here.</p>
<p>The first field is "TEP," and specifies the TEP number of the
! document. A TEP's number is unique.. This document is TEP 1. The
TEP type (discussed below)
determines how a number is assigned to it. Generally, when a document
--- 390,408 ----
</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="footnote-reference" href="#id2" id="id1" name="id1">[1]</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
included in all TEPs, in the order stated here.</p>
<p>The first field is "TEP," and specifies the TEP number of the
! document. A TEP's number is unique.. This document is TEP 1. The
TEP type (discussed below)
determines how a number is assigned to it. Generally, when a document
***************
*** 422,426 ****
<p>Documentary TEPs describe a system or protocol that exists; a
documentary TEP MUST reference an implementation that a reader can
! easily obtain. Documentary TEPs simplify interoperability when
needed, and document TinyOS service implementations.</p>
<p>Informational TEPs provide information that is of interest to the
--- 422,426 ----
<p>Documentary TEPs describe a system or protocol that exists; a
documentary TEP MUST reference an implementation that a reader can
! easily obtain. Documentary TEPs simplify interoperability when
needed, and document TinyOS service implementations.</p>
<p>Informational TEPs provide information that is of interest to the
***************
*** 431,440 ****
<p>Experimental TEPs describe a completely experimental approach to a
problem, which are outside the TinyOS core and will not necessarily
! become part of it. Unlike Documentary TEPs, Experimental TEPs may
describe systems that do not have a reference implementation.</p>
<p>The fourth field is "Status," which specifies the status of the TEP.
A TEP status can either be "Draft," which means it is a work in
! progress, "Final," which means it is complete and will not change.
! Once a TEP has the status "Final," its body MUST NOT change.
The values of its header fields MUST NOT change. The header of a
Final TEP MAY have an "Obsoleted By" field added.</p>
--- 431,440 ----
<p>Experimental TEPs describe a completely experimental approach to a
problem, which are outside the TinyOS core and will not necessarily
! become part of it. Unlike Documentary TEPs, Experimental TEPs may
describe systems that do not have a reference implementation.</p>
<p>The fourth field is "Status," which specifies the status of the TEP.
A TEP status can either be "Draft," which means it is a work in
! progress, "Final," which means it is complete and will not change.
! Once a TEP has the status "Final," its body MUST NOT change.
The values of its header fields MUST NOT change. The header of a
Final TEP MAY have an "Obsoleted By" field added.</p>
***************
*** 464,468 ****
another TEP. The purpose of this field is to denote when a TEP represents
an addition to an existing TEP. Meeting the requirements of a TEP with an
! Extends field requires also meeting the requirements of all TEPs listed
in the Extends field.</p>
<p>If a TEP is a Draft, then four additional fields MUST be included:
--- 464,468 ----
another TEP. The purpose of this field is to denote when a TEP represents
an addition to an existing TEP. Meeting the requirements of a TEP with an
! Extends field requires also meeting the requirements of all TEPs listed
in the Extends field.</p>
<p>If a TEP is a Draft, then four additional fields MUST be included:
***************
*** 475,480 ****
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
--- 475,480 ----
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
***************
*** 494,508 ****
</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>
--- 494,508 ----
</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>
***************
*** 516,521 ****
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">7. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
--- 516,521 ----
</div>
</div>
! <div class="section" id="citations">
! <h1><a name="citations">7. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep101.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** tep101.html 17 Jan 2007 08:46:38 -0000 1.8
--- tep101.html 21 Apr 2007 07:04:39 -0000 1.9
***************
*** 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" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay" />
***************
*** 284,288 ****
</head>
<body>
- <div class="document" id="analog-to-digital-converters-adcs">
<h1 class="title">Analog-to-Digital Converters (ADCs)</h1>
<table class="docinfo" frame="void" rules="none">
--- 284,287 ----
***************
*** 304,307 ****
--- 303,307 ----
</tbody>
</table>
+ <div class="document" id="analog-to-digital-converters-adcs">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 311,316 ****
<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 analog-to-digital converters (ADCs)
in TinyOS 2.x, which is aligned to the three-layer Hardware Abstraction
--- 311,316 ----
<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 analog-to-digital converters (ADCs)
in TinyOS 2.x, which is aligned to the three-layer Hardware Abstraction
***************
*** 318,323 ****
documents the set of hardware-independent interfaces to an ADC.</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 binary
--- 318,323 ----
documents the set of hardware-independent interfaces to an ADC.</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 binary
***************
*** 422,429 ****
<li>the set of standard TinyOS interfaces for collecting ADC conversion
results and for configuring an ADC (<a class="reference" href="#interfaces">2. Interfaces</a>)</li>
! <li>guidelines on how an ADC's HAL should expose chip-specific
interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
<li>what components an ADC's HIL MUST implement (<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
! <li>guidelines on how the HIL should be implemented
(<a class="reference" href="#hil-guidelines">5. HIL guidelines</a>)</li>
<li>a section pointing to current implementations (<a class="reference" href="#implementation">6. Implementation</a>)</li>
--- 422,429 ----
<li>the set of standard TinyOS interfaces for collecting ADC conversion
results and for configuring an ADC (<a class="reference" href="#interfaces">2. Interfaces</a>)</li>
! <li>guidelines on how an ADC's HAL should expose chip-specific
interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
<li>what components an ADC's HIL MUST implement (<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
! <li>guidelines on how the HIL should be implemented
(<a class="reference" href="#hil-guidelines">5. HIL guidelines</a>)</li>
<li>a section pointing to current implementations (<a class="reference" href="#implementation">6. Implementation</a>)</li>
***************
*** 432,437 ****
for the TI MSP430 MCU.</p>
</div>
! <div class="section">
! <h1><a id="interfaces" name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes the <tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface for ADC hardware configuration
and the <tt class="docutils literal"><span class="pre">Read</span></tt>, <tt class="docutils literal"><span class="pre">ReadStream</span></tt> and <tt class="docutils literal"><span class="pre">ReadNow</span></tt> interfaces to acquire
--- 432,437 ----
for the TI MSP430 MCU.</p>
</div>
! <div class="section" id="interfaces">
! <h1><a name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes the <tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface for ADC hardware configuration
and the <tt class="docutils literal"><span class="pre">Read</span></tt>, <tt class="docutils literal"><span class="pre">ReadStream</span></tt> and <tt class="docutils literal"><span class="pre">ReadNow</span></tt> interfaces to acquire
***************
*** 440,450 ****
<tt class="docutils literal"><span class="pre">Read[Now|Stream]</span></tt> interface is always provided in conjunction with a
<tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface.</p>
! <div class="section">
! <h2><a id="interface-for-configuring-the-adc-hardware" name="interface-for-configuring-the-adc-hardware">Interface for configuring the ADC hardware</a></h2>
<p>The <tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface is defined as follows:</p>
<pre class="literal-block">
! interface AdcConfigure< config_type >
{
! async command config_type getConfiguration();
}
</pre>
--- 440,450 ----
<tt class="docutils literal"><span class="pre">Read[Now|Stream]</span></tt> interface is always provided in conjunction with a
<tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface.</p>
! <div class="section" id="interface-for-configuring-the-adc-hardware">
! <h2><a name="interface-for-configuring-the-adc-hardware">Interface for configuring the ADC hardware</a></h2>
<p>The <tt class="docutils literal"><span class="pre">AdcConfigure</span></tt> interface is defined as follows:</p>
<pre class="literal-block">
! interface AdcConfigure< config_type >
{
! async command config_type getConfiguration();
}
</pre>
***************
*** 469,474 ****
configuration in program memory.</p>
</div>
! <div class="section">
! <h2><a id="interfaces-for-acquiring-conversion-results" name="interfaces-for-acquiring-conversion-results">Interfaces for acquiring conversion results</a></h2>
<p>This TEP proposes to adopt the following two source-independent data
collection interfaces from <a class="citation-reference" href="#tep114" id="id10" name="id10">[TEP114]</a> for the collection of ADC conversion
--- 469,474 ----
configuration in program memory.</p>
</div>
! <div class="section" id="interfaces-for-acquiring-conversion-results">
! <h2><a name="interfaces-for-acquiring-conversion-results">Interfaces for acquiring conversion results</a></h2>
<p>This TEP proposes to adopt the following two source-independent data
collection interfaces from <a class="citation-reference" href="#tep114" id="id10" name="id10">[TEP114]</a> for the collection of ADC conversion
***************
*** 489,510 ****
resolution of the conversion results - the actual resolution may be smaller
(e.g. uint16_t for a 12-bit ADC).</p>
! <div class="section">
! <h3><a id="read" name="read">Read</a></h3>
<p>The <tt class="docutils literal"><span class="pre">Read</span></tt> interface can be used to sample an ADC channel once and return a
single conversion result as an uninterpreted value. The <tt class="docutils literal"><span class="pre">Read</span></tt> interface is
documented in <a class="citation-reference" href="#tep114" id="id11" name="id11">[TEP114]</a>.</p>
</div>
! <div class="section">
! <h3><a id="readstream" name="readstream">ReadStream</a></h3>
<p>The <tt class="docutils literal"><span class="pre">ReadStream</span></tt> interface can be used to sample an ADC channel multiple
times with a specified sampling period. The <tt class="docutils literal"><span class="pre">ReadStream</span></tt> interface is
documented in <a class="citation-reference" href="#tep114" id="id12" name="id12">[TEP114]</a> .</p>
</div>
! <div class="section">
! <h3><a id="readnow" name="readnow">ReadNow</a></h3>
<p>The <tt class="docutils literal"><span class="pre">ReadNow</span></tt> interface is intended for split-phase low-latency
reading of small values:</p>
<pre class="literal-block">
! interface ReadNow<val_t>
{
async command error_t read();
--- 489,510 ----
resolution of the conversion results - the actual resolution may be smaller
(e.g. uint16_t for a 12-bit ADC).</p>
! <div class="section" id="read">
! <h3><a name="read">Read</a></h3>
<p>The <tt class="docutils literal"><span class="pre">Read</span></tt> interface can be used to sample an ADC channel once and return a
single conversion result as an uninterpreted value. The <tt class="docutils literal"><span class="pre">Read</span></tt> interface is
documented in <a class="citation-reference" href="#tep114" id="id11" name="id11">[TEP114]</a>.</p>
</div>
! <div class="section" id="readstream">
! <h3><a name="readstream">ReadStream</a></h3>
<p>The <tt class="docutils literal"><span class="pre">ReadStream</span></tt> interface can be used to sample an ADC channel multiple
times with a specified sampling period. The <tt class="docutils literal"><span class="pre">ReadStream</span></tt> interface is
documented in <a class="citation-reference" href="#tep114" id="id12" name="id12">[TEP114]</a> .</p>
</div>
! <div class="section" id="readnow">
! <h3><a name="readnow">ReadNow</a></h3>
<p>The <tt class="docutils literal"><span class="pre">ReadNow</span></tt> interface is intended for split-phase low-latency
reading of small values:</p>
<pre class="literal-block">
! interface ReadNow<val_t>
{
async command error_t read();
***************
*** 526,531 ****
</div>
</div>
! <div class="section">
! <h1><a id="hal-guidelines" name="hal-guidelines">3. HAL guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL exposes the full capabilities of the
ADC hardware. Therefore only chip- and platform-dependent clients can wire to
--- 526,531 ----
</div>
</div>
! <div class="section" id="hal-guidelines">
! <h1><a name="hal-guidelines">3. HAL guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL exposes the full capabilities of the
ADC hardware. Therefore only chip- and platform-dependent clients can wire to
***************
*** 534,539 ****
section to facilitate the mapping to the HIL representation. Appendix B shows
the signature of the HAL for the MSP430.</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 usually multiplexed between
several clients some form of access arbitration is necessary. The HAL should
--- 534,539 ----
section to facilitate the mapping to the HIL representation. Appendix B shows
the signature of the HAL for the MSP430.</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 usually multiplexed between
several clients some form of access arbitration is necessary. The HAL should
***************
*** 544,549 ****
arbiters and the <tt class="docutils literal"><span class="pre">Resource</span></tt> interface are the topic of <a class="citation-reference" href="#tep108" id="id15" name="id15">[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 HAL should support hardware
configuration and sampling per client (although per-port configuration is
--- 544,549 ----
arbiters and the <tt class="docutils literal"><span class="pre">Resource</span></tt> interface are the topic of <a class="citation-reference" href="#tep108" id="id15" name="id15">[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 HAL should support hardware
configuration and sampling per client (although per-port configuration is
***************
*** 567,572 ****
interfaces for the MSP430.</p>
</div>
! <div class="section">
! <h2><a id="hal-virtualization" name="hal-virtualization">HAL 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 HAL.
--- 567,572 ----
interfaces for the MSP430.</p>
</div>
! <div class="section" id="hal-virtualization">
! <h2><a name="hal-virtualization">HAL 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 HAL.
***************
*** 576,587 ****
</div>
</div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
<p>The following generic components MUST be provided on all platforms that have an
ADC:</p>
<pre class="literal-block">
! AdcReadClientC
! AdcReadNowClientC
! AdcReadStreamClientC
</pre>
<p>These components provide virtualized access to the HIL of an ADC. They are
--- 576,587 ----
</div>
</div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
<p>The following generic components MUST be provided on all platforms that have an
ADC:</p>
<pre class="literal-block">
! AdcReadClientC
! AdcReadNowClientC
! AdcReadStreamClientC
</pre>
<p>These components provide virtualized access to the HIL of an ADC. They are
***************
*** 593,598 ****
is a general one in TinyOS 2.x). Appendix C shows the <tt class="docutils literal"><span class="pre">AdcReadClientC</span></tt> for
the MSP430.</p>
! <div class="section">
! <h2><a id="adcreadclientc" name="adcreadclientc">AdcReadClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadClientC() {
--- 593,598 ----
is a general one in TinyOS 2.x). Appendix C shows the <tt class="docutils literal"><span class="pre">AdcReadClientC</span></tt> for
the MSP430.</p>
! <div class="section" id="adcreadclientc">
! <h2><a name="adcreadclientc">AdcReadClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadClientC() {
***************
*** 616,621 ****
an example, see the AdcReadClientC for the MSP430 in Appendix C).</p>
</div>
! <div class="section">
! <h2><a id="adcreadnowclientc" name="adcreadnowclientc">AdcReadNowClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClientC() {
--- 616,621 ----
an example, see the AdcReadClientC for the MSP430 in Appendix C).</p>
</div>
! <div class="section" id="adcreadnowclientc">
! <h2><a name="adcreadnowclientc">AdcReadNowClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClientC() {
***************
*** 648,653 ****
done for the AdcReadClientC see Appendix C).</p>
</div>
! <div class="section">
! <h2><a id="adcreadstreamclientc" name="adcreadstreamclientc">AdcReadStreamClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClientC() {
--- 648,653 ----
done for the AdcReadClientC see Appendix C).</p>
</div>
! <div class="section" id="adcreadstreamclientc">
! <h2><a name="adcreadstreamclientc">AdcReadStreamClientC</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClientC() {
***************
*** 669,674 ****
</div>
</div>
! <div class="section">
! <h1><a id="hil-guidelines" name="hil-guidelines">5. HIL guidelines</a></h1>
<p>The HIL implementation of an ADC stack has two main tasks: it translates a
<tt class="docutils literal"><span class="pre">Read</span></tt>, <tt class="docutils literal"><span class="pre">ReadNow</span></tt> or <tt class="docutils literal"><span class="pre">ReadStream</span></tt> request to a chip-specific HAL sampling
--- 669,674 ----
</div>
</div>
! <div class="section" id="hil-guidelines">
! <h1><a name="hil-guidelines">5. HIL guidelines</a></h1>
<p>The HIL implementation of an ADC stack has two main tasks: it translates a
<tt class="docutils literal"><span class="pre">Read</span></tt>, <tt class="docutils literal"><span class="pre">ReadNow</span></tt> or <tt class="docutils literal"><span class="pre">ReadStream</span></tt> request to a chip-specific HAL sampling
***************
*** 700,707 ****
the conversion result(s) it forwards it to the respective <tt class="docutils literal"><span class="pre">ReadNow</span></tt> client.</p>
</div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
! <div class="section">
! <h2><a id="testadc-application" name="testadc-application">TestAdc application</a></h2>
<p>An ADC HIL test application can be found in <tt class="docutils literal"><span class="pre">tinyos-2.x/apps/tests/TestAdc</span></tt>.
Note that this application instantiates generic DemoSensorC, DemoSensorStreamC
--- 700,707 ----
the conversion result(s) it forwards it to the respective <tt class="docutils literal"><span class="pre">ReadNow</span></tt> client.</p>
</div>
! <div class="section" id="implementation">
! <h1><a name="implementation">6. Implementation</a></h1>
! <div class="section" id="testadc-application">
! <h2><a name="testadc-application">TestAdc application</a></h2>
<p>An ADC HIL test application can be found in <tt class="docutils literal"><span class="pre">tinyos-2.x/apps/tests/TestAdc</span></tt>.
Note that this application instantiates generic DemoSensorC, DemoSensorStreamC
***************
*** 710,715 ****
<tt class="docutils literal"><span class="pre">tinyos-2.x/apps/tests/TestAdc/README.txt</span></tt> for more information.</p>
</div>
! <div class="section">
! <h2><a id="haa-on-the-msp430-and-atmega-128" name="haa-on-the-msp430-and-atmega-128">HAA on the MSP430 and Atmega 128</a></h2>
<p>The implementation of the ADC12 stack on the MSP430 can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430/adc12</span></tt>:</p>
--- 710,715 ----
<tt class="docutils literal"><span class="pre">tinyos-2.x/apps/tests/TestAdc/README.txt</span></tt> for more information.</p>
</div>
! <div class="section" id="haa-on-the-msp430-and-atmega-128">
! <h2><a name="haa-on-the-msp430-and-atmega-128">HAA on the MSP430 and Atmega 128</a></h2>
<p>The implementation of the ADC12 stack on the MSP430 can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430/adc12</span></tt>:</p>
***************
*** 731,735 ****
<li><tt class="docutils literal"><span class="pre">HplAtm128AdcC.nc</span></tt> is the HPL implementation</li>
<li><tt class="docutils literal"><span class="pre">Atm128AdcP.nc</span></tt> is the HAL implementation</li>
! <li><tt class="docutils literal"><span class="pre">AdcP.nc</span></tt>, <tt class="docutils literal"><span class="pre">WireAdcP.nc</span></tt> and the library components for arbitrating
'Read', 'ReadNow' and 'ReadStream', <tt class="docutils literal"><span class="pre">ArbitratedReadC</span></tt> and
<tt class="docutils literal"><span class="pre">ArbitratedReadStreamC</span></tt> (in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/system</span></tt>), realize
--- 731,735 ----
<li><tt class="docutils literal"><span class="pre">HplAtm128AdcC.nc</span></tt> is the HPL implementation</li>
<li><tt class="docutils literal"><span class="pre">Atm128AdcP.nc</span></tt> is the HAL implementation</li>
! <li><tt class="docutils literal"><span class="pre">AdcP.nc</span></tt>, <tt class="docutils literal"><span class="pre">WireAdcP.nc</span></tt> and the library components for arbitrating
'Read', 'ReadNow' and 'ReadStream', <tt class="docutils literal"><span class="pre">ArbitratedReadC</span></tt> and
<tt class="docutils literal"><span class="pre">ArbitratedReadStreamC</span></tt> (in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/system</span></tt>), realize
***************
*** 741,746 ****
</div>
</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 ----
</div>
</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>
***************
*** 752,758 ****
</colgroup>
<thead valign="bottom">
! <tr><th class="head"> </th>
! <th class="head">Atmel Atmega 128</th>
! <th class="head">TI MSP430 ADC12</th>
</tr>
</thead>
--- 752,758 ----
</colgroup>
<thead valign="bottom">
! <tr><th> </th>
! <th>Atmel Atmega 128</th>
! <th>TI MSP430 ADC12</th>
</tr>
</thead>
***************
*** 871,876 ****
</table>
</div>
! <div class="section">
! <h1><a id="appendix-b-a-hal-representation-msp430-adc12" name="appendix-b-a-hal-representation-msp430-adc12">Appendix B: a HAL representation: MSP430 ADC12</a></h1>
<p>This section shows the HAL signature for the ADC12 of the TI MSP430 MCU. It
reflects the four MSP430 ADC12 conversion modes as it lets a client sample an
--- 871,876 ----
</table>
</div>
! <div class="section" id="appendix-b-a-hal-representation-msp430-adc12">
! <h1><a name="appendix-b-a-hal-representation-msp430-adc12">Appendix B: a HAL representation: MSP430 ADC12</a></h1>
<p>This section shows the HAL signature for the ADC12 of the TI MSP430 MCU. It
reflects the four MSP430 ADC12 conversion modes as it lets a client sample an
***************
*** 883,897 ****
responsible for data transfer (managed in an exterior component):</p>
<pre class="literal-block">
! configuration Msp430Adc12P
! {
provides {
! interface Resource[uint8_t id];
! interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
interface AsyncStdControl as DMAExtension[uint8_t id];
}
}
! interface Msp430Adc12SingleChannel
! {
async command error_t configureSingle(const msp430adc12_channel_config_t *config);
async command error_t configureSingleRepeat(const msp430adc12_channel_config_t *config, uint16_t jiffies);
--- 883,897 ----
responsible for data transfer (managed in an exterior component):</p>
<pre class="literal-block">
! configuration Msp430Adc12P
! {
provides {
! interface Resource[uint8_t id];
! interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
interface AsyncStdControl as DMAExtension[uint8_t id];
}
}
! interface Msp430Adc12SingleChannel
! {
async command error_t configureSingle(const msp430adc12_channel_config_t *config);
async command error_t configureSingleRepeat(const msp430adc12_channel_config_t *config, uint16_t jiffies);
***************
*** 900,921 ****
async command error_t getData();
async event error_t singleDataReady(uint16_t data);
! async event uint16_t* multipleDataReady(uint16_t buffer[], uint16_t numSamples);
}
! typedef struct
! {
! unsigned int inch: 4; // input channel
! unsigned int sref: 3; // reference voltage
! unsigned int ref2_5v: 1; // reference voltage level
! unsigned int adc12ssel: 2; // clock source sample-hold-time
! unsigned int adc12div: 3; // clock divider sample-hold-time
unsigned int sht: 4; // sample-hold-time
! unsigned int sampcon_ssel: 2; // clock source sampcon signal
unsigned int sampcon_id: 2; // clock divider sampcon signal
} msp430adc12_channel_config_t;
</pre>
</div>
! <div class="section">
! <h1><a id="appendix-c-a-hil-representation-msp430-adc12" name="appendix-c-a-hil-representation-msp430-adc12">Appendix C: a HIL representation: MSP430 ADC12</a></h1>
<p>The signature of the AdcReadClientC component for the MSP430 ADC12 is as
follows:</p>
--- 900,921 ----
async command error_t getData();
async event error_t singleDataReady(uint16_t data);
! async event uint16_t* multipleDataReady(uint16_t buffer[], uint16_t numSamples);
}
! typedef struct
! {
! unsigned int inch: 4; // input channel
! unsigned int sref: 3; // reference voltage
! unsigned int ref2_5v: 1; // reference voltage level
! unsigned int adc12ssel: 2; // clock source sample-hold-time
! unsigned int adc12div: 3; // clock divider sample-hold-time
unsigned int sht: 4; // sample-hold-time
! unsigned int sampcon_ssel: 2; // clock source sampcon signal
unsigned int sampcon_id: 2; // clock divider sampcon signal
} msp430adc12_channel_config_t;
</pre>
</div>
! <div class="section" id="appendix-c-a-hil-representation-msp430-adc12">
! <h1><a name="appendix-c-a-hil-representation-msp430-adc12">Appendix C: a HIL representation: MSP430 ADC12</a></h1>
<p>The signature of the AdcReadClientC component for the MSP430 ADC12 is as
follows:</p>
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep102.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep102.html 12 Dec 2006 18:22:53 -0000 1.6
--- tep102.html 21 Apr 2007 07:04:39 -0000 1.7
***************
*** 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" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
***************
*** 284,288 ****
</head>
<body>
- <div class="document" id="timers">
<h1 class="title">Timers</h1>
<table class="docinfo" frame="void" rules="none">
--- 284,287 ----
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-18</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 303,309 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.7</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-12-12</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 312,315 ****
--- 311,315 ----
</tbody>
</table>
+ <div class="document" id="timers">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 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
--- 319,324 ----
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This TEP proposes a Timer design that supports common timing
requirements both in precision and width across common hardware
***************
*** 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">
--- 326,331 ----
with the three-layer Hardware Abstraction Architecture (HAA).</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Most microcontrollers offer a rich timer system, with features like:</p>
<ul class="simple">
***************
*** 341,345 ****
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
--- 341,345 ----
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
***************
*** 350,354 ****
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
--- 350,354 ----
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
***************
*** 358,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>
--- 358,368 ----
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>
***************
*** 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">
--- 405,410 ----
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">
***************
*** 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
--- 420,426 ----
advanced user components.</p>
</div>
! <div class="section" id="counter">
! <h2><a name="counter">Counter</a></h2>
! <p>A Counter component will increase the width of a low-level hardware timer
by wrapping the overflow event and incrementing its higher order bits.
These higher order bits are considered extra state over the HPL register
***************
*** 440,446 ****
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending()</dt>
<dd>return TRUE if the overflow flag is set for this counter, i.e., if and
only if an overflow interrupt will occur after the outermost atomic
--- 440,446 ----
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending() </dt>
<dd>return TRUE if the overflow flag is set for this counter, i.e., if and
only if an overflow interrupt will occur after the outermost atomic
***************
*** 449,461 ****
that the underlying hardware platform sets the overflow flag when
appropriate.</dd>
! <dt>clearOverflow()</dt>
<dd>cancel the pending overflow interrupt clearing the overflow flag.</dd>
! <dt>overflow()</dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="alarm" name="alarm">Alarm</a></h2>
<p>Alarm components are extensions of Counters that signal an event
when their compare register detects the alarm time has been hit.
--- 449,461 ----
that the underlying hardware platform sets the overflow flag when
appropriate.</dd>
! <dt>clearOverflow() </dt>
<dd>cancel the pending overflow interrupt clearing the overflow flag.</dd>
! <dt>overflow() </dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section" 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.
***************
*** 480,492 ****
</pre>
<dl class="docutils">
! <dt>start(dt)</dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop()</dt>
<dd>cancel any previously running alarm.</dd>
! <dt>fired()</dt>
<dd>signals that the alarm has occurred.</dd>
! <dt>isRunning()</dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
or has not yet fired. FALSE is returned otherwise.</dd>
--- 480,492 ----
</pre>
<dl class="docutils">
! <dt>start(dt) </dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop() </dt>
<dd>cancel any previously running alarm.</dd>
! <dt>fired() </dt>
<dd>signals that the alarm has occurred.</dd>
! <dt>isRunning() </dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
or has not yet fired. FALSE is returned otherwise.</dd>
***************
*** 500,506 ****
detecting when a short alarm elapses prematurely.</blockquote>
<dl class="docutils">
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm()</dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire. getAlarm can
--- 500,506 ----
detecting when a short alarm elapses prematurely.</blockquote>
<dl class="docutils">
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm() </dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire. getAlarm can
***************
*** 510,515 ****
</dl>
</div>
! <div class="section">
! <h2><a id="busywait" name="busywait">BusyWait</a></h2>
<p>The BusyWait interface allows for very short synchronous delays.
BusyWait should be used sparingly and when an Alarm would not be
--- 510,515 ----
</dl>
</div>
! <div class="section" id="busywait">
! <h2><a name="busywait">BusyWait</a></h2>
<p>The BusyWait interface allows for very short synchronous delays.
BusyWait should be used sparingly and when an Alarm would not be
***************
*** 531,536 ****
</dl>
</div>
! <div class="section">
! <h2><a id="localtime" name="localtime">LocalTime</a></h2>
<p>The LocalTime interface exposes a 32-bit counter without overflow
utilities. This is primarily for application code that does not
--- 531,536 ----
</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
***************
*** 543,552 ****
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="timer" name="timer">Timer</a></h2>
<p>All commands and events of the Timer interface are synchronous (or
in "task context"). The Timer interface provides a set of "basic"
--- 543,552 ----
</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"
***************
*** 573,614 ****
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop()</dt>
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
<dd>signals that the timer has occurred.</dd>
! <dt>isRunning()</dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot()</dt>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt)</dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt)</dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</dd>
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0()</dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt()</dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section">
! <h1><a id="hal-guidelines" name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms SHOULD expose their relevant timing capabilities using
standard Alarm and Counter interfaces. The design pattern presented
--- 573,614 ----
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop() </dt>
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
<dd>signals that the timer has occurred.</dd>
! <dt>isRunning() </dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot() </dt>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt) </dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt) </dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</dd>
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0() </dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt() </dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section" id="hal-guidelines">
! <h1><a name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms SHOULD expose their relevant timing capabilities using
standard Alarm and Counter interfaces. The design pattern presented
***************
*** 655,660 ****
together.</p>
</div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
--- 655,660 ----
together.</p>
</div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
***************
*** 662,667 ****
BusyWaitMicroC</dd>
</dl>
! <div class="section">
! <h2><a id="hiltimermillic" name="hiltimermillic">HilTimerMilliC</a></h2>
<pre class="literal-block">
configuration HilTimerMilliC
--- 662,667 ----
BusyWaitMicroC</dd>
</dl>
! <div class="section" id="hiltimermillic">
! <h2><a name="hiltimermillic">HilTimerMilliC</a></h2>
<pre class="literal-block">
configuration HilTimerMilliC
***************
*** 677,682 ****
TimerMilliC found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt>.</p>
</div>
! <div class="section">
! <h2><a id="busywaitmicroc" name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
--- 677,682 ----
TimerMilliC found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt>.</p>
</div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
***************
*** 691,696 ****
</div>
</div>
! <div class="section">
! <h1><a id="utility-components" name="utility-components">5. Utility components</a></h1>
<p>A number of platform independent generic components are provided to
help implementers and advanced users of the TinyOS timer system:</p>
--- 691,696 ----
</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>
***************
*** 705,710 ****
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section">
! <h2><a id="alarmtotimerc" name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
--- 705,710 ----
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section" id="alarmtotimerc">
! <h2><a name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
***************
*** 716,721 ****
</pre>
</div>
! <div class="section">
! <h2><a id="busywaitcounterc" name="busywaitcounterc">BusyWaitCounterC</a></h2>
<p>BusyWaitCounterC uses a Counter to block until a specified amount of
time elapses.</p>
--- 716,721 ----
</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>
***************
*** 729,734 ****
</pre>
</div>
! <div class="section">
! <h2><a id="countertolocaltimec" name="countertolocaltimec">CounterToLocalTimeC</a></h2>
<p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
<pre class="literal-block">
--- 729,734 ----
</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">
***************
*** 740,749 ****
</pre>
</div>
! <div class="section">
! <h2><a id="transformalarmc" name="transformalarmc">TransformAlarmC</a></h2>
<p>TransformAlarmC decreases precision and/or widens an Alarm. An
already widened Counter component is used to help.</p>
<pre class="literal-block">
! generic component TransformAlarmC(
typedef to_precision_tag,
typedef to_size_type @integer(),
--- 740,749 ----
</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(),
***************
*** 773,778 ****
passed to TransformAlarmC are inconsistent.</p>
</div>
! <div class="section">
! <h2><a id="transformcounterc" name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
--- 773,778 ----
passed to TransformAlarmC are inconsistent.</p>
</div>
! <div class="section" id="transformcounterc">
! <h2><a name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
***************
*** 805,810 ****
</pre>
</div>
! <div class="section">
! <h2><a id="virtualizetimerc" name="virtualizetimerc">VirtualizeTimerC</a></h2>
<p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
timers.</p>
--- 805,810 ----
</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>
***************
*** 819,824 ****
</div>
</div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
<p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
<blockquote>
--- 819,824 ----
</div>
</div>
! <div class="section" id="implementation">
! <h1><a name="implementation">6. Implementation</a></h1>
<p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
<blockquote>
***************
*** 890,895 ****
</blockquote>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Cory Sharp</div>
--- 890,895 ----
</blockquote>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Cory Sharp</div>
***************
*** 919,924 ****
</div>
</div>
! <div class="section">
! <h1><a id="appendix-a-timer-hardware-on-various-microcontrollers" name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
--- 919,924 ----
</div>
</div>
! <div class="section" id="appendix-a-timer-hardware-on-various-microcontrollers">
! <h1><a name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
***************
*** 996,1001 ****
</blockquote>
</div>
! <div class="section">
! <h1><a id="appendix-b-a-microcontroller-atmega-128-timer-subsystem" name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
--- 996,1001 ----
</blockquote>
</div>
! <div class="section" id="appendix-b-a-microcontroller-atmega-128-timer-subsystem">
! <h1><a name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
***************
*** 1027,1031 ****
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
--- 1027,1031 ----
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
***************
*** 1058,1062 ****
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
--- 1058,1062 ----
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
***************
*** 1096,1101 ****
</pre>
</div>
! <div class="section">
! <h1><a id="appendix-c-a-mote-mica-family-timer-subsystem" name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
<p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
--- 1096,1101 ----
</pre>
</div>
! <div class="section" id="appendix-c-a-mote-mica-family-timer-subsystem">
! <h1><a name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
<p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
***************
*** 1119,1123 ****
However, the set of dividers for timer 1 is limited to 1, 8,
64, 256 and 1024. So, when clocked at 2 or 4MHz, a divider of 1 is
! selected and timer 1 runs at 2 or 4MHz. To reflect this fact, the
HAL components exposing timer 1 are named <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> (rather than the <tt class="docutils literal"><span class="pre">CounterMicro16C</span></tt> <tt class="docutils literal"><span class="pre">AlarmMicro16C</span></tt>
--- 1119,1123 ----
However, the set of dividers for timer 1 is limited to 1, 8,
64, 256 and 1024. So, when clocked at 2 or 4MHz, a divider of 1 is
! selected and timer 1 runs at 2 or 4MHz. To reflect this fact, the
HAL components exposing timer 1 are named <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
<tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> (rather than the <tt class="docutils literal"><span class="pre">CounterMicro16C</span></tt> <tt class="docutils literal"><span class="pre">AlarmMicro16C</span></tt>
***************
*** 1140,1144 ****
32768Hz, if possible. As with timer 1, the limited set of dividers makes
this impossible at some clock frequencies, so the 16-bit timer 3 HAL
! components are named <tt class="docutils literal"><span class="pre">CounterThree16C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt>. As
with timer 1, the rate of timer 3 is adjusted in software when
building the 32-bit counter and 32-bit alarms, giving components
--- 1140,1144 ----
32768Hz, if possible. As with timer 1, the limited set of dividers makes
this impossible at some clock frequencies, so the 16-bit timer 3 HAL
! components are named <tt class="docutils literal"><span class="pre">CounterThree16C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt>. As
with timer 1, the rate of timer 3 is adjusted in software when
building the 32-bit counter and 32-bit alarms, giving components
Index: tep103.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep103.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep103.html 12 Dec 2006 18:22:53 -0000 1.6
--- tep103.html 21 Apr 2007 07:04:39 -0000 1.7
***************
*** 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" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>Permanent Data Storage (Flash)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
***************
*** 284,288 ****
</head>
<body>
- <div class="document" id="permanent-data-storage-flash">
<h1 class="title">Permanent Data Storage (Flash)</h1>
<table class="docinfo" frame="void" rules="none">
--- 284,287 ----
***************
*** 304,307 ****
--- 303,307 ----
</tbody>
</table>
+ <div class="document" id="permanent-data-storage-flash">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 311,322 ****
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 interfaces to non-volatile
storage for TinyOS 2.x. It describes some design principles for the HPL and
HAL layers of various flash chips.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Flash chips are a form of EEPROM (electrically-erasable, programmable
read-only memory), distinguished by a fast erase capability. However,
--- 311,322 ----
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 interfaces to non-volatile
storage for TinyOS 2.x. It describes some design principles for the HPL and
HAL layers of various flash chips.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Flash chips are a form of EEPROM (electrically-erasable, programmable
read-only memory), distinguished by a fast erase capability. However,
***************
*** 339,348 ****
</colgroup>
<thead valign="bottom">
! <tr><th class="head">X</th>
! <th class="head">NOR
(ex: ST M25P40,
Intel PXA27x)</th>
! <th class="head">AT45DB</th>
! <th class="head"><dl class="first last docutils">
<dt>NAND</dt>
<dd>(ex: Samsung
--- 339,348 ----
</colgroup>
<thead valign="bottom">
! <tr><th>X</th>
! <th>NOR
(ex: ST M25P40,
Intel PXA27x)</th>
! <th>AT45DB</th>
! <th><dl class="first last docutils">
<dt>NAND</dt>
<dd>(ex: Samsung
***************
*** 445,450 ****
</ul>
</div>
! <div class="section">
! <h1><a id="storage-in-tinyos-2-x" name="storage-in-tinyos-2-x">2. Storage in TinyOS 2.x</a>