[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep102.html,1.7,1.8

David Gay idgay at users.sourceforge.net
Wed May 23 14:42:00 PDT 2007


Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv16971/html

Modified Files:
	tep102.html 
Log Message:
update


Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep102.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** tep102.html	21 Apr 2007 07:04:39 -0000	1.7
--- tep102.html	23 May 2007 21:41:57 -0000	1.8
***************
*** 4,8 ****
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
  <title>Timers</title>
  <meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
--- 4,8 ----
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4.1: http://docutils.sourceforge.net/" />
  <title>Timers</title>
  <meta name="author" content="Cory Sharp, Martin Turon, David Gay" />
***************
*** 284,287 ****
--- 284,288 ----
  </head>
  <body>
+ <div class="document" id="timers">
  <h1 class="title">Timers</h1>
  <table class="docinfo" frame="void" rules="none">
***************
*** 303,309 ****
  <tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
  </tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.7</td>
  </tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-12-12</td>
  </tr>
  <tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List &lt;tinyos-devel at mail.millennium.berkeley.edu&gt;</td>
--- 304,310 ----
  <tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
  </tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.8</td>
  </tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-05-23</td>
  </tr>
  <tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List &lt;tinyos-devel at mail.millennium.berkeley.edu&gt;</td>
***************
*** 311,315 ****
  </tbody>
  </table>
- <div class="document" id="timers">
  <div class="note">
  <p class="first admonition-title">Note</p>
--- 312,315 ----
***************
*** 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>
***************
*** 372,376 ****
  binary milliseconds, 32768 32kHz ticks, or 1048576 microseconds.
  This TEP emphasizes millisecond and 32kHz tick precisions while
! reasonably accommodating other precisions.</p>
  <p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit.  The width
  for timer interfaces and components SHOULD be 32-bits.  That is, for
--- 372,378 ----
  binary milliseconds, 32768 32kHz ticks, or 1048576 microseconds.
  This TEP emphasizes millisecond and 32kHz tick precisions while
! reasonably accommodating other precisions. The use of &quot;binary&quot; units
! is motivated by the common availability of hardware clocks driven
! by a 32768Hz crystal.</p>
  <p>Examples of widths are 8-bit, 16-bit, 32-bit, and 64-bit.  The width
  for timer interfaces and components SHOULD be 32-bits.  That is, for
***************
*** 383,387 ****
  higher for internal vs crystal oscillators) and hardware limitations. As an
  example of hardware limitations, a mica2 clocked at 7.37MHz cannot offer an
! exact microsecond timer -- the closest it can come is 7.37MHz/8. Rather
  than introduce a plethora of precisions, we believe it is often best to
  pick the existing precision closest to what can be provided, along with
--- 385,389 ----
  higher for internal vs crystal oscillators) and hardware limitations. As an
  example of hardware limitations, a mica2 clocked at 7.37MHz cannot offer an
! exact binary microsecond timer -- the closest it can come is 7.37MHz/8. Rather
  than introduce a plethora of precisions, we believe it is often best to
  pick the existing precision closest to what can be provided, along with
***************
*** 395,410 ****
  precision and width for a given timer interface. Accuracy is not
  reflected in the interface type.</p>
! <p>Precision is expressed as an empty type -- TMilli, T32khz, and
  TMicro -- written in the standard Timer.h header like this:</p>
  <pre class="literal-block">
! typedef struct { } TMilli; // 1024 ticks per second
! typedef struct { } T32khz; // 32768 ticks per second
! typedef struct { } TMicro; // 1048576 ticks per second
  </pre>
  <p>Note that the precision names are expressed as either frequency or
  period, whichever is convenient.</p>
  </div>
! <div class="section" 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">
--- 397,412 ----
  precision and width for a given timer interface. Accuracy is not
  reflected in the interface type.</p>
! <p>Precision is expressed as a dummy type -- TMilli, T32khz, and
  TMicro -- written in the standard Timer.h header like this:</p>
  <pre class="literal-block">
! typedef struct { int notUsed; } TMilli; // 1024 ticks per second
! typedef struct { int notUsed; } T32khz; // 32768 ticks per second
! typedef struct { int notUsed; } TMicro; // 1048576 ticks per second
  </pre>
  <p>Note that the precision names are expressed as either frequency or
  period, whichever is convenient.</p>
  </div>
! <div class="section">
! <h2><a id="timer-interfaces" name="timer-interfaces">2.2 Timer interfaces</a></h2>
  <p>This TEP proposes these timer interfaces:</p>
  <pre class="literal-block">
***************
*** 420,430 ****
  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
