[Tinyos-2-commits] CVS: tinyos-2.x/doc/html overview.html, 1.1.2.8,
1.1.2.9 tep1.html, 1.1.2.5, 1.1.2.6 tep101.html, 1.1.2.9,
1.1.2.10 tep102.html, 1.1.2.8, 1.1.2.9 tep103.html, 1.1.2.5,
1.1.2.6 tep106.html, 1.1.2.8, 1.1.2.9 tep107.html, 1.1.2.9,
1.1.2.10 tep108.html, 1.1.2.9, 1.1.2.10 tep109.html, 1.1.2.5,
1.1.2.6 tep110.html, 1.1.2.5, 1.1.2.6 tep111.html, 1.1.2.9,
1.1.2.10 tep112.html, 1.1.2.5, 1.1.2.6 tep113.html, 1.1.2.7,
1.1.2.8 tep114.html, 1.1.2.4, 1.1.2.5 tep115.html, 1.1.2.6,
1.1.2.7 tep116.html, 1.1.2.8, 1.1.2.9 tep117.html, 1.1.2.2,
1.1.2.3 tep118.html, 1.1.2.2, 1.1.2.3 tep119.html, 1.1.2.2,
1.1.2.3 tep120.html, 1.1.2.2, 1.1.2.3 tep121.html, 1.1.2.3,
1.1.2.4 tep2.html, 1.1.2.5, 1.1.2.6 tep3.html, 1.1.2.6, 1.1.2.7
Phil Levis
scipio at users.sourceforge.net
Tue Jun 27 13:23:08 PDT 2006
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv2128/html
Modified Files:
Tag: tinyos-2_0_devel-BRANCH
overview.html tep1.html tep101.html tep102.html tep103.html
tep106.html tep107.html tep108.html tep109.html tep110.html
tep111.html tep112.html tep113.html tep114.html tep115.html
tep116.html tep117.html tep118.html tep119.html tep120.html
tep121.html tep2.html tep3.html
Log Message:
Rebuilt the TEPs.
Index: tep1.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep1.html,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -C2 -d -r1.1.2.5 -r1.1.2.6
*** tep1.html 9 Jun 2006 21:12:17 -0000 1.1.2.5
--- tep1.html 27 Jun 2006 20:23:04 -0000 1.1.2.6
***************
*** 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.2</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-03-29</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">18-Oct-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 396,400 ****
content of the proposal.</p>
<p>All TEPs MUST follow the TEP docutils template, and conform to
! reStructuredText standards <a class="citation-reference" href="#rst" id="id1" name="id1">[rst]</a>, to enable translation from
reStructuredText to HTML and Latex.</p>
<div class="section">
--- 396,400 ----
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">
***************
*** 404,408 ****
included in all TEPs, in the order stated here.</p>
<p>The first field is "TEP," and specifies the TEP number of the
! document. This document is TEP 1.</p>
<p>The second field states the name of the working group that produced
the document. This document was produced by the Core Working Group.</p>
--- 404,413 ----
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
! is ready to be a TEP, it is assigned the smallest available number.
! BCP TEPs start at 1 and all other TEPs (Documentary, Experimental,
! and Informational) start at 101.</p>
<p>The second field states the name of the working group that produced
the document. This document was produced by the Core Working Group.</p>
***************
*** 417,433 ****
<p>Documentary TEPs describe a system or protocol that exists; a
documentary TEP MUST reference an implementation that a reader can
! easily obtain. Compliance with Documentary TEPs is entirely OPTIONAL;
! they exist to simplify interoperability when it is needed, and to
! document TinyOS service implementations.</p>
<p>Informational TEPs provide information that is of interest to the
community. Informational TEPs include data gathered on radio behavior,
hardware characteristics, other aspects of TinyOS software/hardware,
! or experiences which would help the community it its goals. It is
! RECOMMENDED that TEPs be aware of and consider Informational TEPs of
! relevance to its particular topic.</p>
<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. Experimental TEPs may describe systems that do not
! have a reference implementation (as Documentary ones do).</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
--- 422,436 ----
<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
community. Informational TEPs include data gathered on radio behavior,
hardware characteristics, other aspects of TinyOS software/hardware,
! organizational and logistic information,
! or experiences which could help the community achieve its goals.</p>
<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
***************
*** 496,503 ****
<div class="section">
<h1><a id="citations" name="citations">7. Citations</a></h1>
! <table class="docutils citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id1" name="rst">[rst]</a></td><td>reStructuredText Markup Specification. <<a class="reference" href="http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html">http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html</a>></td></tr>
</tbody>
</table>
--- 499,506 ----
<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>
<tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id1" name="id2">[1]</a></td><td>reStructuredText Markup Specification. <<a class="reference" href="http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html">http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html</a>></td></tr>
</tbody>
</table>
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep101.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep101.html 14 Jun 2006 17:56:36 -0000 1.1.2.9
--- tep101.html 27 Jun 2006 20:23:04 -0000 1.1.2.10
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.7: http://docutils.sourceforge.net/" />
<title>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay" />
***************
*** 319,324 ****
<a class="citation-reference" href="#tep1" id="id1" name="id1">[TEP1]</a>.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This TEP proposes a hardware abstraction for TinyOS 2.x analog-to-digital
converters (ADCs). It focuses on aligning the ADC abstraction with the
--- 319,324 ----
<a class="citation-reference" href="#tep1" id="id1" name="id1">[TEP1]</a>.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This TEP proposes a hardware abstraction for TinyOS 2.x analog-to-digital
converters (ADCs). It focuses on aligning the ADC abstraction with the
***************
*** 327,332 ****
ADC is platform-dependent.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Analog-to-digital converters (ADCs) are devices that convert analog input
signals to discrete digital output signals, typically voltage to a digital
--- 327,332 ----
ADC is platform-dependent.</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Analog-to-digital converters (ADCs) are devices that convert analog input
signals to discrete digital output signals, typically voltage to a digital
***************
*** 387,392 ****
implementation for the TI MSP430 MCU.</p>
</div>
! <div class="section" id="interfaces">
! <h1><a name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes to adopt the following three generic, source-independent
data collection interfaces from <a class="citation-reference" href="#tep114" id="id6" name="id6">[TEP114]</a> for the collection of ADC conversion
--- 387,392 ----
implementation for the TI MSP430 MCU.</p>
</div>
! <div class="section">
! <h1><a id="interfaces" name="interfaces">2. Interfaces</a></h1>
<p>This TEP proposes to adopt the following three generic, source-independent
data collection interfaces from <a class="citation-reference" href="#tep114" id="id6" name="id6">[TEP114]</a> for the collection of ADC conversion
***************
*** 406,417 ****
are specified in <a class="citation-reference" href="#tep114" id="id7" name="id7">[TEP114]</a>, in the following their usage is explained with
respect to ADCs.</p>
! <div class="section" id="read">
! <h2><a name="read">Read</a></h2>
<p>The Read interface can be used to sample an ADC channel and return a single
conversion result. It provides no guarantees about when exactly the sampling
occurs (the request may be buffered).</p>
</div>
! <div class="section" id="readnow">
! <h2><a name="readnow">ReadNow</a></h2>
<p>The ReadNow interface provides more precise control over the time of the
sampling: If a call to ReadNow.read() succeeds, the ADC starts to sample the
--- 406,417 ----
are specified in <a class="citation-reference" href="#tep114" id="id7" name="id7">[TEP114]</a>, in the following their usage is explained with
respect to ADCs.</p>
! <div class="section">
! <h2><a id="read" name="read">Read</a></h2>
<p>The Read interface can be used to sample an ADC channel and return a single
conversion result. It provides no guarantees about when exactly the sampling
occurs (the request may be buffered).</p>
</div>
! <div class="section">
! <h2><a id="readnow" name="readnow">ReadNow</a></h2>
<p>The ReadNow interface provides more precise control over the time of the
sampling: If a call to ReadNow.read() succeeds, the ADC starts to sample the
***************
*** 422,427 ****
release access via the Resource interface when it is finished (see <a class="citation-reference" href="#tep108" id="id8" name="id8">[TEP108]</a>).</p>
</div>
! <div class="section" id="readstream">
! <h2><a name="readstream">ReadStream</a></h2>
<p>The ReadStream interface can be used to sample an ADC channel multiple times
with a specified sampling period. It provides no guarantees about when exactly
--- 422,427 ----
release access via the Resource interface when it is finished (see <a class="citation-reference" href="#tep108" id="id8" name="id8">[TEP108]</a>).</p>
</div>
! <div class="section">
! <h2><a id="readstream" name="readstream">ReadStream</a></h2>
<p>The ReadStream interface can be used to sample an ADC channel multiple times
with a specified sampling period. It provides no guarantees about when exactly
***************
*** 430,435 ****
</div>
</div>
! <div class="section" id="hal1-guidelines">
! <h1><a name="hal1-guidelines">3. HAL1 guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL of an ADC abstraction consists of
two sublayers, HAL1 and HAL2. In the ADC component stack the HAL1 resides
--- 430,435 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal1-guidelines" name="hal1-guidelines">3. HAL1 guidelines</a></h1>
<p>As explained in <a class="reference" href="#introduction">1. Introduction</a> the HAL of an ADC abstraction consists of
two sublayers, HAL1 and HAL2. In the ADC component stack the HAL1 resides
***************
*** 441,446 ****
facilitate the mapping to platform-independent interfaces on the level of
HAL2. Appendix B shows the HAL1 specification for the TI MSP430 MCU.</p>
! <div class="section" id="resource-reservation">
! <h2><a name="resource-reservation">Resource reservation</a></h2>
<p>As the ADC hardware is a shared resource that is multiplexed between several
clients, it requires access arbitration. Therefore the HAL1 configuration
--- 441,446 ----
facilitate the mapping to platform-independent interfaces on the level of
HAL2. Appendix B shows the HAL1 specification for the TI MSP430 MCU.</p>
! <div class="section">
! <h2><a id="resource-reservation" name="resource-reservation">Resource reservation</a></h2>
<p>As the ADC hardware is a shared resource that is multiplexed between several
clients, it requires access arbitration. Therefore the HAL1 configuration
***************
*** 455,460 ****
'Resource' interface (see <a class="citation-reference" href="#tep108" id="id11" name="id11">[TEP108]</a>).</p>
</div>
! <div class="section" id="configuration-and-sampling">
! <h2><a name="configuration-and-sampling">Configuration and sampling</a></h2>
<p>As the ADC hardware is a shared resource the HAL1 SHOULD support hardware
configuration and sampling on a per-client basis (although per-port
--- 455,460 ----
'Resource' interface (see <a class="citation-reference" href="#tep108" id="id11" name="id11">[TEP108]</a>).</p>
</div>
! <div class="section">
! <h2><a id="configuration-and-sampling" name="configuration-and-sampling">Configuration and sampling</a></h2>
<p>As the ADC hardware is a shared resource the HAL1 SHOULD support hardware
configuration and sampling on a per-client basis (although per-port
***************
*** 477,482 ****
HAL1 interfaces for the TI MSP430 MCU.</p>
</div>
! <div class="section" id="hal1-virtualization">
! <h2><a name="hal1-virtualization">HAL1 virtualization</a></h2>
<p>In order to hide wiring complexities and/or export only a subset of all ADC
functions generic ADC wrapper components MAY be provided on the level of HAL1
--- 477,482 ----
HAL1 interfaces for the TI MSP430 MCU.</p>
</div>
! <div class="section">
! <h2><a id="hal1-virtualization" name="hal1-virtualization">HAL1 virtualization</a></h2>
<p>In order to hide wiring complexities and/or export only a subset of all ADC
functions generic ADC wrapper components MAY be provided on the level of HAL1
***************
*** 484,494 ****
</div>
</div>
! <div class="section" id="hal2-requirements">
! <h1><a name="hal2-requirements">4. HAL2 requirements</a></h1>
<p>The following components MUST be provided on all platforms that have an ADC:</p>
<pre class="literal-block">
! AdcReadClient
! AdcReadNowClient
! AdcReadStreamClient
</pre>
<p>These generic components are instantiated and provide access to the ADC on a
--- 484,494 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal2-requirements" name="hal2-requirements">4. HAL2 requirements</a></h1>
<p>The following components MUST be provided on all platforms that have an ADC:</p>
<pre class="literal-block">
! AdcReadClient
! AdcReadNowClient
! AdcReadStreamClient
</pre>
<p>These generic components are instantiated and provide access to the ADC on a
***************
*** 503,508 ****
reference voltage - makes the HAL2 representation chip dependent. Therefore
the ADC abstraction does not include an HIL.</p>
! <div class="section" id="adcreadclient">
! <h2><a name="adcreadclient">AdcReadClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadClient() {
--- 503,508 ----
reference voltage - makes the HAL2 representation chip dependent. Therefore
the ADC abstraction does not include an HIL.</p>
! <div class="section">
! <h2><a id="adcreadclient" name="adcreadclient">AdcReadClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadClient() {
***************
*** 525,530 ****
resolution of the conversion results.</p>
</div>
! <div class="section" id="adcreadnowclient">
! <h2><a name="adcreadnowclient">AdcReadNowClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClient() {
--- 525,530 ----
resolution of the conversion results.</p>
</div>
! <div class="section">
! <h2><a id="adcreadnowclient" name="adcreadnowclient">AdcReadNowClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadNowClient() {
***************
*** 551,556 ****
resolution of the conversion result.</p>
</div>
! <div class="section" id="adcreadstreamclient">
! <h2><a name="adcreadstreamclient">AdcReadStreamClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClient() {
--- 551,556 ----
resolution of the conversion result.</p>
</div>
! <div class="section">
! <h2><a id="adcreadstreamclient" name="adcreadstreamclient">AdcReadStreamClient</a></h2>
<pre class="literal-block">
generic configuration AdcReadStreamClient() {
***************
*** 575,580 ****
</div>
</div>
! <div class="section" id="hal2-implementation-guidelines">
! <h1><a name="hal2-implementation-guidelines">5. HAL2 implementation guidelines</a></h1>
<p>The HAL2 implementation of an ADC stack has two main tasks: It translates a
platform-independent HAL2 request (from the 'Read', 'ReadNow' or 'ReadStream'
--- 575,580 ----
</div>
</div>
! <div class="section">
! <h1><a id="hal2-implementation-guidelines" name="hal2-implementation-guidelines">5. HAL2 implementation guidelines</a></h1>
<p>The HAL2 implementation of an ADC stack has two main tasks: It translates a
platform-independent HAL2 request (from the 'Read', 'ReadNow' or 'ReadStream'
***************
*** 614,619 ****
ADC12 implementation in Appendix C).</p>
</div>
! <div class="section" id="implementation">
! <h1><a name="implementation">6. Implementation</a></h1>
<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>
--- 614,619 ----
ADC12 implementation in Appendix C).</p>
</div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
<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>
***************
*** 625,630 ****
<li><tt class="docutils literal"><span class="pre">AdcReadClientC.nc</span></tt>, <tt class="docutils literal"><span class="pre">AdcReadNowClientC.nc</span></tt> and
<tt class="docutils literal"><span class="pre">AdcReadStreamClientC.nc</span></tt> provide access to the ADC on a per-client
! basis via the interfaces 'Read', 'ReadNow' and 'ReadStream',
! respectively, and the msp430-specific ADC configuration
interface <tt class="docutils literal"><span class="pre">Msp430Adc12Config.nc</span></tt></li>
</ul>
--- 625,630 ----
<li><tt class="docutils literal"><span class="pre">AdcReadClientC.nc</span></tt>, <tt class="docutils literal"><span class="pre">AdcReadNowClientC.nc</span></tt> and
<tt class="docutils literal"><span class="pre">AdcReadStreamClientC.nc</span></tt> provide access to the ADC on a per-client
! basis via the interfaces 'Read', 'ReadNow' and 'ReadStream',
! respectively, and the msp430-specific ADC configuration
interface <tt class="docutils literal"><span class="pre">Msp430Adc12Config.nc</span></tt></li>
</ul>
***************
*** 636,640 ****
<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 HAL1 implementation</li>
! <li><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
--- 636,640 ----
<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 HAL1 implementation</li>
! <li><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
***************
*** 643,653 ****
<tt class="docutils literal"><span class="pre">AdcReadStreamClientC.nc</span></tt> provide access to the ADC on a per-client
basis via the platform-independent interfaces 'Read', 'ReadNow' and
! 'ReadStream', respectively, and the atmega-specific ADC configuration
interface <tt class="docutils literal"><span class="pre">Atm128AdcConfig.nc</span></tt></li>
</ul>
</blockquote>
</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>
--- 643,653 ----
<tt class="docutils literal"><span class="pre">AdcReadStreamClientC.nc</span></tt> provide access to the ADC on a per-client
basis via the platform-independent interfaces 'Read', 'ReadNow' and
! 'ReadStream', respectively, and the atmega-specific ADC configuration
interface <tt class="docutils literal"><span class="pre">Atm128AdcConfig.nc</span></tt></li>
</ul>
</blockquote>
</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>
***************
*** 659,665 ****
</colgroup>
<thead valign="bottom">
! <tr><th> </th>
! <th>Atmel Atmega 128</th>
! <th>TI MSP430 ADC12</th>
</tr>
</thead>
--- 659,665 ----
</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>
***************
*** 778,783 ****
</table>
</div>
! <div class="section" id="appendix-b-an-hal1-representation-msp430-adc12">
! <h1><a name="appendix-b-an-hal1-representation-msp430-adc12">Appendix B: an HAL1 representation: MSP430 ADC12</a></h1>
<p>The following shows the HAL1 representation for the ADC12 of the TI MSP430
MCU. It reflects the four MSP430 ADC12 conversion modes as it lets a client
--- 778,783 ----
</table>
</div>
! <div class="section">
! <h1><a id="appendix-b-an-hal1-representation-msp430-adc12" name="appendix-b-an-hal1-representation-msp430-adc12">Appendix B: an HAL1 representation: MSP430 ADC12</a></h1>
<p>The following shows the HAL1 representation for the ADC12 of the TI MSP430
MCU. It reflects the four MSP430 ADC12 conversion modes as it lets a client
***************
*** 790,811 ****
implemented).:</p>
<pre class="literal-block">
! configuration Msp430Adc12C
! {
! provides interface Resource[uint8_t id];
! provides interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
! }
! interface Msp430Adc12SingleChannel
! {
async command error_t getSingleData(const msp430adc12_channel_config_t *config);
! async command error_t getSingleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t jiffies);
async command error_t getMultipleData( const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint16_t numSamples, uint16_t jiffies);
! async command error_t getMultipleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint8_t numSamples, uint16_t jiffies);
async event error_t singleDataReady(uint16_t data);
async event uint16_t* multipleDataReady(uint16_t *buffer, uint16_t
! numSamples);
}
</pre>
--- 790,811 ----
implemented).:</p>
<pre class="literal-block">
! configuration Msp430Adc12C
! {
! provides interface Resource[uint8_t id];
! provides interface Msp430Adc12SingleChannel as SingleChannel[uint8_t id];
! }
! interface Msp430Adc12SingleChannel
! {
async command error_t getSingleData(const msp430adc12_channel_config_t *config);
! async command error_t getSingleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t jiffies);
async command error_t getMultipleData( const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint16_t numSamples, uint16_t jiffies);
! async command error_t getMultipleDataRepeat(const msp430adc12_channel_config_t *config,
uint16_t *buffer, uint8_t numSamples, uint16_t jiffies);
async event error_t singleDataReady(uint16_t data);
async event uint16_t* multipleDataReady(uint16_t *buffer, uint16_t
! numSamples);
}
</pre>
***************
*** 814,819 ****
errors.</p>
</div>
! <div class="section" id="appendix-c-an-hal2-representation-msp430-adc12">
! <h1><a name="appendix-c-an-hal2-representation-msp430-adc12">Appendix C: an HAL2 representation: MSP430 ADC12</a></h1>
<p>The AdcReadClientC component for the MSP430 ADC12 is implemented as follows:</p>
<pre class="literal-block">
--- 814,819 ----
errors.</p>
</div>
! <div class="section">
! <h1><a id="appendix-c-an-hal2-representation-msp430-adc12" name="appendix-c-an-hal2-representation-msp430-adc12">Appendix C: an HAL2 representation: MSP430 ADC12</a></h1>
<p>The AdcReadClientC component for the MSP430 ADC12 is implemented as follows:</p>
<pre class="literal-block">
***************
*** 823,827 ****
} implementation {
components AdcC;
! #ifdef REF_VOLT_AUTO_CONFIGURE
components new Msp430Adc12RefVoltAutoClientC() as Msp430AdcClient;
#else
--- 823,827 ----
} implementation {
components AdcC;
! #ifdef REF_VOLT_AUTO_CONFIGURE
components new Msp430Adc12RefVoltAutoClientC() as Msp430AdcClient;
#else
***************
*** 839,843 ****
#ifdef REF_VOLT_AUTO_CONFIGURE
Msp430Adc12Config = Msp430AdcClient.Msp430Adc12Config;
! #endif
}
</pre>
--- 839,843 ----
#ifdef REF_VOLT_AUTO_CONFIGURE
Msp430Adc12Config = Msp430AdcClient.Msp430Adc12Config;
! #endif
}
</pre>
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep102.html,v
retrieving revision 1.1.2.8
retrieving revision 1.1.2.9
diff -C2 -d -r1.1.2.8 -r1.1.2.9
*** tep102.html 16 Jun 2006 00:26:36 -0000 1.1.2.8
--- tep102.html 27 Jun 2006 20:23:04 -0000 1.1.2.9
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
***************
*** 319,324 ****
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This TEP proposes a Timer design that supports common timing
requirements both in precision and width across common hardware
--- 319,324 ----
TEP 1.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This TEP proposes a Timer design that supports common timing
requirements both in precision and width across common hardware
***************
*** 326,331 ****
with the three-layer Hardware Abstraction Architecture (HAA).</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Most microcontrollers offer a rich timer system, with features like:</p>
<ul class="simple">
--- 326,331 ----
with the three-layer Hardware Abstraction Architecture (HAA).</p>
</div>
! <div class="section">
! <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Most microcontrollers offer a rich timer system, with features like:</p>
<ul class="simple">
***************
*** 341,345 ****
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
--- 341,345 ----
HAA[_tep2], each microcontroller should expose all this functionality
via components and interfaces at the HPL and, where appropriate, HAL levels.
! However, two aspects of timers are sufficiently common and important
that they should be made available in a well-defined way: measuring time,
and triggering (possibly repeating) events at specific times. The rest
***************
*** 350,354 ****
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
--- 350,354 ----
<li>guidelines on how each microcontroller's HAL SHOULD expose its timer hardware
in terms of the above interfaces (<a class="reference" href="#hal-guidelines">3. HAL guidelines</a>)</li>
! <li>what components a microcontroller's timer HIL MUST implement
(<a class="reference" href="#hil-requirements">4. HIL requirements</a>)</li>
<li>a set of utility components whose use simplifies building the components
***************
*** 358,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>
--- 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>
***************
*** 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">
--- 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">
***************
*** 420,426 ****
advanced user components.</p>
</div>
! <div class="section" id="counter">
! <h2><a name="counter">Counter</a></h2>
! <p>A Counter component will increase the width of a low-level hardware timer
by wrapping the overflow event and incrementing its higher order bits.
These higher order bits are considered extra state over the HPL register
--- 420,426 ----
advanced user components.</p>
</div>
! <div class="section">
! <h2><a id="counter" name="counter">Counter</a></h2>
! <p>A Counter component will increase the width of a low-level hardware timer
by wrapping the overflow event and incrementing its higher order bits.
These higher order bits are considered extra state over the HPL register
***************
*** 440,457 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending() </dt>
<dd>return TRUE if an overflow interrupt will occur after the outermost
atomic block is exits. FALSE otherwise.</dd>
! <dt>clearOverflow() </dt>
<dd>cancel the pending overflow interrupt.</dd>
! <dt>overflow() </dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section" id="alarm">
! <h2><a name="alarm">Alarm</a></h2>
<p>Alarm components are extensions of Counters that signal an event
when their Compare register detects the alarm time has been hit.
--- 440,457 ----
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
! <dt>isOverflowPending()</dt>
<dd>return TRUE if an overflow interrupt will occur after the outermost
atomic block is exits. FALSE otherwise.</dd>
! <dt>clearOverflow()</dt>
<dd>cancel the pending overflow interrupt.</dd>
! <dt>overflow()</dt>
<dd>signals that an overflow in the current time. That is, the current
time has wrapped around from its maximum value to zero.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="alarm" name="alarm">Alarm</a></h2>
<p>Alarm components are extensions of Counters that signal an event
when their Compare register detects the alarm time has been hit.
***************
*** 476,491 ****
</pre>
<dl class="docutils">
! <dt>start(dt) </dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop() </dt>
<dd>cancel any previously running alarm.</dd>
! <dt>fired() </dt>
<dd>signals that the alarm has occurred.</dd>
! <dt>isRunning() </dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
or has not yet fired. FALSE is returned otherwise.</dd>
! <dt>startAt(t0,dt) </dt>
<dd>cancel any previously running alarm and set to fire at time t1 =
t0+dt. This form allows a delay to be anchored to some time t0
--- 476,491 ----
</pre>
<dl class="docutils">
! <dt>start(dt)</dt>
<dd>cancel any previously running alarm and set to fire in dt time units
from the time of invocation. The alarm will only fire once then
stop.</dd>
! <dt>stop()</dt>
<dd>cancel any previously running alarm.</dd>
! <dt>fired()</dt>
<dd>signals that the alarm has occurred.</dd>
! <dt>isRunning()</dt>
<dd>return TRUE if the alarm has been started and has not been cancelled
or has not yet fired. FALSE is returned otherwise.</dd>
! <dt>startAt(t0,dt)</dt>
<dd>cancel any previously running alarm and set to fire at time t1 =
t0+dt. This form allows a delay to be anchored to some time t0
***************
*** 494,506 ****
of an alarm while being able to detect if the alarm time for a short
alarm prematurely elapsed.</dd>
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm() </dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire.</dd>
</dl>
</div>
! <div class="section" id="busywait">
! <h2><a name="busywait">BusyWait</a></h2>
<p>The BusyWait interface replaces the TOSH_uwait macro from TinyOS
1.x.</p>
--- 494,506 ----
of an alarm while being able to detect if the alarm time for a short
alarm prematurely elapsed.</dd>
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm()</dt>
<dd>return the time the currently running alarm will fire or the time
that the previously running alarm was set to fire.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="busywait" name="busywait">BusyWait</a></h2>
<p>The BusyWait interface replaces the TOSH_uwait macro from TinyOS
1.x.</p>
***************
*** 516,521 ****
</dl>
</div>
! <div class="section" id="localtime">
! <h2><a name="localtime">LocalTime</a></h2>
<p>The LocalTime interface exposes a 32-bit counter without overflow
utilities. This is primarily for application code that does not
--- 516,521 ----
</dl>
</div>
! <div class="section">
! <h2><a id="localtime" name="localtime">LocalTime</a></h2>
<p>The LocalTime interface exposes a 32-bit counter without overflow
utilities. This is primarily for application code that does not
***************
*** 528,537 ****
</pre>
<dl class="docutils">
! <dt>get() </dt>
<dd>return the current time.</dd>
</dl>
</div>
! <div class="section" id="timer">
! <h2><a name="timer">Timer</a></h2>
<p>All commands and events of the Timer interface are synchronous (or
in "task context"). The Timer interface provides a set of "basic"
--- 528,537 ----
</pre>
<dl class="docutils">
! <dt>get()</dt>
<dd>return the current time.</dd>
</dl>
</div>
! <div class="section">
! <h2><a id="timer" name="timer">Timer</a></h2>
<p>All commands and events of the Timer interface are synchronous (or
in "task context"). The Timer interface provides a set of "basic"
***************
*** 558,599 ****
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt) </dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop() </dt>
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
<dd>signals that the timer has occurred.</dd>
! <dt>isRunning() </dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot() </dt>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt) </dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt) </dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</dd>
! <dt>getNow() </dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0() </dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt() </dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section" id="hal-guidelines">
! <h1><a name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms typically select a clocking option for each of their
hardware counters, based on their hardware design (e.g., the mica
--- 558,599 ----
</pre>
<dl class="docutils">
! <dt>startPeriodic(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will fire periodically every
dt time units until stopped.</dd>
! <dt>startOneShot(dt)</dt>
<dd>cancel any previously running timer and set to fire in dt time units
from the time of invocation. The timer will only fire once then
stop.</dd>
! <dt>stop()</dt>
<dd>cancel any previously running timer.</dd>
<dt>fired()</dt>
<dd>signals that the timer has occurred.</dd>
! <dt>isRunning()</dt>
<dd>return TRUE if the timer has been started and has not been cancelled
and has not fired for the case of one-shot timers. One a periodic
timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot()</dt>
<dd>return TRUE if the timer is a one-shot timer. Return FALSE
otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt)</dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire periodically every dt time units until
stopped.</dd>
! <dt>startOneShotAt(t0,dt)</dt>
<dd>cancel any previously running timer and set to fire at time t1 =
t0+dt. The timer will fire once then stop.</dd>
! <dt>getNow()</dt>
<dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0()</dt>
<dd>return the time anchor for the previously started timer or the time
of the previous event for periodic timers.</dd>
! <dt>getdt()</dt>
<dd>return the delay or period for the previously started timer.</dd>
</dl>
</div>
</div>
! <div class="section">
! <h1><a id="hal-guidelines" name="hal-guidelines">3. HAL guidelines</a></h1>
<p>Platforms typically select a clocking option for each of their
hardware counters, based on their hardware design (e.g., the mica
***************
*** 610,614 ****
configuration CounterPWC {
provides interface Counter<TP, uintW_t>;
! } ...
generic configuration AlarmPWC {
provides interface Alarm<TP,uintW_t>;
--- 610,614 ----
configuration CounterPWC {
provides interface Counter<TP, uintW_t>;
! } ...
generic configuration AlarmPWC {
provides interface Alarm<TP,uintW_t>;
***************
*** 619,623 ****
configuration CounterP32C {
provides interface Counter<TP, uint32_t>;
! } ...
generic configuration AlarmP32C {
provides interface Alarm<TP,uint32_t>;
--- 619,623 ----
configuration CounterP32C {
provides interface Counter<TP, uint32_t>;
! } ...
generic configuration AlarmP32C {
provides interface Alarm<TP,uint32_t>;
***************
*** 635,640 ****
allowed).</p>
</div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
--- 635,640 ----
allowed).</p>
</div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
<dl class="docutils">
<dt>The following component MUST be provided on all platforms::</dt>
***************
*** 642,647 ****
BusyWaitMicroC</dd>
</dl>
! <div class="section" id="timermillic">
! <h2><a name="timermillic">TimerMilliC</a></h2>
<pre class="literal-block">
#define TIMERMILLIC_SERVICE ...
--- 642,647 ----
BusyWaitMicroC</dd>
</dl>
! <div class="section">
! <h2><a id="timermillic" name="timermillic">TimerMilliC</a></h2>
<pre class="literal-block">
#define TIMERMILLIC_SERVICE ...
***************
*** 657,662 ****
parameterised interface.</p>
</div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
--- 657,662 ----
parameterised interface.</p>
</div>
! <div class="section">
! <h2><a id="busywaitmicroc" name="busywaitmicroc">BusyWaitMicroC</a></h2>
<pre class="literal-block">
configuration BusyWaitMicroC
***************
*** 671,676 ****
</div>
</div>
! <div class="section" id="utility-components">
! <h1><a name="utility-components">5. Utility components</a></h1>
<p>A number of platform independent generic components are provided to
help implementers and advanced users of the TinyOS timer system:</p>
--- 671,676 ----
</div>
</div>
! <div class="section">
! <h1><a id="utility-components" name="utility-components">5. Utility components</a></h1>
<p>A number of platform independent generic components are provided to
help implementers and advanced users of the TinyOS timer system:</p>
***************
*** 685,690 ****
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section" id="alarmtotimerc">
! <h2><a name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
--- 685,690 ----
<p>Appendices B and C show how these can be used to help implement
the timer HAL and HIL.</p>
! <div class="section">
! <h2><a id="alarmtotimerc" name="alarmtotimerc">AlarmToTimerC</a></h2>
<p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
<pre class="literal-block">
***************
*** 696,701 ****
</pre>
</div>
! <div class="section" id="busywaitcounterc">
! <h2><a name="busywaitcounterc">BusyWaitCounterC</a></h2>
<p>BusyWaitCounterC uses a Counter to block until a specified amount of
time elapses.</p>
--- 696,701 ----
</pre>
</div>
! <div class="section">
! <h2><a id="busywaitcounterc" name="busywaitcounterc">BusyWaitCounterC</a></h2>
<p>BusyWaitCounterC uses a Counter to block until a specified amount of
time elapses.</p>
***************
*** 709,714 ****
</pre>
</div>
! <div class="section" id="countertolocaltimec">
! <h2><a name="countertolocaltimec">CounterToLocalTimeC</a></h2>
<p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
<pre class="literal-block">
--- 709,714 ----
</pre>
</div>
! <div class="section">
! <h2><a id="countertolocaltimec" name="countertolocaltimec">CounterToLocalTimeC</a></h2>
<p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
<pre class="literal-block">
***************
*** 720,729 ****
</pre>
</div>
! <div class="section" id="transformalarmc">
! <h2><a name="transformalarmc">TransformAlarmC</a></h2>
<p>TransformAlarmC decreases precision and/or widens an Alarm. An
already widened Counter component is used to help.</p>
<pre class="literal-block">
! generic component TransformAlarmC(
typedef to_precision_tag,
typedef to_size_type @integer(),
--- 720,729 ----
</pre>
</div>
! <div class="section">
! <h2><a id="transformalarmc" name="transformalarmc">TransformAlarmC</a></h2>
<p>TransformAlarmC decreases precision and/or widens an Alarm. An
already widened Counter component is used to help.</p>
<pre class="literal-block">
! generic component TransformAlarmC(
typedef to_precision_tag,
typedef to_size_type @integer(),
***************
*** 749,754 ****
</pre>
</div>
! <div class="section" id="transformcounterc">
! <h2><a name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
--- 749,754 ----
</pre>
</div>
! <div class="section">
! <h2><a id="transformcounterc" name="transformcounterc">TransformCounterC</a></h2>
<p>TransformCounterC decreases precision and/or widens a Counter.</p>
<pre class="literal-block">
***************
*** 781,786 ****
</pre>
</div>
! <div class="section" id="virtualizetimerc">
! <h2><a name="virtualizetimerc">VirtualizeTimerC</a></h2>
<p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
timers.</p>
--- 781,786 ----
</pre>
</div>
! <div class="section">
! <h2><a id="virtualizetimerc" name="virtualizetimerc">VirtualizeTimerC</a></h2>
<p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
timers.</p>
***************
*** 795,800 ****
</div>
</div>
! <div class="section" id="appendix-a-timer-hardware-on-various-microcontrollers">
! <h1><a name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
--- 795,800 ----
</div>
</div>
! <div class="section">
! <h1><a id="appendix-a-timer-hardware-on-various-microcontrollers" name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
<blockquote>
<ol class="loweralpha simple">
***************
*** 872,877 ****
</blockquote>
</div>
! <div class="section" id="appendix-b-a-microcontroller-atmega-128-timer-subsystem">
! <h1><a name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
--- 872,877 ----
</blockquote>
</div>
! <div class="section">
! <h1><a id="appendix-b-a-microcontroller-atmega-128-timer-subsystem" name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
<p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
<blockquote>
***************
*** 903,907 ****
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
--- 903,907 ----
/// Clock initialization interface
! async command void off(); //<! Turn off the clock
async command void setScale( uint8_t scale); //<! Turn on the clock
async command uint8_t getScale(); //<! Get prescaler setting
***************
*** 934,938 ****
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
--- 934,938 ----
async event void captured(size_type t); //<! Signalled on capture int
! /// Interrupt flag utilites: Bit level set/clr
async command void reset(); //<! Clear the capture interrupt flag
async command void start(); //<! Enable the capture interrupt
***************
*** 972,977 ****
</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,
--- 972,977 ----
</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,
***************
*** 995,999 ****
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>
--- 995,999 ----
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>
***************
*** 1016,1020 ****
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
--- 1016,1020 ----
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/Attic/tep103.html,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -C2 -d -r1.1.2.5 -r1.1.2.6
*** tep103.html 14 Jun 2006 21:32:42 -0000 1.1.2.5
--- tep103.html 27 Jun 2006 20:23:04 -0000 1.1.2.6
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title>Permanent Data Storage (Flash)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Permanent Data Storage (Flash)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">27-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-14</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">27-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.12</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-21</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 319,337 ****
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
! <p>This memo documents a set of hardware-independent, non-volatile storage
! interfaces for TinyOS 2.x, and some principles for the HPL and HAL layers
! for various flash chips.</p>
</div>
! <div class="section" id="introduction">
! <h1><a name="introduction">1. Introduction</a></h1>
<p>Flash chips are a form of EEPROM (electrically-eraseable, programmable
read-only memory), distinguished by a fast erase capability. However,
erases can only be done in large units (from 256B to 128kB depending on the
! flash chip). Erases are the only way to switch bits from 0 to 1, the
! programming operation can only switch 1's to 0's. Additionally, some
! chips requires that programming only happen once between each erase,
! or that it be performed in relatively large units (e.g., 256B).</p>
<p>In the table below, we summarise these differences by categorising
flash chips by their underlying technology (NOR vs NAND). We also
--- 319,337 ----
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-eraseable, programmable
read-only memory), distinguished by a fast erase capability. However,
erases can only be done in large units (from 256B to 128kB depending on the
! flash chip). Erases are the only way to switch bits from 0 to 1, and
! programming operations can only switch 1's to 0's. Additionally, some
! chips require that programming only happen once between each erase,
! or that it be in relatively large units (e.g., 256B).</p>
<p>In the table below, we summarise these differences by categorising
flash chips by their underlying technology (NOR vs NAND). We also
***************
*** 345,351 ****
Writes : Slow (100s kB/s) Slow (60kB/s) Fast (MBs/s)
Write unit : 1 bit 256B 100's of bytes
! Bit-errors : Low Low High (requires ECC,
bad-block mapping)
! Read : Fast* Slow+I/O bus Fast (but limited by
I/O bus)
Erase cycles : 10^4 - 10^5 10^4 ** 10^5 - 10^7
--- 345,351 ----
Writes : Slow (100s kB/s) Slow (60kB/s) Fast (MBs/s)
Write unit : 1 bit 256B 100's of bytes
! Bit-errors : Low Low High (requires ECC,
bad-block mapping)
! Read : Fast* Slow+I/O bus Fast (but limited by
I/O bus)
Erase cycles : 10^4 - 10^5 10^4 ** 10^5 - 10^7
***************
*** 364,368 ****
to depend mostly on how long the read takes (the power consumptions are
comparable), i.e., on the efficiency of the bus + processor.</p>
! <p>Early motes used with TinyOS all used a flash chip from the AT45DB
family. In TinyOS 1.x, this chip could be accessed through three
different components:</p>
--- 364,368 ----
to depend mostly on how long the read takes (the power consumptions are
comparable), i.e., on the efficiency of the bus + processor.</p>
! <p>Early TinyOS platforms all used a flash chip from the AT45DB
family. In TinyOS 1.x, this chip could be accessed through three
different components:</p>
***************
*** 373,379 ****
read, write and logging operations.</li>
<li>Using a simple file system (<tt class="docutils literal"><span class="pre">Matchbox</span></tt>) with sequential-only
! files.</li>
</ul>
! <p>Some more recent motes use different flash chips: the ST M25P family (Telos
rev. B, eyes) and the Intel Strataflash (Intel Mote2). None of the
three components listed above are supported on these chips:</p>
--- 373,379 ----
read, write and logging operations.</li>
<li>Using a simple file system (<tt class="docutils literal"><span class="pre">Matchbox</span></tt>) with sequential-only
! files [<a class="reference" href="#id1">1</a>].</li>
</ul>
! <p>Some more recent platforms use different flash chips: the ST M25P family (Telos
rev. B, eyes) and the Intel Strataflash (Intel Mote2). None of the
three components listed above are supported on these chips:</p>
***************
*** 383,387 ****
This is not readily implementable on a flash chip with large erase units.</li>
<li>The <tt class="docutils literal"><span class="pre">Matchbox</span></tt> implementation was AT45DB-specific. It was not
! reimplemented for these other chips, in part because it does not
support some applications (e.g., network reprogramming) very well.</li>
</ul>
--- 383,387 ----
This is not readily implementable on a flash chip with large erase units.</li>
<li>The <tt class="docutils literal"><span class="pre">Matchbox</span></tt> implementation was AT45DB-specific. It was not
! reimplemented for these other chips, in part because it does not
support some applications (e.g., network reprogramming) very well.</li>
</ul>
***************
*** 395,404 ****
<li>To support arbitrary block writes where blocks are smaller than the
erase unit, and to deal with the limited number of erase cycles/block
! requires remapping blocks. We believe that maintaining this remapping
table is too expensive on many mote-class devices.</li>
</ul>
<p>Another approach to supporting multiple flash chips is to build a
file system (like Matchbox) which can be implemented for multiple
! flash chips. However, TinyOS is currently targeted at running a
single application, and many applications know their storage needs
in advance: for instance, a little space for configuration data, and
--- 395,404 ----
<li>To support arbitrary block writes where blocks are smaller than the
erase unit, and to deal with the limited number of erase cycles/block
! requires remapping blocks. We believe that maintaining this remapping
table is too expensive on many mote-class devices.</li>
</ul>
<p>Another approach to supporting multiple flash chips is to build a
file system (like Matchbox) which can be implemented for multiple
! flash chips. However, TinyOS is currently targeted at running a
single application, and many applications know their storage needs
in advance: for instance, a little space for configuration data, and
***************
*** 407,439 ****
files) is overkill, and may come at the expense of implementation
and runtime complexity.</p>
! <p>Instead, in TinyOS 2.x, we divide flash chips into separate volumes (with
! sizes fixed at compile-time). Each volume is dedicated to a high-level
! storage services useful for sensor network applications. We have so far
! identified three such services: large objects written in a single session,
small objects with arbitrary reads and writes, and logs. This approach
has two advantages:</p>
<ul class="simple">
! <li>Each service is relatively easy to implement on a new flash chip, and
has relatively little overhead.</li>
<li>The problem of dealing with the limited number of erase cycles/block
is simplified: it is unlikely that user applications will need to
rewrite the same small object 100'000 times, or cycle 100'000 times
! through their log. Thus the services can mostly ignore the need for
"wear levelling" (ensuring that each block of the flash is erased
the same number of time, to maximise flash chip lifetime).</li>
</ul>
! <p>New services (including a filing system...) can easily be added to this
! framework.</p>
<p>The rest of this TEP covers some principles for the organisation of
flash chips (Section 2), then describes the flash volumes and
! storage services in detail (Section 3).</p>
</div>
! <div class="section" id="hpl-hal-hil-architecture">
! <h1><a name="hpl-hal-hil-architecture">2. HPL/HAL/HIL Architecture</a></h1>
! <p>The flash chip architecture aligns with the three-layer Hardware
Abstraction Architecture (HAA), with each chip providing a presentation
layer (HPL, Section 2.1), adaptation layer (HAL, Section 2.2) and
! platform-independent interface layer (the storage services described in
! Section 3). The implementation of these layers SHOULD be found in the
<tt class="docutils literal"><span class="pre">tos/chips/CHIPNAME</span></tt> directory. If a flash chip is part of a larger
family with a similar interface, the HAA SHOULD support all family members
--- 407,439 ----
files) is overkill, and may come at the expense of implementation
and runtime complexity.</p>
! <p>Instead, TinyOS 2.x, divides flash chips into separate volumes (with
! sizes fixed at compile-time). Each volume provides a single storage
! abstraction (the abstraction defines the format). So far there are three
! such abstractions: large objects written in a single session,
small objects with arbitrary reads and writes, and logs. This approach
has two advantages:</p>
<ul class="simple">
! <li>Each abstraction is relatively easy to implement on a new flash chip, and
has relatively little overhead.</li>
<li>The problem of dealing with the limited number of erase cycles/block
is simplified: it is unlikely that user applications will need to
rewrite the same small object 100'000 times, or cycle 100'000 times
! through their log. Thus the abstractions can mostly ignore the need for
"wear levelling" (ensuring that each block of the flash is erased
the same number of time, to maximise flash chip lifetime).</li>
</ul>
! <p>New abstractions (including a filing system) can easily be added to this
! framework, or can be built on top of these abstractions.</p>
<p>The rest of this TEP covers some principles for the organisation of
flash chips (Section 2), then describes the flash volumes and
! storage abstractions in detail (Section 3).</p>
</div>
! <div class="section">
! <h1><a id="hpl-hal-hil-architecture" name="hpl-hal-hil-architecture">2. HPL/HAL/HIL Architecture</a></h1>
! <p>The flash chip architecture dollows the three-layer Hardware
Abstraction Architecture (HAA), with each chip providing a presentation
layer (HPL, Section 2.1), adaptation layer (HAL, Section 2.2) and
! platform-independent interface layer (the storage abstractions described in
! Section 3) [<a class="reference" href="#id2">2</a>]. The implementation of these layers SHOULD be found in the
<tt class="docutils literal"><span class="pre">tos/chips/CHIPNAME</span></tt> directory. If a flash chip is part of a larger
family with a similar interface, the HAA SHOULD support all family members
***************
*** 441,458 ****
<p>Appendix A shows example HPL and HAL specifications for the AT45DB
and ST M25P chip families.</p>
! <div class="section" id="hardware-presentation-layer-hpl">
! <h2><a name="hardware-presentation-layer-hpl">2.1 Hardware Presentation Layer (HPL)</a></h2>
<p>The flash HPL has a chip-dependent, system-independent interface. The
implementation of this HPL is system-dependent. The flash HPL SHOULD be
stateless.</p>
! <p>The flash chip's HPL SHOULD connect to platform-specific components
! providing access to the flash chip on a particular mote; these components
SHOULD be placed in the <tt class="docutils literal"><span class="pre">tos/platforms/PLATFORM/chips/CHIPNAME</span></tt>
! directory. If the flash chip implementation supports a family of
flash chips, this directory MAY also contain a file describing the
particular flash chip found on the platform.</p>
</div>
! <div class="section" id="hardware-adaptation-layer-hal">
! <h2><a name="hardware-adaptation-layer-hal">2.2 Hardware Adaptation Layer (HAL)</a></h2>
<p>The flash HAL has a chip-dependent, system-independent interface and
implementation. Flash families with a common HPL SHOULD have a common
--- 441,459 ----
<p>Appendix A shows example HPL and HAL specifications for the AT45DB
and ST M25P chip families.</p>
! <div class="section">
! <h2><a id="hardware-presentation-layer-hpl" name="hardware-presentation-layer-hpl">2.1 Hardware Presentation Layer (HPL)</a></h2>
<p>The flash HPL has a chip-dependent, system-independent interface. The
implementation of this HPL is system-dependent. The flash HPL SHOULD be
stateless.</p>
! <p>To remain platform independent, a flash chip's HPL SHOULD connect to
! platform-specific components
! providing access to the flash chip; these components
SHOULD be placed in the <tt class="docutils literal"><span class="pre">tos/platforms/PLATFORM/chips/CHIPNAME</span></tt>
! directory. If the flash chip implementation supports a family of
flash chips, this directory MAY also contain a file describing the
particular flash chip found on the platform.</p>
</div>
! <div class="section">
! <h2><a id="hardware-adaptation-layer-hal" name="hardware-adaptation-layer-hal">2.2 Hardware Adaptation Layer (HAL)</a></h2>
<p>The flash HAL has a chip-dependent, system-independent interface and
implementation. Flash families with a common HPL SHOULD have a common
***************
*** 461,474 ****
provide a way to access the volume information specified by the
programmer (see Section 3). This allows users to build new flash
! services that interact cleanly with the rest of the flash system.</p>
</div>
</div>
! <div class="section" id="non-volatile-storage-services-in-tinyos-2-x">
! <h1><a name="non-volatile-storage-services-in-tinyos-2-x">3. Non-Volatile Storage Services in TinyOS 2.x</a></h1>
<p>The HIL implementations are system-independent, but chip (family)
! dependent. They implement the three storage services and
volume structure discussed in the introduction.</p>
! <div class="section" id="volumes">
! <h2><a name="volumes">3.1. Volumes</a></h2>
<p>The division of the flash chip into fixed-size volumes is specified by
an XML file that is placed in the application's directory (where one
--- 462,475 ----
provide a way to access the volume information specified by the
programmer (see Section 3). This allows users to build new flash
! abstractions that interact cleanly with the rest of the flash system.</p>
</div>
</div>
! <div class="section">
! <h1><a id="non-volatile-storage-abstracitons-in-tinyos-2-x" name="non-volatile-storage-abstracitons-in-tinyos-2-x">3. Non-Volatile Storage Abstracitons in TinyOS 2.x</a></h1>
<p>The HIL implementations are system-independent, but chip (family)
! dependent. They implement the three storage abstractions and
volume structure discussed in the introduction.</p>
! <div class="section">
! <h2><a id="volumes" name="volumes">3.1. Volumes</a></h2>
<p>The division of the flash chip into fixed-size volumes is specified by
an XML file that is placed in the application's directory (where one
***************
*** 498,502 ****
the XML file and '#define' each resulting name to map to a unique
integer.</p>
! <p>The storage services are accessed by instantiating generic
components that take the volume macro as argument:</p>
<pre class="literal-block">
--- 499,503 ----
the XML file and '#define' each resulting name to map to a unique
integer.</p>
! <p>The storage abstractions are accessed by instantiating generic
components that take the volume macro as argument:</p>
<pre class="literal-block">
***************
*** 505,519 ****
<p>If the named volume is not in the specification, nesC will give a
compile-time error since the symbol will be undefined.</p>
! <p>A volume MUST NOT be used with more than one storage service instance.</p>
</div>
! <div class="section" id="large-objects">
! <h2><a name="large-objects">3.2 Large objects</a></h2>
<p>The motivating example for large objects is the transmission or long-term
! storage of large objects. For instance, programs in a network-reprogramming
system, or large data-packets in a reliable data-transmission system. Such
objects have two interesting characteristics: each byte in the object is
written at most once, and a full object is written in a single "session"
(i.e., without the mote rebooting).</p>
! <p>This leads to the definition of the <tt class="docutils literal"><span class="pre">BlockStorageC</span></tt> service for storing
large objects:</p>
<ul class="simple">
--- 506,520 ----
<p>If the named volume is not in the specification, nesC will give a
compile-time error since the symbol will be undefined.</p>
! <p>A volume MUST NOT be used with more than one storage abstraction instance.</p>
</div>
! <div class="section">
! <h2><a id="large-objects" name="large-objects">3.2 Large objects</a></h2>
<p>The motivating example for large objects is the transmission or long-term
! storage of large pieces of data. For instance, programs in a network-reprogramming
system, or large data-packets in a reliable data-transmission system. Such
objects have two interesting characteristics: each byte in the object is
written at most once, and a full object is written in a single "session"
(i.e., without the mote rebooting).</p>
! <p>This leads to the definition of the <tt class="docutils literal"><span class="pre">BlockStorageC</span></tt> abstraction for storing
large objects:</p>
<ul class="simple">
***************
*** 553,562 ****
volume.</li>
</ul>
! <p>For full details on arguments, etc, see the comments in the interface
! definitions.</p>
</div>
! <div class="section" id="logging">
! <h2><a name="logging">3.3 Logging</a></h2>
! <p>Logging of results, events, etc is a common requirement in sensor
networks. Such logging should be reliable (a mote crash should not
lose data). It should also be easy to extract data from the log,
--- 554,563 ----
volume.</li>
</ul>
! <p>For full details on arguments and other considerations, see the comments in
! the interface definitions.</p>
</div>
! <div class="section">
! <h2><a id="logging" name="logging">3.3 Logging</a></h2>
! <p>Event and reuslt logging is a common requirement in sensor
networks. Such logging should be reliable (a mote crash should not
lose data). It should also be easy to extract data from the log,
***************
*** 564,568 ****
the volume is full), others are <em>circular</em> (the oldest data is
overwritten when the volume is full).</p>
! <p>The <tt class="docutils literal"><span class="pre">LogStorageC</span></tt> service supports these requirements. The log is record
based: each call to <tt class="docutils literal"><span class="pre">LogWrite.append</span></tt> (see below) creates a new
record. On failure (crash or reboot), the log is guaranteed to only lose
--- 565,569 ----
the volume is full), others are <em>circular</em> (the oldest data is
overwritten when the volume is full).</p>
! <p>The <tt class="docutils literal"><span class="pre">LogStorageC</span></tt> abstraction supports these requirements. The log is record
based: each call to <tt class="docutils literal"><span class="pre">LogWrite.append</span></tt> (see below) creates a new
record. On failure (crash or reboot), the log is guaranteed to only lose
***************
*** 590,594 ****
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">LogWrite.append</span></tt>: append some bytes to the log. In a circular log,
! this may overwrite the current read position. In this case, the
read position is implicitly advanced to the log's current beginning
(i.e., as if <tt class="docutils literal"><span class="pre">LogRead.seek</span></tt> had been called with <tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt>).</p>
--- 591,595 ----
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">LogWrite.append</span></tt>: append some bytes to the log. In a circular log,
! this may overwrite the current read position. In this case, the
read position is implicitly advanced to the log's current beginning
(i.e., as if <tt class="docutils literal"><span class="pre">LogRead.seek</span></tt> had been called with <tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt>).</p>
***************
*** 613,617 ****
a prior call to <tt class="docutils literal"><span class="pre">LogWrite.currentOffset</span></tt> or <tt class="docutils literal"><span class="pre">LogRead.currentOffset</span></tt>,
or to the special <tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> value. In a circular log, if
! the specified position has been overwritten, behave as if
<tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> was requested.</p>
<p><tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> positions the read position at the beginning of
--- 614,618 ----
a prior call to <tt class="docutils literal"><span class="pre">LogWrite.currentOffset</span></tt> or <tt class="docutils literal"><span class="pre">LogRead.currentOffset</span></tt>,
or to the special <tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> value. In a circular log, if
! the specified position has been overwritten, behave as if
<tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> was requested.</p>
<p><tt class="docutils literal"><span class="pre">SEEK_BEGINNING</span></tt> positions the read position at the beginning of
***************
*** 625,635 ****
definitions.</p>
</div>
! <div class="section" id="small-objects">
! <h2><a name="small-objects">3.4 Small objects:</a></h2>
<p>Sensor network applications may need to store configuration data, e.g.,
mote id, radio frequency, sample rates, etc. Such data is not large, but
losing it may lead to a mote misbehaving or losing contact with the
network.</p>
! <p>The <tt class="docutils literal"><span class="pre">ConfigStorageC</span></tt> service stores a single small object in a volume. It:</p>
<ul class="simple">
<li>Assumes that configuration data is relatively small (a few
--- 626,636 ----
definitions.</p>
</div>
! <div class="section">
! <h2><a id="small-objects" name="small-objects">3.4 Small objects:</a></h2>
<p>Sensor network applications may need to store configuration data, e.g.,
mote id, radio frequency, sample rates, etc. Such data is not large, but
losing it may lead to a mote misbehaving or losing contact with the
network.</p>
! <p>The <tt class="docutils literal"><span class="pre">ConfigStorageC</span></tt> abstraction stores a single small object in a volume. It:</p>
<ul class="simple">
<li>Assumes that configuration data is relatively small (a few
***************
*** 651,655 ****
} ...
</pre>
! <p>A small object MUST be mounted (via the <tt class="docutils literal"><span class="pre">Mount</span></tt> interface) before
the first use.</p>
<p>The <tt class="docutils literal"><span class="pre">Mount</span></tt> and <tt class="docutils literal"><span class="pre">ConfigStorage</span></tt> interfaces contain the following
--- 652,656 ----
} ...
</pre>
! <p>A small object MUST be mounted (via the <tt class="docutils literal"><span class="pre">Mount</span></tt> interface) before
the first use.</p>
<p>The <tt class="docutils literal"><span class="pre">Mount</span></tt> and <tt class="docutils literal"><span class="pre">ConfigStorage</span></tt> interfaces contain the following
***************
*** 673,683 ****
</div>
</div>
! <div class="section" id="implementations">
! <h1><a name="implementations">4. Implementations</a></h1>
<p>An AT45DB implementation can be found in tinyos-2.x/tos/chips/at45db.</p>
<p>An ST M25P implementation can be found in tinyos-2.x/tos/chips/stm25p.</p>
</div>
! <div class="section" id="authors-addresses">
! <h1><a name="authors-addresses">5. Authors' Addresses</a></h1>
<div class="line-block">
<div class="line">David Gay</div>
--- 674,684 ----
</div>
</div>
! <div class="section">
! <h1><a id="implementations" name="implementations">4. Implementations</a></h1>
<p>An AT45DB implementation can be found in tinyos-2.x/tos/chips/at45db.</p>
<p>An ST M25P implementation can be found in tinyos-2.x/tos/chips/stm25p.</p>
</div>
! <div class="section">
! <h1><a id="authors-addresses" name="authors-addresses">5. Authors' Addresses</a></h1>
<div class="line-block">
<div class="line">David Gay</div>
***************
*** 699,706 ****
</div>
</div>
! <div class="section" id="appendix-a-haa-for-some-existing-flash-chips">
! <h1><a name="appendix-a-haa-for-some-existing-flash-chips">Appendix A. HAA for some existing flash chips</a></h1>
! <div class="section" id="a-1-at45db">
! <h2><a name="a-1-at45db">A.1 AT45DB</a></h2>
<p>The Atmel AT45DB family HPL is:</p>
<pre class="literal-block">
--- 700,723 ----
</div>
</div>
! <div class="section">
! <h1><a id="citations" name="citations">6. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id1" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="id1">[1]</a></td><td>David Gay. "Design of Matchbox, the simple filing system for
! motes. (version 1.0)."</td></tr>
! </tbody>
! </table>
! <table class="docutils footnote" frame="void" id="id2" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a name="id2">[2]</a></td><td>TEP 2: Hardware Abstraction Architecture.</td></tr>
! </tbody>
! </table>
! </div>
! <div class="section">
! <h1><a id="appendix-a-haa-for-some-existing-flash-chips" name="appendix-a-haa-for-some-existing-flash-chips">Appendix A. HAA for some existing flash chips</a></h1>
! <div class="section">
! <h2><a id="a-1-at45db" name="a-1-at45db">A.1 AT45DB</a></h2>
<p>The Atmel AT45DB family HPL is:</p>
<pre class="literal-block">
***************
*** 712,716 ****
buffer to flash, erase page, read, compute CRC, and write operations. Most
of these operations are asynchronous, i.e., their completion is signaled
! before the flash chip has completed the operation. The HPL also includes
operations to wait for asynchronous operations to complete.</p>
<p>A generic, system-independent implementation of the HPL
--- 729,733 ----
buffer to flash, erase page, read, compute CRC, and write operations. Most
of these operations are asynchronous, i.e., their completion is signaled
! before the flash chip has completed the operation. The HPL also includes
operations to wait for asynchronous operations to complete.</p>
<p>A generic, system-independent implementation of the HPL
***************
*** 752,757 ****
map volume-relative pages to absolute pages.</p>
</div>
! <div class="section" id="a-2-st-m25p">
! <h2><a name="a-2-st-m25p">A.2 ST M25P</a></h2>
<p>The ST M25P family HPL is:</p>
<pre class="literal-block">
--- 769,774 ----
map volume-relative pages to absolute pages.</p>
</div>
! <div class="section">
! <h2><a id="a-2-st-m25p" name="a-2-st-m25p">A.2 ST M25P</a></h2>
<p>The ST M25P family HPL is:</p>
<pre class="literal-block">
Index: tep106.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep106.html,v
retrieving revision 1.1.2.8
retrieving revision 1.1.2.9
diff -C2 -d -r1.1.2.8 -r1.1.2.9
*** tep106.html 13 Jun 2006 16:44:17 -0000 1.1.2.8
--- tep106.html 27 Jun 2006 20:23:04 -0000 1.1.2.9
***************
*** 304,308 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.8</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
--- 304,308 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
Index: tep107.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep107.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep107.html 13 Jun 2006 16:44:17 -0000 1.1.2.9
--- tep107.html 27 Jun 2006 20:23:04 -0000 1.1.2.10
***************
*** 304,308 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.10</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
--- 304,308 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.11</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
Index: tep108.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep108.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep108.html 21 Jun 2006 06:33:32 -0000 1.1.2.9
--- tep108.html 27 Jun 2006 20:23:04 -0000 1.1.2.10
***************
*** 12,39 ****
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
! :Date: $Date$
! :Revision: $Revision$
! :Copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
-
- See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
- customize this style sheet.
*/
!
! /* used to remove borders from tables and images */
! .borderless, table.borderless td, table.borderless th {
! border: 0 }
!
! table.borderless td, table.borderless th {
! /* Override padding for "table.docutils td" with "! important".
! The right padding separates the table cells. */
! padding: 0 0.5em 0 0 ! important }
.first {
- /* Override more specific margin styles with "! important". */
margin-top: 0 ! important }
! .last, .with-subtitle {
margin-bottom: 0 ! important }
--- 12,30 ----
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
! :date: $Date$
! :version: $Revision$
! :copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
! body {
! font-family: Times;
! font-size: 16px;
! }
.first {
margin-top: 0 ! important }
! .last {
margin-bottom: 0 ! important }
***************
*** 48,56 ****
margin: 2em 5em ; }
! dl.docutils dd {
margin-bottom: 0.5em }
! /* Uncomment (and remove this text!) to get bold-faced definition list terms
! dl.docutils dt {
font-weight: bold }
*/
--- 39,47 ----
margin: 2em 5em ; }
! dd {
margin-bottom: 0.5em }
! /* Uncomment (& remove this text!) to get bold-faced definition list terms
! dt {
font-weight: bold }
*/
***************
*** 63,78 ****
text-align: center }
! div.admonition, div.attention, div.caution, div.danger, div.error,
! div.hint, div.important, div.note, div.tip, div.warning {
margin: 2em ;
border: medium outset ;
padding: 1em }
- div.admonition p.admonition-title, div.hint p.admonition-title,
- div.important p.admonition-title, div.note p.admonition-title,
- div.tip p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
--- 54,63 ----
text-align: center }
! div.attention, div.caution, div.danger, div.error, div.hint,
! div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
***************
*** 82,93 ****
font-family: sans-serif }
! /* Uncomment (and remove this text!) to get reduced vertical space in
! compound paragraphs.
! div.compound .compound-first, div.compound .compound-middle {
! margin-bottom: 0.5em }
!
! div.compound .compound-last, div.compound .compound-middle {
! margin-top: 0.5em }
! */
div.dedication {
--- 67,75 ----
font-family: sans-serif }
! div.hint p.admonition-title, div.important p.admonition-title,
! div.note p.admonition-title, div.tip p.admonition-title,
! div.admonition p.admonition-title {
! font-weight: bold ;
! font-family: sans-serif }
div.dedication {
***************
*** 101,109 ****
div.figure {
! margin-left: 2em ;
! margin-right: 2em }
div.footer, div.header {
- clear: both;
font-size: smaller }
--- 83,89 ----
div.figure {
! margin-left: 2em }
div.footer, div.header {
font-size: smaller }
***************
*** 121,125 ****
margin-left: 1em ;
border: medium outset ;
! padding: 1em ;
background-color: #ffffee ;
width: 40% ;
--- 101,105 ----
margin-left: 1em ;
border: medium outset ;
! padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
***************
*** 148,169 ****
margin: 2em }
! h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
! h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
! margin-top: 0.4em }
h1.title {
! text-align: center }
h2.subtitle {
text-align: center }
! hr.docutils {
! width: 75% }
!
! img.align-left {
! clear: left }
! img.align-right {
! clear: right }
ol.simple, ul.simple {
--- 128,156 ----
margin: 2em }
! h1 {
! font-family: Arial, sans-serif;
! font-size: 20px;
! }
h1.title {
! text-align: center;
! font-size: 32px;
! }
!
! h2 {
! font-size: 16px;
! font-family: Arial, sans-serif;
! }
h2.subtitle {
text-align: center }
! h3 {
! font-size: 12px;
! font-family: Arial, sans-serif;
! }
! hr {
! width: 75% }
ol.simple, ul.simple {
***************
*** 223,230 ****
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
--- 210,225 ----
font-size: 100% }
+ pre.line-block {
+ font-family: serif ;
+ font-size: 100% }
+
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
***************
*** 242,245 ****
--- 237,243 ----
white-space: nowrap }
+ span.option-argument {
+ font-style: italic }
+
span.pre {
white-space: pre }
***************
*** 248,288 ****
color: red }
! span.section-subtitle {
! /* font-size relative to parent (h1..h6 element) */
! font-size: 80% }
table.citation {
! border-left: solid 1px gray;
! margin-left: 1px }
table.docinfo {
! margin: 2em 4em }
!
! table.docutils {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
table.footnote {
! border-left: solid 1px black;
! margin-left: 1px }
! table.docutils td, table.docutils th,
! table.docinfo td, table.docinfo th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
! table.docutils th.field-name, table.docinfo th.docinfo-name {
font-weight: bold ;
text-align: left ;
! white-space: nowrap ;
! padding-left: 0 }
! h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
! h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
font-size: 100% }
! tt.docutils {
! background-color: #eeeeee }
ul.auto-toc {
--- 246,280 ----
color: red }
! table {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
table.citation {
! border-left: solid thin gray ;
! padding-left: 0.5ex }
table.docinfo {
! margin: 2em 4em;
! }
table.footnote {
! border-left: solid thin black ;
! padding-left: 0.5ex }
! td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
! th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
! white-space: nowrap;
! }
! h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
! tt {}
ul.auto-toc {
***************
*** 316,322 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">28-Mar-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.8</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 308,314 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">28-Mar-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.9</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-21</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
Index: tep111.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep111.html,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep111.html 13 Jun 2006 16:44:17 -0000 1.1.2.9
--- tep111.html 27 Jun 2006 20:23:04 -0000 1.1.2.10
***************
*** 304,308 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jul-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.11</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
--- 304,308 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jul-2005</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.12</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
Index: tep113.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep113.html,v
retrieving revision 1.1.2.7
retrieving revision 1.1.2.8
diff -C2 -d -r1.1.2.7 -r1.1.2.8
*** tep113.html 14 Jun 2006 01:36:31 -0000 1.1.2.7
--- tep113.html 27 Jun 2006 20:23:04 -0000 1.1.2.8
***************
*** 4,11 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.7: http://docutils.sourceforge.net/" />
<title>Serial Communication</title>
<meta name="author" content="Ben Greenstein and Philip Levis" />
! <link rel="stylesheet" href="../stylesheets/tep.css" type="text/css" />
</head>
<body>
--- 4,285 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Serial Communication</title>
<meta name="author" content="Ben Greenstein and Philip Levis" />
! <style type="text/css">
!
! /*
! :Author: David Goodger
! :Contact: goodger at users.sourceforge.net
! :date: $Date$
! :version: $Revision$
! :copyright: This stylesheet has been placed in the public domain.
!
! Default cascading style sheet for the HTML output of Docutils.
! */
! body {
! font-family: Times;
! font-size: 16px;
! }
!
! .first {
! margin-top: 0 ! important }
!
! .last {
! margin-bottom: 0 ! important }
!
! .hidden {
! display: none }
!
! a.toc-backref {
! text-decoration: none ;
! color: black }
!
! blockquote.epigraph {
! margin: 2em 5em ; }
!
! dd {
! margin-bottom: 0.5em }
!
! /* Uncomment (& remove this text!) to get bold-faced definition list terms
! dt {
! font-weight: bold }
! */
!
! div.abstract {
! margin: 2em 5em }
!
! div.abstract p.topic-title {
! font-weight: bold ;
! text-align: center }
!
! div.attention, div.caution, div.danger, div.error, div.hint,
! div.important, div.note, div.tip, div.warning, div.admonition {
! margin: 2em ;
! border: medium outset ;
! padding: 1em }
!
! div.attention p.admonition-title, div.caution p.admonition-title,
! div.danger p.admonition-title, div.error p.admonition-title,
! div.warning p.admonition-title {
! color: red ;
! font-weight: bold ;
! font-family: sans-serif }
!
! div.hint p.admonition-title, div.important p.admonition-title,
! div.note p.admonition-title, div.tip p.admonition-title,
! div.admonition p.admonition-title {
! font-weight: bold ;
! font-family: sans-serif }
!
! div.dedication {
! margin: 2em 5em ;
! text-align: center ;
! font-style: italic }
!
! div.dedication p.topic-title {
! font-weight: bold ;
! font-style: normal }
!
! div.figure {
! margin-left: 2em }
!
! div.footer, div.header {
! font-size: smaller }
!
! div.line-block {
! display: block ;
! margin-top: 1em ;
! margin-bottom: 1em }
!
! div.line-block div.line-block {
! margin-top: 0 ;
! margin-bottom: 0 ;
! margin-left: 1.5em }
!
! div.sidebar {
! margin-left: 1em ;
! border: medium outset ;
! padding: 0em 1em ;
! background-color: #ffffee ;
! width: 40% ;
! float: right ;
! clear: right }
!
! div.sidebar p.rubric {
! font-family: sans-serif ;
! font-size: medium }
!
! div.system-messages {
! margin: 5em }
!
! div.system-messages h1 {
! color: red }
!
! div.system-message {
! border: medium outset ;
! padding: 1em }
!
! div.system-message p.system-message-title {
! color: red ;
! font-weight: bold }
!
! div.topic {
! margin: 2em }
!
! h1 {
! font-family: Arial, sans-serif;
! font-size: 20px;
! }
!
! h1.title {
! text-align: center;
! font-size: 32px;
! }
!
! h2 {
! font-size: 16px;
! font-family: Arial, sans-serif;
! }
!
! h2.subtitle {
! text-align: center }
!
! h3 {
! font-size: 12px;
! font-family: Arial, sans-serif;
! }
!
! hr {
! width: 75% }
!
! ol.simple, ul.simple {
! margin-bottom: 1em }
!
! ol.arabic {
! list-style: decimal }
!
! ol.loweralpha {
! list-style: lower-alpha }
!
! ol.upperalpha {
! list-style: upper-alpha }
!
! ol.lowerroman {
! list-style: lower-roman }
!
! ol.upperroman {
! list-style: upper-roman }
!
! p.attribution {
! text-align: right ;
! margin-left: 50% }
!
! p.caption {
! font-style: italic }
!
! p.credits {
! font-style: italic ;
! font-size: smaller }
!
! p.label {
! white-space: nowrap }
!
! p.rubric {
! font-weight: bold ;
! font-size: larger ;
! color: maroon ;
! text-align: center }
!
! p.sidebar-title {
! font-family: sans-serif ;
! font-weight: bold ;
! font-size: larger }
!
! p.sidebar-subtitle {
! font-family: sans-serif ;
! font-weight: bold }
!
! p.topic-title {
! font-weight: bold }
!
! pre.address {
! margin-bottom: 0 ;
! margin-top: 0 ;
! font-family: serif ;
! font-size: 100% }
!
! pre.line-block {
! font-family: serif ;
! font-size: 100% }
!
! pre.literal-block, pre.doctest-block {
! margin-left: 2em ;
! margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
!
! span.classifier {
! font-family: sans-serif ;
! font-style: oblique }
!
! span.classifier-delimiter {
! font-family: sans-serif ;
! font-weight: bold }
!
! span.interpreted {
! font-family: sans-serif }
!
! span.option {
! white-space: nowrap }
!
! span.option-argument {
! font-style: italic }
!
! span.pre {
! white-space: pre }
!
! span.problematic {
! color: red }
!
! table {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
!
! table.citation {
! border-left: solid thin gray ;
! padding-left: 0.5ex }
!
! table.docinfo {
! margin: 2em 4em;
! }
!
! table.footnote {
! border-left: solid thin black ;
! padding-left: 0.5ex }
!
! td, th {
! padding-left: 0.5em ;
! padding-right: 0.5em ;
! vertical-align: top }
!
! th.docinfo-name, th.field-name {
! font-weight: bold ;
! text-align: left ;
! white-space: nowrap;
! }
!
! h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
! font-size: 100% }
!
! tt {}
!
! ul.auto-toc {
! list-style-type: none }
!
! </style>
</head>
<body>
***************
*** 30,36 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">11-Jul-2005</td>
</tr>
! <tr class="field"><th class="do