[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep101.html, 1.1.2.10,
1.1.2.11
Jan-Hinrich Hauer
janhauer at users.sourceforge.net
Fri Jul 14 10:01:17 PDT 2006
- Previous message: [Tinyos-2-commits] CVS: tinyos-2.x/tos/sensorboards/im2sb
LIS3L02DQInternalC.nc, 1.1.2.1, 1.1.2.2 LIS3L02DQInternalP.nc,
1.1.2.1, 1.1.2.2 MAX136xInternalC.nc, 1.1.2.1,
1.1.2.2 SensirionSht11C.nc, 1.1.2.1,
1.1.2.2 TMP175InternalC.nc, 1.1.2.1,
1.1.2.2 Tsl2561InternalC.nc, 1.1.2.1, 1.1.2.2
- Next message: [Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep101.txt, 1.1.2.6,
1.1.2.7
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv13783/doc/html
Modified Files:
Tag: tinyos-2_0_devel-BRANCH
tep101.html
Log Message:
Integrated the changes discussed during the last working group telephone conference:
- removed remarks about how the Resource interface must be used (instead included a reference to TEP108)
- made section 3 (HAL1 requirements) less restrictive (SHOULD => should, inserted a recommendation for the round robin arbiter)
- added missing link in Introduction to point to section 6 (Implementation)
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep101.html,v
retrieving revision 1.1.2.10
retrieving revision 1.1.2.11
diff -C2 -d -r1.1.2.10 -r1.1.2.11
*** tep101.html 27 Jun 2006 20:23:04 -0000 1.1.2.10
--- tep101.html 14 Jul 2006 17:01:14 -0000 1.1.2.11
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Analog-to-Digital Converters (ADCs)</title>
<meta name="author" content="Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.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" />
***************
*** 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
--- 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
***************
*** 327,334 ****
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
number. The interested reader can refer to Appendix A for a brief overview of
the ADC hardware on some current TinyOS platforms. In earlier versions of
--- 327,334 ----
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 binary
number. The interested reader can refer to Appendix A for a brief overview of
the ADC hardware on some current TinyOS platforms. In earlier versions of
***************
*** 379,392 ****
<li>the set of platform-independent interfaces for the collection of ADC
conversion results (<a class="reference" href="#interfaces">2. Interfaces</a>)</li>
! <li>guidelines on how an ADC's HAL SHOULD should be split into HAL1 and HAL2 and
! how the HAL1 SHOULD expose chip-specific interfaces (<a class="reference" href="#hal1-guidelines">3. HAL1 guidelines</a>)</li>
<li>what components an ADC's HAL2 MUST implement (<a class="reference" href="#hal2-requirements">4. HAL2 requirements</a>)</li>
<li>guidelines on how the HAL2 may be structured (<a class="reference" href="#hal2-implementation-guidelines">5. HAL2 implementation guidelines</a>)</li>
</ul>
<p>This TEP ends with appendices documenting, as an example, the ADC
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
--- 379,393 ----
<li>the set of platform-independent interfaces for the collection of ADC
conversion results (<a class="reference" href="#interfaces">2. Interfaces</a>)</li>
! <li>guidelines on how an ADC's HAL should be split into HAL1 and HAL2 and
! how the HAL1 should expose chip-specific interfaces (<a class="reference" href="#hal1-guidelines">3. HAL1 guidelines</a>)</li>
<li>what components an ADC's HAL2 MUST implement (<a class="reference" href="#hal2-requirements">4. HAL2 requirements</a>)</li>
<li>guidelines on how the HAL2 may be structured (<a class="reference" href="#hal2-implementation-guidelines">5. HAL2 implementation guidelines</a>)</li>
+ <li>a section pointing to the current implementation (<a class="reference" href="#implementation">6. Implementation</a>)</li>
</ul>
<p>This TEP ends with appendices documenting, as an example, the ADC
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
***************
*** 406,427 ****
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
channel immediately (the request is not buffered). Due to its timing
constraints the ReadNow interface is always provided in conjunction with an
! instance of the Resource interface. A client MUST request access to the ADC
! via the Resource interface before it can call ReadNow.read() and it MUST
! 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
--- 407,427 ----
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
channel immediately (the request is not buffered). Due to its timing
constraints the ReadNow interface is always provided in conjunction with an
! instance of the Resource interface. Refer to <a class="citation-reference" href="#tep108" id="id8" name="id8">[TEP108]</a> on how the 'Resource'
! interface should be used by a client component.</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
***************
*** 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
--- 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
***************
*** 438,474 ****
HAA <a class="citation-reference" href="#tep2" id="id9" name="id9">[TEP2]</a>. Therefore only chip- and platform-dependent clients MAY wire to
the HAL1. Although the HAL1 is chip-specific, both, in terms of implementation
! and representation, its design SHOULD follow the guidelines described below to
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
! component SHOULD provide a parameterized 'Resource' interface, instantiate a
generic arbiter component and connect the 'Resource' interface to the arbiter
! as described in <a class="citation-reference" href="#tep108" id="id10" name="id10">[TEP108]</a>. To provide a uniform arbitration service for all
! platforms on the level of HAL2 (see <a class="reference" href="#hal2-requirements">4. HAL2 requirements</a>), all ADCs should
! be arbitrated in round robin fashion, i.e. the HAL1 SHOULD instantiate the
! standard round robin arbiter. On the level of HAL1 a client MUST have
! successfully requested access to the ADC via the 'Resource' interface before
! it can configure / sample a channel. After use it MUST release the ADC via the
! '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
configuration is possible, it is not recommended, because it forces all
! clients to use the same settings for a given port). Therefore an HAL1 SHOULD
! provide "sampling interfaces" parameterized by a client identifier. An HAL1
client can use its instance of the sampling interface to configure the ADC
hardware, start the sampling process and get conversion results. It wires to a
sampling interface using a unique client identifier. All commands and events
! in the sampling interface SHOULD be 'async' to reflect the potential timing
! requirements of clients. An HAL1 MAY provide multiple different parameterized
sampling interfaces, depending on the hardware capabilities. This allows to
differentiate/group ADC functionality, for example single vs. repeated
sampling, single channel vs. multiple channels or low-frequency vs.
! high-frequency sampling. Every sampling interface SHOULD allow the client to
individually configure the ADC hardware, for example by including the
configuration data as parameters in the sampling commands. However, if
--- 438,470 ----
HAA <a class="citation-reference" href="#tep2" id="id9" name="id9">[TEP2]</a>. Therefore only chip- and platform-dependent clients MAY wire to
the HAL1. Although the HAL1 is chip-specific, both, in terms of implementation
! and representation, its design should follow the guidelines described below to
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
! component should provide a parameterized 'Resource' interface, instantiate a
generic arbiter component and connect the 'Resource' interface to the arbiter
! as described in <a class="citation-reference" href="#tep108" id="id10" name="id10">[TEP108]</a>. To ensure fair and uniform arbitration on all
! platforms the standard round robin arbiter is recommended. Refer to <a class="citation-reference" href="#tep108" id="id11" name="id11">[TEP108]</a>
! on how the 'Resource' interface is to be used by a client wiring to HAL1.</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
configuration is possible, it is not recommended, because it forces all
! clients to use the same settings for a given port). Therefore an HAL1 should
! provide sampling interfaces parameterized by a client identifier. An HAL1
client can use its instance of the sampling interface to configure the ADC
hardware, start the sampling process and get conversion results. It wires to a
sampling interface using a unique client identifier. All commands and events
! in the sampling interface should be 'async' to reflect the potential timing
! requirements of clients. An HAL1 may provide multiple different parameterized
sampling interfaces, depending on the hardware capabilities. This allows to
differentiate/group ADC functionality, for example single vs. repeated
sampling, single channel vs. multiple channels or low-frequency vs.
! high-frequency sampling. Every sampling interface should allow the client to
individually configure the ADC hardware, for example by including the
configuration data as parameters in the sampling commands. However, if
***************
*** 477,494 ****
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
to be instantiated by chip- and platform-dependent clients.</p>
</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
--- 473,490 ----
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
to be instantiated by chip- and platform-dependent clients.</p>
</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
***************
*** 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() {
--- 499,504 ----
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() {
***************
*** 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() {
--- 521,526 ----
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() {
***************
*** 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() {
--- 547,552 ----
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() {
***************
*** 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'
--- 571,576 ----
</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'
***************
*** 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>
--- 610,615 ----
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>
***************
*** 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>
--- 621,626 ----
<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
--- 632,636 ----
<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">
! <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>
--- 639,649 ----
<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>
***************
*** 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>
--- 655,661 ----
</colgroup>
<thead valign="bottom">
! <tr><th> </th>
! <th>Atmel Atmega 128</th>
! <th>TI MSP430 ADC12</th>
</tr>
</thead>
***************
*** 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
--- 774,779 ----
</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
***************
*** 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>
--- 786,807 ----
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">
! <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">
--- 810,815 ----
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">
***************
*** 823,827 ****
} implementation {
components AdcC;
! #ifdef REF_VOLT_AUTO_CONFIGURE
components new Msp430Adc12RefVoltAutoClientC() as Msp430AdcClient;
#else
--- 819,823 ----
} 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>
--- 835,839 ----
#ifdef REF_VOLT_AUTO_CONFIGURE
Msp430Adc12Config = Msp430AdcClient.Msp430Adc12Config;
! #endif
}
</pre>
- Previous message: [Tinyos-2-commits] CVS: tinyos-2.x/tos/sensorboards/im2sb
LIS3L02DQInternalC.nc, 1.1.2.1, 1.1.2.2 LIS3L02DQInternalP.nc,
1.1.2.1, 1.1.2.2 MAX136xInternalC.nc, 1.1.2.1,
1.1.2.2 SensirionSht11C.nc, 1.1.2.1,
1.1.2.2 TMP175InternalC.nc, 1.1.2.1,
1.1.2.2 Tsl2561InternalC.nc, 1.1.2.1, 1.1.2.2
- Next message: [Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep101.txt, 1.1.2.6,
1.1.2.7
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-2-commits
mailing list