! layer, and therefore qualify all Counters as HAL components.
! The Counter interface returns the current time and provides commands
  and an event for managing overflow conditions.  These overflow
  commands and events are necessary for properly deriving larger width
--- 422,428 ----
  advanced user components.</p>
  </div>
! <div class="section">
! <h2><a id="counter" name="counter">Counter</a></h2>
! <p>The Counter interface returns the current time and provides commands
  and an event for managing overflow conditions.  These overflow
  commands and events are necessary for properly deriving larger width
***************
*** 440,461 ****
  </pre>
  <dl class="docutils">
! <dt>get() </dt>
  <dd>return the current time.</dd>
! <dt>isOverflowPending() </dt>
  <dd>return TRUE if the overflow flag is set for this counter, i.e., if and
! only if an overflow interrupt will occur after the outermost atomic
  block exits.  Return FALSE otherwise.  This command only returns the
! state of the overflow flag and causes no side effect.  It is expected
! that the underlying hardware platform sets the overflow flag when
! appropriate.</dd>
! <dt>clearOverflow() </dt>
! <dd>cancel the pending overflow interrupt clearing the overflow flag.</dd>
! <dt>overflow() </dt>
  <dd>signals that an overflow in the current time.  That is, the current
  time has wrapped around from its maximum value to zero.</dd>
  </dl>
  </div>
! <div class="section" 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.
--- 438,457 ----
  </pre>
  <dl class="docutils">
! <dt>get()</dt>
  <dd>return the current time.</dd>
! <dt>isOverflowPending()</dt>
  <dd>return TRUE if the overflow flag is set for this counter, i.e., if and
! only if an overflow event will occur after the outermost atomic
  block exits.  Return FALSE otherwise.  This command only returns the
! state of the overflow flag and causes no side effect.</dd>
! <dt>clearOverflow()</dt>
! <dd>cancel the pending overflow event clearing the overflow flag.</dd>
! <dt>overflow()</dt>
  <dd>signals that an overflow in the current time.  That is, the current
  time has wrapped around from its maximum value to zero.</dd>
  </dl>
  </div>
! <div class="section">
! <h2><a id="alarm" name="alarm">Alarm</a></h2>
  <p>Alarm components are extensions of Counters that signal an event
  when their compare register detects the alarm time has been hit.
***************
*** 480,492 ****
  </pre>
  <dl class="docutils">
! <dt>start(dt) </dt>
  <dd>cancel any previously running alarm and set to fire in dt time units
  from the time of invocation.  The alarm will only fire once then
  stop.</dd>
! <dt>stop() </dt>
  <dd>cancel any previously running alarm.</dd>
! <dt>fired() </dt>
  <dd>signals that the alarm has occurred.</dd>
! <dt>isRunning() </dt>
  <dd>return TRUE if the alarm has been started and has not been cancelled
  or has not yet fired.  FALSE is returned otherwise.</dd>
--- 476,488 ----
  </pre>
  <dl class="docutils">
! <dt>start(dt)</dt>
  <dd>cancel any previously running alarm and set to fire in dt time units
  from the time of invocation.  The alarm will only fire once then
  stop.</dd>
! <dt>stop()</dt>
  <dd>cancel any previously running alarm.</dd>
! <dt>fired()</dt>
  <dd>signals that the alarm has occurred.</dd>
! <dt>isRunning()</dt>
  <dd>return TRUE if the alarm has been started and has not been cancelled
  or has not yet fired.  FALSE is returned otherwise.</dd>
***************
*** 494,506 ****
  <p>startAt(t0,dt)</p>
  <blockquote>
! 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 taken
  before the invocation of startAt.  The timer subsystem uses this form
  internally, to be able to use of the full width of an alarm while also
! detecting when a short alarm elapses prematurely.</blockquote>
  <dl class="docutils">
! <dt>getNow() </dt>
  <dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm() </dt>
  <dd>return the time the currently running alarm will fire or the time
  that the previously running alarm was set to fire.  getAlarm can
--- 490,506 ----
  <p>startAt(t0,dt)</p>
  <blockquote>
! <p>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 taken
  before the invocation of startAt.  The timer subsystem uses this form
  internally, to be able to use of the full width of an alarm while also
! detecting when a short alarm elapses prematurely.</p>
! <p>The time <tt class="docutils literal"><span class="pre">t0</span></tt> is always assumed to be in the past. A value of <tt class="docutils literal"><span class="pre">t0</span></tt>
! numerically greater than the current time (returned by <tt class="docutils literal"><span class="pre">getNow()</span></tt>)
! represents a time from before the last wraparound.</p>
! </blockquote>
  <dl class="docutils">
