[Tinyos-2-commits]
CVS: tinyos-2.x/doc/html install-tinyos.html, 1.7,
1.8 overview.html, 1.5, 1.6 porting.html, 1.4, 1.5 tep1.html,
1.5, 1.6 tep101.html, 1.5, 1.6 tep102.html, 1.5,
1.6 tep103.html, 1.5, 1.6 tep106.html, 1.5, 1.6 tep107.html,
1.5, 1.6 tep108.html, 1.5, 1.6 tep109.html, 1.5,
1.6 tep110.html, 1.5, 1.6 tep111.html, 1.5, 1.6 tep112.html,
1.5, 1.6 tep113.html, 1.5, 1.6 tep114.html, 1.5,
1.6 tep115.html, 1.5, 1.6 tep116.html, 1.5, 1.6 tep117.html,
1.5, 1.6 tep118.html, 1.5, 1.6 tep119.html, 1.6,
1.7 tep120.html, 1.5, 1.6 tep121.html, 1.5, 1.6 tep123.html,
1.5, 1.6 tep2.html, 1.5, 1.6 tep3.html, 1.5, 1.6
Vlado Handziski
vlahan at users.sourceforge.net
Tue Dec 12 10:24:20 PST 2006
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv383/doc/html
Modified Files:
install-tinyos.html overview.html porting.html tep1.html
tep101.html tep102.html tep103.html tep106.html tep107.html
tep108.html tep109.html tep110.html tep111.html tep112.html
tep113.html tep114.html tep115.html tep116.html tep117.html
tep118.html tep119.html tep120.html tep121.html tep123.html
tep2.html tep3.html
Log Message:
Swapping HEAD and DEVEL branches
Index: install-tinyos.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/install-tinyos.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** install-tinyos.html 7 Nov 2006 19:30:38 -0000 1.7
--- install-tinyos.html 12 Dec 2006 18:22:53 -0000 1.8
***************
*** 73,76 ****
--- 73,78 ----
<p>
<ol>
+ <li> Download and install Cygwin from <A HREF="http://www.cygwin.com">www.cygwin.com</A>.</li>
+ <p>
<li> Download the confirmed-compatible cygwin packages from the tinyos web site <a href="http://www.tinyos.net/dist-1.2.0/tools/windows/cygwin-1.2a.tgz">here</a>.
<p>
***************
*** 291,296 ****
<tr>
<td>TinyOS</td>
! <td><a href="http://www.tinyos.net/dist-2.0.0/tinyos/windows/tinyos-2.0.0-1.cygwin.noarch.rpm">tinyos-2.0.0-1.cygwin.noarch.rpm</a></td>
! <td><a href="http://www.tinyos.net/dist-2.0.0/tinyos/linux/tinyos-2.0.0-1.noarch.rpm">tinyos-2.0.0-1.noarch.rpm</a></td>
</tr>
--- 293,298 ----
<tr>
<td>TinyOS</td>
! <td><a href="http://www.tinyos.net/dist-2.0.0/tinyos/windows/tinyos-2.0.0-3.cygwin.noarch.rpm">tinyos-2.0.0-3.cygwin.noarch.rpm</a></td>
! <td><a href="http://www.tinyos.net/dist-2.0.0/tinyos/linux/tinyos-2.0.0-3.noarch.rpm">tinyos-2.0.0-3.noarch.rpm</a></td>
</tr>
Index: tep106.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep106.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep106.html 7 Nov 2006 19:30:38 -0000 1.5
--- tep106.html 12 Dec 2006 18:22:53 -0000 1.6
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-08-17</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.11</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-11-07</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 628,632 ****
The key used for task unique identifiers MUST be "TinySchedulerC.TaskInterface",
where <em>TaskInterface</em> is the name of the new task interface as presented
! by the scheduler. For example, the module SomethingP requires two EDF
tasks:</p>
<pre class="literal-block">
--- 628,637 ----
The key used for task unique identifiers MUST be "TinySchedulerC.TaskInterface",
where <em>TaskInterface</em> is the name of the new task interface as presented
! by the scheduler. A common way to make sure a consistent string is used
! is to #define it. For example, TaskEdf.nc might include:</p>
! <pre class="literal-block">
! #define UQ_TASK_EDF "TinySchedulerC.TaskEdf"
! </pre>
! <p>In this example, the module SomethingP requires two EDF
tasks:</p>
<pre class="literal-block">
***************
*** 636,641 ****
implementation {
components SomethingP, TinySchedulerC;
! SomethingP.SendTask -> TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];
! SomethingP.SenseTask -> TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];
}
</pre>
--- 641,646 ----
implementation {
components SomethingP, TinySchedulerC;
! SomethingP.SendTask -> TinySchedulerC.TaskEdf[unique(UQ_TASK_EDF)];
! SomethingP.SenseTask -> TinySchedulerC.TaskEdf[unique(UQ_TASK_EDF)];
}
</pre>
Index: tep109.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep109.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep109.html 7 Nov 2006 19:30:38 -0000 1.5
--- tep109.html 12 Dec 2006 18:22:53 -0000 1.6
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Sensors and Sensor Boards</title>
<meta name="author" content="David Gay, Phil Levis, Wei Hong, Joe Polastre, and Gilman Tolle" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.10: http://docutils.sourceforge.net/" />
<title>Sensors and Sensor Boards</title>
<meta name="author" content="David Gay, Phil Levis, Wei Hong, Joe Polastre, and Gilman Tolle" />
***************
*** 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 }
--- 12,32 ----
: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.
*/
+ /* "! important" is used here to override other ``margin-top`` and
+ ``margin-bottom`` styles that are later in the stylesheet or
+ more specific. See http://www.w3.org/TR/CSS1#the-cascade */
.first {
margin-top: 0 ! important }
! .last, .with-subtitle {
margin-bottom: 0 ! important }
***************
*** 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 }
*/
--- 41,49 ----
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 }
*/
***************
*** 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,
--- 56,71 ----
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,
***************
*** 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 {
--- 75,86 ----
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 {
***************
*** 86,89 ****
--- 97,101 ----
div.footer, div.header {
+ clear: both;
font-size: smaller }
***************
*** 101,105 ****
margin-left: 1em ;
border: medium outset ;
! padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
--- 113,117 ----
margin-left: 1em ;
border: medium outset ;
! padding: 1em ;
background-color: #ffffee ;
width: 40% ;
***************
*** 128,157 ****
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 }
--- 140,165 ----
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 }
+
+ img.borderless {
+ border: 0 }
+
ol.simple, ul.simple {
margin-bottom: 1em }
***************
*** 217,225 ****
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee;
! border-color: #000000;
! border-width: thin;
! font-size: 14px
! }
span.classifier {
--- 225,229 ----
margin-left: 2em ;
margin-right: 2em ;
! background-color: #eeeeee }
span.classifier {
***************
*** 237,243 ****
white-space: nowrap }
- span.option-argument {
- font-style: italic }
-
span.pre {
white-space: pre }
--- 241,244 ----
***************
*** 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 {
--- 247,285 ----
color: red }
! span.section-subtitle {
! /* font-size relative to parent (h1..h6 element) */
! font-size: 80% }
table.citation {
! border-left: solid thin gray }
table.docinfo {
! margin: 2em 4em }
!
! table.docutils {
! margin-top: 0.5em ;
! margin-bottom: 0.5em }
table.footnote {
! border-left: solid thin black }
! 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 {
***************
*** 326,330 ****
<p>This section describes the basic organization principles for sensor
drivers in TinyOS.</p>
! <p>For background, a sensor may be attached to the microcontroller on a
TinyOS platform through a few different types of connections:</p>
<blockquote>
--- 331,335 ----
<p>This section describes the basic organization principles for sensor
drivers in TinyOS.</p>
! <p>For background, a sensor can be attached to the microcontroller on a
TinyOS platform through a few different types of connections:</p>
<blockquote>
***************
*** 337,362 ****
</ul>
</blockquote>
! <p>Physically, these connections may also be decoupled by attaching the
sensors to a <cite>sensor board</cite>, which can be removed from the TinyOS
! platform, and may fit multiple different TinyOS platforms.</p>
<p>The capabilities of a physical sensor are made available to a TinyOS
application through a <cite>sensor driver</cite>.</p>
! <p>According to the HAA <a class="citation-reference" href="#tep2" id="id1" name="id1">[TEP2]</a>, TinyOS devices should provide both
simple hardware-independent interfaces for common-case use (HIL) and
rich hardware-dependent interfaces for special-case use (HAL). Sensor
! drivers should follow this spirit as well.</p>
<p>TinyOS 2.x represents each sensor as an individual component. This
allows the compilation process to minimize the amount of code
! included. A sensor board containing multiple sensors should be
represented as a collection of components, one for each sensor,
contained within a sensor board directory.</p>
! <p>Sensors, being physical devices that may be shared, can benefit from
virtualization and arbitration. This document describes a design
! pattern for sensor virtualization that may be followed by sensor
drivers.</p>
! <p>The same physical sensor may be attached to multiple different TinyOS
platforms, through platform-dependent interconnections. The common
! logic of sensor driver should be factored into chip-dependent,
! platform-independent components, and those components should be bound
to the hardware resources on a platform by platform-dependent
components, and to the hardware resources on a sensor board by
--- 342,367 ----
</ul>
</blockquote>
! <p>Physically, these connections can also be decoupled by attaching the
sensors to a <cite>sensor board</cite>, which can be removed from the TinyOS
! platform, and could attach to multiple different TinyOS platforms.</p>
<p>The capabilities of a physical sensor are made available to a TinyOS
application through a <cite>sensor driver</cite>.</p>
! <p>According to the HAA <a class="citation-reference" href="#tep2" id="id1" name="id1">[TEP2]</a>, TinyOS devices SHOULD provide both
simple hardware-independent interfaces for common-case use (HIL) and
rich hardware-dependent interfaces for special-case use (HAL). Sensor
! drivers SHOULD follow this spirit as well.</p>
<p>TinyOS 2.x represents each sensor as an individual component. This
allows the compilation process to minimize the amount of code
! included. A sensor board containing multiple sensors SHOULD be
represented as a collection of components, one for each sensor,
contained within a sensor board directory.</p>
! <p>Sensors, being physical devices that can be shared, can benefit from
virtualization and arbitration. This document describes a design
! pattern for sensor virtualization that SHOULD be followed by sensor
drivers.</p>
! <p>The same physical sensor can be attached to multiple different TinyOS
platforms, through platform-dependent interconnections. The common
! logic of sensor driver SHOULD be factored into chip-dependent,
! platform-independent components, and those components SHOULD be bound
to the hardware resources on a platform by platform-dependent
components, and to the hardware resources on a sensor board by
***************
*** 364,376 ****
<p>A physical sensor has a general class and a specific set of
performance characteristics, captured by the make and model of the
! sensor itself. The naming of the sensor driver components should
! reflect the specifc name of the sensor, and optionally provide a
! component with a generic name for application authors who only care
! about the general class of the sensor.</p>
<p>This document takes no position on the meaning of the values returned
! by sensor drivers. They may be raw uninterpreted values or they may
have some physical meaning. If a driver returns uninterpreted values,
! the driver may provide additional interfaces that would allow
! higher-level clients to interpret the value properly.</p>
</div>
<div class="section">
--- 369,382 ----
<p>A physical sensor has a general class and a specific set of
performance characteristics, captured by the make and model of the
! sensor itself. The naming of the sensor driver components SHOULD
! reflect the specifc name of the sensor, and MAY provide a component
! with a generic name for application authors who only care about the
! general class of the sensor.</p>
<p>This document takes no position on the meaning of the values returned
! by sensor drivers. They MAY be raw uninterpreted values or they MAY
have some physical meaning. If a driver returns uninterpreted values,
! the driver MAY provide additional interfaces that would allow
! higher-level clients to obtain information needed to properly
! interpret the value.</p>
</div>
<div class="section">
***************
*** 389,395 ****
virtualization for itself by defining a nesC generic client
component. When a client component is being used, a call to a
! top-level SID interface should be delayed when the device is busy,
! rather than failing. This virtualization may be easier to accomplish
! by using one of the arbiters provided by the system.</p>
<p>For example:</p>
<pre class="literal-block">
--- 395,401 ----
virtualization for itself by defining a nesC generic client
component. When a client component is being used, a call to a
! top-level SID interface SHOULD be delayed when the device is busy,
! rather than failing. Using one of the system arbiters can make the
! implementation of this requirement easier to accomplish.</p>
<p>For example:</p>
<pre class="literal-block">
***************
*** 397,402 ****
--- 403,411 ----
provides interface Read<uint16_t> as Temperature;
provides interface ReadStream<uint16_t> as TemperatureStream;
+ provides interface DeviceMetadata as TemperatureDeviceMetadata;
+
provides interface Read<uint16_t> as Humidity;
provides interface ReadStream<uint16_t> as HumidityStream;
+ provides interface DeviceMetadata as HumidityDeviceMetadata;
}
implementation {
***************
*** 413,422 ****
interface. Sensors that draw appreciable power MUST be started in
response to a call to one of the top-level SID interfaces, and stopped
! some time after that call completes. One of the power-management
! components described in <a class="citation-reference" href="#tep115" id="id4" name="id4">[TEP115]</a> may be useful for this purpose.</p>
<p>Generally, simple types are made up of octets. However, sensor values
! often have levels of precision besides a multiple of 8. A device MAY
! specify the precision of one of its interfaces with the DeviceMetadata
! interface:</p>
<pre class="literal-block">
interface DeviceMetadata {
--- 422,431 ----
interface. Sensors that draw appreciable power MUST be started in
response to a call to one of the top-level SID interfaces, and stopped
! some time after that call completes. Using one of the power-management
! components described in <a class="citation-reference" href="#tep115" id="id4" name="id4">[TEP115]</a> can make this implementation easier.</p>
<p>Generally, simple types are made up of octets. However, sensor values
! often have levels of precision besides a multiple of 8. To account for
! such cases, each device MUST specify the precision of each one of its
! interfaces by providing the DeviceMetadata interface:</p>
<pre class="literal-block">
interface DeviceMetadata {
***************
*** 424,440 ****
}
</pre>
! <p>The name of the instance of DeviceMetadata SHOULD clearly indicate
! which interface it corresponds to.</p>
! <p>A value contained returned from the device through a SID interface
! MAY be left shifted so that it covers as much of the type's range as
! possible. For example, if a 12-bit ADC reading is presented as a
! 16-bit Read interface:</p>
! <pre class="literal-block">
! component DemoSensorC {
! provides interface Read<uint16_t>;
! }
! </pre>
! <p>then the driver MAY shift the 12-bit value left so that its range is
! 0x0000 - 0xfff0, rather than 0x0000 - 0x0fff.</p>
<p>Sensor driver components SHOULD be named according to the make and
model of the sensing device being presented. Using specific names
--- 433,441 ----
}
</pre>
! <p>The name of the instance of DeviceMetadata MUST clearly indicate which
! interface it corresponds to.</p>
! <p>The getSignificantBits() call MUST return the number of significant
! bits in the reading. For example, a sensor reading taken from a 12-bit
! ADC MUST return the value "12".</p>
<p>Sensor driver components SHOULD be named according to the make and
model of the sensing device being presented. Using specific names
***************
*** 445,453 ****
the particular type of the sensor and not its make, model, or detailed
performance characteristics.</p>
! <p>A "common" naming layer atop a HIL may look like this:</p>
<pre class="literal-block">
generic configuration TemperatureC() {
provides interface Read<uint16_t>;
provides interface ReadStream<uint16_t>;
}
implementation {
--- 446,455 ----
the particular type of the sensor and not its make, model, or detailed
performance characteristics.</p>
! <p>A "common" naming layer atop a HIL might look like this:</p>
<pre class="literal-block">
generic configuration TemperatureC() {
provides interface Read<uint16_t>;
provides interface ReadStream<uint16_t>;
+ provides interface DeviceMetadata;
}
implementation {
***************
*** 455,458 ****
--- 457,461 ----
Read = SensirionSht11C.Temperature;
ReadStream = SensirionSht11C.TemperatureStream;
+ DeviceMetadata = SensirionSht11C.TemperatureDeviceMetadata;
}
***************
*** 460,463 ****
--- 463,467 ----
provides interface Read<uint16_t>;
provides interface ReadStream<uint16_t>;
+ provides interface DeviceMetadata;
}
implementation {
***************
*** 465,468 ****
--- 469,473 ----
Read = SensirionSht11C.Humidity;
ReadStream = SensirionSht11C.HumidityStream;
+ DeviceMetadata = SensirionSht11C.HumidityDeviceMetadata;
}
</pre>
***************
*** 500,505 ****
<div class="section">
<h1><a id="directory-organization-guidelines" name="directory-organization-guidelines">4. Directory Organization Guidelines</a></h1>
! <p>Because the same physical sensor may be attached to TinyOS platforms
! in many different ways, the organization of sensor drivers should
reflect the distinction between sensor and sensor interconnect.</p>
<p>Sensor components commonly exist at three levels:
--- 505,510 ----
<div class="section">
<h1><a id="directory-organization-guidelines" name="directory-organization-guidelines">4. Directory Organization Guidelines</a></h1>
! <p>Because the same physical sensor can be attached to TinyOS platforms
! in many different ways, the organization of sensor drivers SHOULD
reflect the distinction between sensor and sensor interconnect.</p>
<p>Sensor components commonly exist at three levels:
***************
*** 539,543 ****
subdirectories.</li>
<li>@commonboards: This can be set to a list of sensor board names which
! should be added to the include path list. These sensor boards must be
in tinyos-2.x/tos/sensorboards.</li>
</ul>
--- 544,548 ----
subdirectories.</li>
<li>@commonboards: This can be set to a list of sensor board names which
! will be added to the include path list. These sensor boards MUST be
in tinyos-2.x/tos/sensorboards.</li>
</ul>
***************
*** 549,553 ****
If a "chips" subdirectory is used, sensorboard-dependent driver
components needed to connect platform-independent logic to a
! particular attachment for that sensor should be placed in
"<sensorboard>/chips/<sensor>".</p>
<p>Components needed to connect the platform-independent sensor driver
--- 554,558 ----
If a "chips" subdirectory is used, sensorboard-dependent driver
components needed to connect platform-independent logic to a
! particular attachment for that sensor SHOULD be placed in
"<sensorboard>/chips/<sensor>".</p>
<p>Components needed to connect the platform-independent sensor driver
***************
*** 555,559 ****
resources available on a particular platform SHOULD be placed in
"tos/<platform>/chips/<sensor>". In addition, components for a sensor
! that only exists on a particular platform should be placed in a such a
directory.</p>
<p>Sensors that exist as part of a larger chip, like a MCU internal
--- 560,564 ----
resources available on a particular platform SHOULD be placed in
"tos/<platform>/chips/<sensor>". In addition, components for a sensor
! that only exists on a particular platform SHOULD be placed in a such a
directory.</p>
<p>Sensors that exist as part of a larger chip, like a MCU internal
***************
*** 565,569 ****
<p>All of these directory organization guidelines are only intended for
code that will enter the core source tree. In general, sensor
! components may be placed anywhere as long as the nesC compiler
receives enough <cite>-I</cite> directives to locate all of the necessary pieces.</p>
</div>
--- 570,574 ----
<p>All of these directory organization guidelines are only intended for
code that will enter the core source tree. In general, sensor
! components can be placed anywhere as long as the nesC compiler
receives enough <cite>-I</cite> directives to locate all of the necessary pieces.</p>
</div>
***************
*** 652,655 ****
--- 657,661 ----
provides interface Read<uint16_t>;
provides interface ReadStream<uint16_t>;
+ provides interface DeviceMetadata;
}
implementation {
***************
*** 661,666 ****
components HamamatsuS1087ParP;
! AdcReadClientC.Msp430Adc12Config -> HamamatsuS1087ParP;
! AdcReadStreamClientC.Msp430Adc12Config -> HamamatsuS1087ParP;
}
</pre>
--- 667,673 ----
components HamamatsuS1087ParP;
! DeviceMetadata = HamamatsuS1087ParP;
! AdcReadClientC.AdcConfigure -> HamamatsuS1087ParP;
! AdcReadStreamClientC.AdcConfigure -> HamamatsuS1087ParP;
}
</pre>
***************
*** 668,692 ****
tos/platforms/telosa/chips/s1087/HamamatsuS1087ParP.nc
module HamamatsuS1087ParP {
! provides interface Msp430Adc12Config;
}
implementation {
! async command msp430adc12_channel_config_t
! Msp430Adc12Config.getChannelSettings() {
!
! msp430adc12_channel_config_t config = {
! inch: INPUT_CHANNEL_A4,
! sref: REFERENCE_VREFplus_AVss,
! ref2_5v: REFVOLT_LEVEL_1_5,
! adc12ssel: SHT_SOURCE_ACLK,
! adc12div: SHT_CLOCK_DIV_1,
! sht: SAMPLE_HOLD_4_CYCLES,
! sampcon_ssel: SAMPCON_SOURCE_SMCLK,
! sampcon_id: SAMPCON_CLOCK_DIV_1
! };
! return config;
}
}
</pre>
--- 675,702 ----
tos/platforms/telosa/chips/s1087/HamamatsuS1087ParP.nc
+ #include "Msp430Adc12.h"
+
module HamamatsuS1087ParP {
! provides interface AdcConfigure<const msp430adc12_channel_config_t*>;
! provides interface DeviceMetadata;
}
implementation {
! msp430adc12_channel_config_t config = {
! inch: INPUT_CHANNEL_A4,
! sref: REFERENCE_VREFplus_AVss,
! ref2_5v: REFVOLT_LEVEL_1_5,
! adc12ssel: SHT_SOURCE_ACLK,
! adc12div: SHT_CLOCK_DIV_1,
! sht: SAMPLE_HOLD_4_CYCLES,
! sampcon_ssel: SAMPCON_SOURCE_SMCLK,
! sampcon_id: SAMPCON_CLOCK_DIV_1
! };
! async command const msp430adc12_channel_config_t* AdcConfigure.getConfiguration() {
! return &config;
}
+
+ command uint8_t DeviceMetadata.getSignificantBits() { return 12; }
}
</pre>
***************
*** 710,724 ****
provides interface Get<bool>;
provides interface Notify<bool>;
}
implementation {
components UserButtonLogicP;
components HplUserButtonC;
UserButtonLogicP.GpioInterrupt -> HplUserButtonC.GpioInterrupt;
UserButtonLogicP.GeneralIO -> HplUserButtonC.GeneralIO;
-
- Get = UserButtonLogicP;
- Notify = UserButtonLogicP;
}
</pre>
--- 720,735 ----
provides interface Get<bool>;
provides interface Notify<bool>;
+ provides interface DeviceMetadata;
}
implementation {
components UserButtonLogicP;
+ Get = UserButtonLogicP;
+ Notify = UserButtonLogicP;
+ DeviceMetadata = UserButtonLogicP;
components HplUserButtonC;
UserButtonLogicP.GpioInterrupt -> HplUserButtonC.GpioInterrupt;
UserButtonLogicP.GeneralIO -> HplUserButtonC.GeneralIO;
}
</pre>
***************
*** 729,735 ****
provides interface Get<bool>;
provides interface Notify<bool>;
uses interface GeneralIO;
! uses interface GpioInterrupt;
}
implementation {
--- 740,747 ----
provides interface Get<bool>;
provides interface Notify<bool>;
+ provides interface DeviceMetadata;
uses interface GeneralIO;
! uses interface GpioInterrupt;
}
implementation {
***************
*** 767,773 ****
bool pinHigh;
pinHigh = m_pinHigh;
!
signal Notify.notify( pinHigh );
!
if ( pinHigh ) {
call GpioInterrupt.enableFallingEdge();
--- 779,785 ----
bool pinHigh;
pinHigh = m_pinHigh;
!
signal Notify.notify( pinHigh );
!
if ( pinHigh ) {
call GpioInterrupt.enableFallingEdge();
***************
*** 776,779 ****
--- 788,793 ----
}
}
+
+ command uint8_t DeviceMetadata.getSignificantBits() { return 1; }
}
</pre>
***************
*** 825,831 ****
tos/platforms/telosa/chips/sht11/SensirionSht11C.nc
! generic configuration SensirionSht11C() {
provides interface Read<uint16_t> as Temperature;
provides interface Read<uint16_t> as Humidity;
}
implementation {
--- 839,847 ----
tos/platforms/telosa/chips/sht11/SensirionSht11C.nc
! generic configuration SensirionSht11C() {
provides interface Read<uint16_t> as Temperature;
+ provides interface DeviceMetadata as TemperatureDeviceMetadata;
provides interface Read<uint16_t> as Humidity;
+ provides interface DeviceMetadata as HumidityDeviceMetadata;
}
implementation {
***************
*** 833,837 ****
--- 849,855 ----
Temperature = SensirionSht11ReaderP.Temperature;
+ TemperatureDeviceMetadata = SensirionSht11ReaderP.TemperatureDeviceMetadata;
Humidity = SensirionSht11ReaderP.Humidity;
+ HumidityDeviceMetadata = SensirionSht11ReaderP.HumidityDeviceMetadata;
components HalSensirionSht11C;
***************
*** 851,856 ****
generic module SensirionSht11ReaderP() {
provides interface Read<uint16_t> as Temperature;
provides interface Read<uint16_t> as Humidity;
!
uses interface Resource as TempResource;
uses interface Resource as HumResource;
--- 869,876 ----
generic module SensirionSht11ReaderP() {
provides interface Read<uint16_t> as Temperature;
+ provides interface DeviceMetadata as TemperatureDeviceMetadata;
provides interface Read<uint16_t> as Humidity;
! provides interface DeviceMetadata as HumidityDeviceMetadata;
!
uses interface Resource as TempResource;
uses interface Resource as HumResource;
***************
*** 877,880 ****
--- 897,902 ----
}
+ command uint8_t TemperatureDeviceMetadata.getSignificantBits() { return 14; }
+
command error_t Humidity.read() {
call HumResource.request();
***************
*** 895,898 ****
--- 917,922 ----
}
+ command uint8_t HumidityDeviceMetadata.getSignificantBits() { return 12; }
+
event void Sht11Temp.resetDone( error_t result ) { }
event void Sht11Temp.measureHumidityDone( error_t result, uint16_t val ) { }
***************
*** 925,929 ****
SensirionSht11LogicP.CLOCK -> HplSensirionSht11C.SCK;
SensirionSht11LogicP.InterruptDATA -> HplSensirionSht11C.InterruptDATA;
!
components new TimerMilliC();
SensirionSht11LogicP.Timer -> TimerMilliC;
--- 949,953 ----
SensirionSht11LogicP.CLOCK -> HplSensirionSht11C.SCK;
SensirionSht11LogicP.InterruptDATA -> HplSensirionSht11C.InterruptDATA;
!
components new TimerMilliC();
SensirionSht11LogicP.Timer -> TimerMilliC;
***************
*** 964,968 ****
implementation {
components HplMsp430GeneralIOC;
!
components new Msp430GpioC() as DATAM;
DATAM -> HplMsp430GeneralIOC.Port15;
--- 988,992 ----
implementation {
components HplMsp430GeneralIOC;
!
components new Msp430GpioC() as DATAM;
DATAM -> HplMsp430GeneralIOC.Port15;
***************
*** 991,995 ****
components new FcfsArbiterC( "Sht11.Resource" ) as Arbiter;
Resource = Arbiter;
!
components new SplitControlPowerManagerC();
SplitControlPowerManagerC.SplitControl -> HplSensirionSht11P;
--- 1015,1019 ----
components new FcfsArbiterC( "Sht11.Resource" ) as Arbiter;
Resource = Arbiter;
!
components new SplitControlPowerManagerC();
SplitControlPowerManagerC.SplitControl -> HplSensirionSht11P;
***************
*** 1018,1022 ****
return SUCCESS;
}
!
event void Timer.fired() {
signal SplitControl.startDone( SUCCESS );
--- 1042,1046 ----
return SUCCESS;
}
!
event void Timer.fired() {
signal SplitControl.startDone( SUCCESS );
More information about the Tinyos-2-commits
mailing list