! <dt>getNow()</dt>
  <dd>return the current time in the precision and width of the alarm.</dd>
! <dt>getAlarm()</dt>
  <dd>return the time the currently running alarm will fire or the time
  that the previously running alarm was set to fire.  getAlarm can
***************
*** 510,515 ****
  </dl>
  </div>
! <div class="section" id="busywait">
! <h2><a name="busywait">BusyWait</a></h2>
  <p>The BusyWait interface allows for very short synchronous delays.
  BusyWait should be used sparingly and when an Alarm would not be
--- 510,515 ----
  </dl>
  </div>
! <div class="section">
! <h2><a id="busywait" name="busywait">BusyWait</a></h2>
  <p>The BusyWait interface allows for very short synchronous delays.
  BusyWait should be used sparingly and when an Alarm would not be
***************
*** 531,536 ****
  </dl>
  </div>
! <div class="section" id="localtime">
! <h2><a name="localtime">LocalTime</a></h2>
  <p>The LocalTime interface exposes a 32-bit counter without overflow
  utilities.  This is primarily for application code that does not
--- 531,536 ----
  </dl>
  </div>
! <div class="section">
! <h2><a id="localtime" name="localtime">LocalTime</a></h2>
  <p>The LocalTime interface exposes a 32-bit counter without overflow
  utilities.  This is primarily for application code that does not
***************
*** 543,552 ****
  </pre>
  <dl class="docutils">
! <dt>get() </dt>
  <dd>return the current time.</dd>
  </dl>
  </div>
! <div class="section" id="timer">
! <h2><a name="timer">Timer</a></h2>
  <p>All commands and events of the Timer interface are synchronous (or
  in &quot;task context&quot;).  The Timer interface provides a set of &quot;basic&quot;
--- 543,552 ----
  </pre>
  <dl class="docutils">
! <dt>get()</dt>
  <dd>return the current time.</dd>
  </dl>
  </div>
! <div class="section">
! <h2><a id="timer" name="timer">Timer</a></h2>
  <p>All commands and events of the Timer interface are synchronous (or
  in &quot;task context&quot;).  The Timer interface provides a set of &quot;basic&quot;
***************
*** 573,614 ****
  </pre>
  <dl class="docutils">
! <dt>startPeriodic(dt) </dt>
  <dd>cancel any previously running timer and set to fire in dt time units
  from the time of invocation.  The timer will fire periodically every
  dt time units until stopped.</dd>
! <dt>startOneShot(dt) </dt>
  <dd>cancel any previously running timer and set to fire in dt time units
  from the time of invocation.  The timer will only fire once then
  stop.</dd>
! <dt>stop() </dt>
  <dd>cancel any previously running timer.</dd>
  <dt>fired()</dt>
  <dd>signals that the timer has occurred.</dd>
! <dt>isRunning() </dt>
  <dd>return TRUE if the timer has been started and has not been cancelled
  and has not fired for the case of one-shot timers.  One a periodic
  timer is started, isRunning will return TRUE until it is cancelled.</dd>
! <dt>isOneShot() </dt>
  <dd>return TRUE if the timer is a one-shot timer.  Return FALSE
  otherwise if the timer is a periodic timer.</dd>
! <dt>startPeriodicAt(t0,dt) </dt>
! <dd>cancel any previously running timer and set to fire at time t1 =
  t0+dt.  The timer will fire periodically every dt time units until
! stopped.</dd>
! <dt>startOneShotAt(t0,dt) </dt>
! <dd>cancel any previously running timer and set to fire at time t1 =
! t0+dt.  The timer will fire once then stop.</dd>
! <dt>getNow() </dt>
  <dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0() </dt>
  <dd>return the time anchor for the previously started timer or the time
  of the previous event for periodic timers.</dd>
! <dt>getdt() </dt>
  <dd>return the delay or period for the previously started timer.</dd>
  </dl>
  </div>
  </div>
! <div class="section" id="hal-guidelines">
! <h1><a name="hal-guidelines">3. HAL guidelines</a></h1>
  <p>Platforms SHOULD expose their relevant timing capabilities using
  standard Alarm and Counter interfaces.  The design pattern presented
--- 573,620 ----
  </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><p class="first">cancel any previously running timer and set to fire at time t1 =
  t0+dt.  The timer will fire periodically every dt time units until
! stopped.</p>
! <p class="last">As with alarms, the time <tt class="docutils literal"><span class="pre">t0</span></tt> is always assumed to be in the past. A
! value of <tt class="docutils literal"><span class="pre">t0</span></tt> numerically greater than the current time (returned by
! <tt class="docutils literal"><span class="pre">getNow()</span></tt>) represents a time from before the last wraparound.</p>
! </dd>
! <dt>startOneShotAt(t0,dt)</dt>
! <dd><p class="first">cancel any previously running timer and set to fire at time t1 =
! t0+dt.  The timer will fire once then stop.</p>
! <p class="last"><tt class="docutils literal"><span class="pre">t0</span></tt> is as in <tt class="docutils literal"><span class="pre">startPeriodicAt</span></tt>.</p>
! </dd>
! <dt>getNow()</dt>
  <dd>return the current time in the precision and width of the timer.</dd>
! <dt>gett0()</dt>
  <dd>return the time anchor for the previously started timer or the time
  of the previous event for periodic timers.</dd>
! <dt>getdt()</dt>
  <dd>return the delay or period for the previously started timer.</dd>
  </dl>
  </div>
  </div>
! <div class="section">
! <h1><a id="hal-guidelines" name="hal-guidelines">3. HAL guidelines</a></h1>
  <p>Platforms SHOULD expose their relevant timing capabilities using
  standard Alarm and Counter interfaces.  The design pattern presented
***************
*** 630,639 ****
  }
  </pre>
! <p>Instantiating an Alarm${P}${W}C component provides a new and
! independent Alarm.  If the platform presents a limited number of
! Alarm resources, then allocating more Alarms in an application than
! are available for the platform SHOULD produce a compile-time error.
! See Appendix B for an example of how to make allocatable Alarms that
! are each implemented on independent hardware timers.</p>
  <p>For example, if a platform has an 8-bit 32kHz counter and three
  8-bit 32kHz alarms, then the Counter and Alarm interfaces for
--- 636,645 ----
  }
  </pre>
! <p>Instantiating an Alarm${P}${W}C component provides a new and independent
! Alarm.  If the platform presents a limited number of Alarm resources,
! then allocating more Alarms in an application than are available for the
! platform SHOULD produce a compile-time error.  See Appendices B and C
! for an example of how to make allocatable Alarms that are each
! implemented on independent hardware timers.</p>
  <p>For example, if a platform has an 8-bit 32kHz counter and three
  8-bit 32kHz alarms, then the Counter and Alarm interfaces for
***************
*** 655,660 ****
  together.</p>
  </div>
! <div class="section" id="hil-requirements">
! <h1><a name="hil-requirements">4. HIL requirements</a></h1>
  <dl class="docutils">
  <dt>The following component MUST be provided on all platforms::</dt>
--- 661,666 ----
  together.</p>
  </div>
! <div class="section">
! <h1><a id="hil-requirements" name="hil-requirements">4. HIL requirements</a></h1>
  <dl class="docutils">
  <dt>The following component MUST be provided on all platforms::</dt>
***************
*** 662,667 ****
  BusyWaitMicroC</dd>
  </dl>
! <div class="section" id="hiltimermillic">
! <h2><a name="hiltimermillic">HilTimerMilliC</a></h2>
  <pre class="literal-block">
  configuration HilTimerMilliC
--- 668,673 ----
  BusyWaitMicroC</dd>
  </dl>
! <div class="section">
! <h2><a id="hiltimermillic" name="hiltimermillic">HilTimerMilliC</a></h2>
  <pre class="literal-block">
  configuration HilTimerMilliC
***************
*** 669,672 ****
--- 675,679 ----
    provides interface Init;
    provides interface Timer&lt;TMilli&gt; as TimerMilli[ uint8_t num ];
+   provides interface LocalTime&lt;TMilli&gt;;
  }
  </pre>
***************
*** 674,682 ****
  new unique timer number.  This timer number is used to index the
  TimerMilli parameterised interface.  UQ_TIMER_MILLI is defined in
! Timer.h.  HilTimerMilliC is used by the generic component
! TimerMilliC found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt>.</p>
  </div>
! <div class="section" id="busywaitmicroc">
! <h2><a name="busywaitmicroc">BusyWaitMicroC</a></h2>
  <pre class="literal-block">
  configuration BusyWaitMicroC
--- 681,689 ----
  new unique timer number.  This timer number is used to index the
  TimerMilli parameterised interface.  UQ_TIMER_MILLI is defined in
! Timer.h.  HilTimerMilliC is used by the LocalTimeMilliC component and the
! TimerMilliC generic component, both found in <tt class="docutils literal"><span class="pre">tos/system/</span></tt></p>
  </div>
! <div class="section">
! <h2><a id="busywaitmicroc" name="busywaitmicroc">BusyWaitMicroC</a></h2>
  <pre class="literal-block">
  configuration BusyWaitMicroC
***************
*** 691,696 ****
  </div>
  </div>
! <div class="section" id="utility-components">
! <h1><a name="utility-components">5. Utility components</a></h1>
  <p>A number of platform independent generic components are provided to
  help implementers and advanced users of the TinyOS timer system:</p>
--- 698,703 ----
  </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>
***************
*** 705,710 ****
  <p>Appendices B and C show how these can be used to help implement
  the timer HAL and HIL.</p>
! <div class="section" id="alarmtotimerc">
! <h2><a name="alarmtotimerc">AlarmToTimerC</a></h2>
  <p>AlarmToTimerC converts a 32-bit Alarm to a Timer.</p>
  <pre class="literal-block">
--- 712,717 ----
  <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">
***************
*** 716,721 ****
  </pre>
  </div>
! <div class="section" id="busywaitcounterc">
! <h2><a name="busywaitcounterc">BusyWaitCounterC</a></h2>
  <p>BusyWaitCounterC uses a Counter to block until a specified amount of
  time elapses.</p>
--- 723,728 ----
  </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>
***************
*** 729,734 ****
  </pre>
  </div>
! <div class="section" id="countertolocaltimec">
! <h2><a name="countertolocaltimec">CounterToLocalTimeC</a></h2>
  <p>CounterToLocalTimeC converts from a 32-bit Counter to LocalTime.</p>
  <pre class="literal-block">
--- 736,741 ----
  </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">
***************
*** 740,749 ****
  </pre>
  </div>
! <div class="section" id="transformalarmc">
! <h2><a name="transformalarmc">TransformAlarmC</a></h2>
  <p>TransformAlarmC decreases precision and/or widens an Alarm.  An
  already widened Counter component is used to help.</p>
  <pre class="literal-block">
! generic component TransformAlarmC( 
    typedef to_precision_tag,
    typedef to_size_type &#64;integer(),
--- 747,756 ----
  </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 &#64;integer(),
***************
*** 773,778 ****
  passed to TransformAlarmC are inconsistent.</p>
  </div>
! <div class="section" id="transformcounterc">
! <h2><a name="transformcounterc">TransformCounterC</a></h2>
  <p>TransformCounterC decreases precision and/or widens a Counter.</p>
  <pre class="literal-block">
--- 780,785 ----
  passed to TransformAlarmC are inconsistent.</p>
  </div>
! <div class="section">
! <h2><a id="transformcounterc" name="transformcounterc">TransformCounterC</a></h2>
  <p>TransformCounterC decreases precision and/or widens a Counter.</p>
  <pre class="literal-block">
***************
*** 792,796 ****
  final width for the provided Counter.  from_precision_tag and
  from_size_type describe the precision and width for the source
! AlarmFrom.  bit_shift_right describes the bit-shift necessary to
  convert from the used precision to the provided precision.
  upper_count_type describes the numeric type used to store the
--- 799,803 ----
  final width for the provided Counter.  from_precision_tag and
  from_size_type describe the precision and width for the source
! CounterFrom.  bit_shift_right describes the bit-shift necessary to
  convert from the used precision to the provided precision.
  upper_count_type describes the numeric type used to store the
***************
*** 805,810 ****
  </pre>
  </div>
! <div class="section" id="virtualizetimerc">
! <h2><a name="virtualizetimerc">VirtualizeTimerC</a></h2>
  <p>VirtualizeTimerC uses a single Timer to create up to 255 virtual
  timers.</p>
--- 812,817 ----
  </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>
***************
*** 819,824 ****
  </div>
  </div>
! <div class="section" id="implementation">
! <h1><a name="implementation">6. Implementation</a></h1>
  <p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
  <blockquote>
--- 826,831 ----
  </div>
  </div>
! <div class="section">
! <h1><a id="implementation" name="implementation">6. Implementation</a></h1>
  <p>The definition of the HIL interfaces are found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/timer</span></tt>:</p>
  <blockquote>
***************
*** 840,844 ****
  <li><tt class="docutils literal"><span class="pre">CounterToLocalTimeC.nc</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">TransformAlarmC.nc</span></tt></li>
- <li><tt class="docutils literal"><span class="pre">TransformAlarmCounterC.nc</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">TransformCounterC.nc</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">VirtualizeAlarmC.nc</span></tt></li>
--- 847,850 ----
***************
*** 861,865 ****
  <li><tt class="docutils literal"><span class="pre">CounterMilli32C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter&lt;TMilli,uint32_t&gt;</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">GpioCaptureC.nc</span></tt></li>
! <li><tt class="docutils literal"><span class="pre">HilTimerMilliC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Timer&lt;TMilli&gt;</span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">Msp430AlarmC.nc</span></tt> is generic and converts an MSP430 timer to a 16-bit Alarm</li>
  <li><tt class="docutils literal"><span class="pre">Msp430Capture.nc</span></tt> HPL interface definition for MSP430 timer captures</li>
--- 867,872 ----
  <li><tt class="docutils literal"><span class="pre">CounterMilli32C.nc</span></tt> provides <tt class="docutils literal"><span class="pre">Counter&lt;TMilli,uint32_t&gt;</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">GpioCaptureC.nc</span></tt></li>
! <li><tt class="docutils literal"><span class="pre">HilTimerMilliC.nc</span></tt> provides <tt class="docutils literal"><span class="pre">LocalTime&lt;TMilli&gt;</span></tt> and
! <tt class="docutils literal"><span class="pre">Timer&lt;TMilli&gt;</span> <span class="pre">as</span> <span class="pre">TimerMilli[uint8_t</span> <span class="pre">num]</span></tt></li>
  <li><tt class="docutils literal"><span class="pre">Msp430AlarmC.nc</span></tt> is generic and converts an MSP430 timer to a 16-bit Alarm</li>
  <li><tt class="docutils literal"><span class="pre">Msp430Capture.nc</span></tt> HPL interface definition for MSP430 timer captures</li>
***************
*** 890,895 ****
  </blockquote>
  </div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">7. Author's Address</a></h1>
  <div class="line-block">
  <div class="line">Cory Sharp</div>
--- 897,902 ----
  </blockquote>
  </div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
  <div class="line-block">
  <div class="line">Cory Sharp</div>
***************
*** 919,924 ****
  </div>
  </div>
! <div class="section" id="appendix-a-timer-hardware-on-various-microcontrollers">
! <h1><a name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
  <blockquote>
  <ol class="loweralpha simple">
--- 926,931 ----
  </div>
  </div>
! <div class="section">
! <h1><a id="appendix-a-timer-hardware-on-various-microcontrollers" name="appendix-a-timer-hardware-on-various-microcontrollers">Appendix A: Timer hardware on various microcontrollers</a></h1>
  <blockquote>
  <ol class="loweralpha simple">
***************
*** 996,1001 ****
  </blockquote>
  </div>
! <div class="section" id="appendix-b-a-microcontroller-atmega-128-timer-subsystem">
! <h1><a name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
  <p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
  <blockquote>
--- 1003,1008 ----
  </blockquote>
  </div>
! <div class="section">
! <h1><a id="appendix-b-a-microcontroller-atmega-128-timer-subsystem" name="appendix-b-a-microcontroller-atmega-128-timer-subsystem">Appendix B: a microcontroller: Atmega 128 timer subsystem</a></h1>
  <p>The Atmega128 exposes its four timers through a common set of interfaces:</p>
  <blockquote>
***************
*** 1027,1031 ****
  
    /// Clock initialization interface
!   async command void    off();                     //&lt;! Turn off the clock 
    async command void    setScale( uint8_t scale);  //&lt;! Turn on the clock
    async command uint8_t getScale();                //&lt;! Get prescaler setting
--- 1034,1038 ----
  
    /// Clock initialization interface
!   async command void    off();                     //&lt;! Turn off the clock
    async command void    setScale( uint8_t scale);  //&lt;! Turn on the clock
    async command uint8_t getScale();                //&lt;! Get prescaler setting
***************
*** 1058,1062 ****
    async event void captured(size_type t);  //&lt;! Signalled on capture int
  
!   /// Interrupt flag utilites: Bit level set/clr  
    async command void reset();          //&lt;! Clear the capture interrupt flag
    async command void start();          //&lt;! Enable the capture interrupt
--- 1065,1069 ----
    async event void captured(size_type t);  //&lt;! Signalled on capture int
  
!   /// Interrupt flag utilites: Bit level set/clr
    async command void reset();          //&lt;! Clear the capture interrupt flag
    async command void start();          //&lt;! Enable the capture interrupt
***************
*** 1068,1073 ****
  }
  </pre>
! <p>These interfaces are provided by four components, corresponding to
! each hardware timer: HplAtm128Timer0C through HplAtm128Timer3C.</p>
  <p>The Atmega128 chip components do not define a HAL, as the timer
  configuration choices (frequencies, use of input capture or compare output,
--- 1075,1104 ----
  }
  </pre>
! <p>These interfaces are provided by four components, corresponding to each
! hardware timer: HplAtm128Timer0AsyncC, and HplAtm128Timer0C through
! HplAtm128Timer3C. Timers 1 and 3 have three compare registers, so offer
! a parameterised HplAtm128Compare interface:</p>
! <pre class="literal-block">
! configuration HplAtm128Timer1C
! {
!   provides {
!     // 16-bit Timers
!     interface HplAtm128Timer&lt;uint16_t&gt;   as Timer;
!     interface HplAtm128TimerCtrl16       as TimerCtrl;
!     interface HplAtm128Capture&lt;uint16_t&gt; as Capture;
!     interface HplAtm128Compare&lt;uint16_t&gt; as Compare[uint8_t id];
!   }
! }
! ...
! </pre>
! <p>where the <tt class="docutils literal"><span class="pre">id</span></tt> corresponds to the compare register number. The parameterised
! interface is only connected for <tt class="docutils literal"><span class="pre">id</span></tt> equal to 0, 1 or 2. Attempts to use
! another value cause a compile-time error. This is achieved as follows (code
! from the implementation of <tt class="docutils literal"><span class="pre">HplAtm128Timer1C</span></tt>)</p>
! <pre class="literal-block">
! Compare[0] = HplAtm128Timer1P.CompareA;
! Compare[1] = HplAtm128Timer1P.CompareB;
! Compare[2] = HplAtm128Timer1P.CompareC;
! </pre>
  <p>The Atmega128 chip components do not define a HAL, as the timer
  configuration choices (frequencies, use of input capture or compare output,
***************
*** 1095,1101 ****
  } ...
  </pre>
  </div>
! <div class="section" id="appendix-c-a-mote-mica-family-timer-subsystem">
! <h1><a name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
  <p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
  microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
--- 1126,1146 ----
  } ...
  </pre>
+ <p>As a result of issues arising from using timer 0 in asynchronous mode,
+ the HAL also offers the following component:</p>
+ <pre class="literal-block">
+ generic configuration Atm128AlarmAsyncC(typedef precision, int divider) {
+   provides {
+     interface Init &#64;atleastonce();
+     interface Alarm&lt;precision, uint32_t&gt;;
+     interface Counter&lt;precision, uint32_t&gt;;
+   }
+ }
+ ...
+ </pre>
+ <p>which builds a 32-bit alarm and timer over timer 0. divider is used
+ to initialise the timer0 scaling factor.</p>
  </div>
! <div class="section">
! <h1><a id="appendix-c-a-mote-mica-family-timer-subsystem" name="appendix-c-a-mote-mica-family-timer-subsystem">Appendix C: a mote: Mica family timer subsystem</a></h1>
  <p>Members of the mica family (mica2, mica2dot, micaz) use the Atmega128
  microprocessor and have external crystals at 4 or 7.37MHz. Additionally,
***************
*** 1111,1129 ****
  of this MHZ symbol:</p>
  <ul>
! <li><p class="first">Timer 0: divides the external 32768Hz crystal by 32 to build AlarmMilli8C
! and AlarmMilli32C (see Section 3). As timer 0 has a single compare
! register, these can only be instantiated once.
! Timing accuracy is as good as the external crystal.</p>
  </li>
  <li><p class="first">Timer 1: the 16-bit hardware timer 1 is set to run at 1MHz if possible.
  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>
  as suggested in Section 3).</p>
! <p>When building the 32-bit counter and 32-bit alarms, the rate of
! timer 1 is adjusted in software to 1MHz. Thus the 32-bit HAL components
! for timer <em>are</em> named <tt class="docutils literal"><span class="pre">CounterMicro32C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt>.</p>
  <p>Three compare registers are available on timer1, so up to three instances
  of <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> and/or <tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt> can be created. The timing
--- 1156,1176 ----
  of this MHZ symbol:</p>
  <ul>
! <li><p class="first">Timer 0: uses Atm128AlarmAsyncC to divide the external 32768Hz crystal
! by 32, creating a 32-bit alarm and counter. This alarm and counter is
! used to build HilTimerMilliC, using the AlarmToTimerC,
! VirtualizeTimerC and CounterToLocalTimeC utility components.</p>
! <p>Timing accuracy is as good as the external crystal.</p>
  </li>
  <li><p class="first">Timer 1: the 16-bit hardware timer 1 is set to run at 1MHz if possible.
  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>
  as suggested in Section 3).</p>
! <p>32-bit microsecond Counters and Alarms, named <tt class="docutils literal"><span class="pre">CounterMicro32C</span></tt> and
! <tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt>, are created from <tt class="docutils literal"><span class="pre">CounterOne16C</span></tt> and
! <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> using the TransformAlarmC and TransformCounterC
! utility components.</p>
  <p>Three compare registers are available on timer1, so up to three instances
  of <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt> and/or <tt class="docutils literal"><span class="pre">AlarmMicro32C</span></tt> can be created. The timing
***************
*** 1140,1146 ****
  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
  <tt class="docutils literal"><span class="pre">Counter32khz32C</span></tt> and <tt class="docutils literal"><span class="pre">Alarm32khz32C</span></tt>. As with timer 1, three compare
  registers, hence up to three instances of <tt class="docutils literal"><span class="pre">Alarm32khz32C</span></tt> and/or
--- 1187,1193 ----
  32768Hz, if possible. As with timer 1, the limited set of dividers makes
  this impossible at some clock frequencies, so the 16-bit timer 3 HAL
! components are named <tt class="docutils literal"><span class="pre">CounterThree16C</span></tt> and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt>. As
! with timer 1, the rate of timer 3 is adjusted in software to
! build 32-bit counter and 32-bit alarms, giving components
  <tt class="docutils literal"><span class="pre">Counter32khz32C</span></tt> and <tt class="docutils literal"><span class="pre">Alarm32khz32C</span></tt>. As with timer 1, three compare
  registers, hence up to three instances of <tt class="docutils literal"><span class="pre">Alarm32khz32C</span></tt> and/or
***************
*** 1151,1154 ****
--- 1198,1226 ----
  </li>
  </ul>
+ <p>The automatic allocation of compare registers to alarms (and
+ corresponding compile-time error when too many compare registers are
+ used) is achieved as follows.  The implementations of <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt>
+ and <tt class="docutils literal"><span class="pre">AlarmThree16C</span></tt> use the <tt class="docutils literal"><span class="pre">Atm128AlarmC</span></tt> generic component and
+ wire it, using <tt class="docutils literal"><span class="pre">unique</span></tt>, to one of the compare registers offered by
+ <tt class="docutils literal"><span class="pre">HplAtm128Timer1C</span></tt> and <tt class="docutils literal"><span class="pre">HplAtm128Timer3C</span></tt>:</p>
+ <pre class="literal-block">
+ generic configuration AlarmOne16C()
+ {
+   provides interface Alarm&lt;TOne, uint16_t&gt;;
+ }
+ implementation
+ {
+   components HplAtm128Timer1C, InitOneP,
+     new Atm128AlarmC(TOne, uint16_t, 3) as NAlarm;
+ 
+   Alarm = NAlarm;
+   NAlarm.HplAtm128Timer -&gt; HplAtm128Timer1C.Timer;
+   NAlarm.HplAtm128Compare -&gt; HplAtm128Timer1C.Compare[unique(UQ_TIMER1_COMPARE)];
+ }
+ </pre>
+ <p>On the fourth creation of an <tt class="docutils literal"><span class="pre">AlarmOne16C</span></tt>, <tt class="docutils literal"><span class="pre">unique(UQ_TIMER1_COMPARE)</span></tt>
+ will return 3, causing a compile-time error as discussed in Appendix B
+ (<tt class="docutils literal"><span class="pre">HplAtm128Timer1C</span></tt>'s <tt class="docutils literal"><span class="pre">Compare</span></tt> interface is only defined for values
+ from 0 to 2).</p>
  <p>When an Atmega128 is in any power-saving mode, hardware timers 1, 2 and 3
  stop counting. The default Atmega128 power management <em>will</em> enter these
***************
*** 1159,1164 ****
  <p>The mica family HIL components are built as follows:</p>
  <ul class="simple">
! <li>TimerMilliC: built using AlarmMilli32C (consuming its single compare
! register)</li>
  <li>BusyWaitMicroC: implemented using a simple software busy-wait loop which
  waits for <tt class="docutils literal"><span class="pre">MHZ</span></tt> cycles per requested microsecond. Accuracy is the same as
--- 1231,1235 ----
  <p>The mica family HIL components are built as follows:</p>
  <ul class="simple">
! <li>HilTimerMilliC: built as described above from hardware timer 0.</li>
  <li>BusyWaitMicroC: implemented using a simple software busy-wait loop which
  waits for <tt class="docutils literal"><span class="pre">MHZ</span></tt> cycles per requested microsecond. Accuracy is the same as



More information about the Tinyos-2-commits mailing list