[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/html tep101.html,
1.9, 1.10
Jan-Hinrich Hauer
janhauer at users.sourceforge.net
Tue Jul 5 20:43:59 PDT 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/html
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12563/beta/teps/html
Modified Files:
tep101.html
Log Message:
Polished once more so it can be made public to ask for general feedback.
Index: tep101.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/html/tep101.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** tep101.html 8 Jun 2005 22:50:18 -0000 1.9
--- tep101.html 6 Jul 2005 03:43:57 -0000 1.10
***************
*** 301,305 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">20-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.10</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2005-06-08</td>
--- 301,305 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">20-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.11</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2005-06-08</td>
***************
*** 332,345 ****
between a sensor and an ADC were blurred: this led components that had
nothing to do with an ADC to still resemble one programatically, even
! though the semantics and forms of operation were completely
! different. This led non-ADC sensors to introduce new interfaces, such
! as ADCError, that were tightly bound to sensor acquisition but
! separate in wiring. The separation between the ADC and ADCError
! interface is bug prone and problematic, as is the equation of a sensor
! and an ADC. TinyOS 2.x separates the structure and interfaces of an
! ADC from those of sensors (which may be on top of an ADC, but this is
! hidden from higher level components). This TEP presents how TinyOS 2.x
! decomposes and structures ADC software. TEP 109 (Sensorboards) presents how a
! platform can present actual named sensors <a class="citation-reference" href="#tep109" id="id1" name="id1">[tep109]</a>.</p>
<p>TinyOS platforms are based on many different hardware chips, whose
ADCs differ in many respects (see <a class="reference" href="#hardware-differences-between-the-current-platforms">Hardware differences between the
--- 332,346 ----
between a sensor and an ADC were blurred: this led components that had
nothing to do with an ADC to still resemble one programatically, even
! though the semantics and forms of operation were completely different.
! To compensate for the difference non-ADC sensors introduced additional
! interfaces, such as ADCError, that were tightly bound to sensor
! acquisition but separate in wiring. The separation between the ADC and
! ADCError interface is bug prone and problematic, as is the equation of
! a sensor and an ADC. TinyOS 2.x separates the structure and interfaces
! of an ADC from those of sensors (which may be on top of an ADC, but
! this is hidden from higher level components). This TEP presents how
! TinyOS 2.x decomposes and structures ADC software. TEP 109
! (Sensorboards) presents how a platform can present actual named
! sensors <a class="citation-reference" href="#tep109" id="id1" name="id1">[tep109]</a>.</p>
<p>TinyOS platforms are based on many different hardware chips, whose
ADCs differ in many respects (see <a class="reference" href="#hardware-differences-between-the-current-platforms">Hardware differences between the
***************
*** 394,401 ****
supports arbitration of its input channels therefore MUST incorporate
a layer providing these interfaces for standard arbiter components to
! use. The parameter to these parameterized interface defines the sensor
! or, more precisely, the ADC input channel. An input channel is the
! most natural representation on this level of abstraction, because a
! common denominator of all ADCs is that they sample an input channel
and produce conversion results.</p>
<p>Although HAL2 is common across many ADCs, it is <em>not</em> a HIL
--- 395,402 ----
supports arbitration of its input channels therefore MUST incorporate
a layer providing these interfaces for standard arbiter components to
! use. The parameter to these parameterized interfaces defines the
! sensor or, more precisely, the ADC input channel. An input channel is
! the most natural representation on this level of abstraction, because
! a common denominator of all ADCs is that they sample an input channel
and produce conversion results.</p>
<p>Although HAL2 is common across many ADCs, it is <em>not</em> a HIL
***************
*** 412,417 ****
lies below it.</p>
<p>An example for a component stack of a platform independent application
! wiring to a sensor wrapper on the 'eyes' platform (using the MSP430)
! is shown in the following figure.:</p>
<pre class="literal-block">
+-------------+
--- 413,418 ----
lies below it.</p>
<p>An example for a component stack of a platform independent application
! wiring to a sensor wrapper on the 'eyes' platform (using the TI MSP430
! MCU) is shown in the following figure.:</p>
<pre class="literal-block">
+-------------+
***************
*** 445,450 ****
| ADCC |
HAL2: | (MSP430 specific | location: tinyos-2.x/tos/chips/msp430
! | implementation and |
! | representation) |
+---------------------+
^
--- 446,450 ----
| ADCC |
HAL2: | (MSP430 specific | location: tinyos-2.x/tos/chips/msp430
! | implementation) |
+---------------------+
^
***************
*** 475,479 ****
very different functionality and capabilities. These distinctions
illustrate the complexities that prevent ADCs from having a truly
! hardware independent abstraction. The following table comparse the
characteristics of the two microcontrollers:</p>
<table border="1" class="docutils">
--- 475,479 ----
very different functionality and capabilities. These distinctions
illustrate the complexities that prevent ADCs from having a truly
! hardware independent abstraction. The following table compares the
characteristics of the two microcontrollers:</p>
<table border="1" class="docutils">
***************
*** 626,631 ****
AcquireDataNow interface) and HAL1 (for the 'traditional' HAL). In the
hardware stack for the ADC the HAL1 resides below HAL2, i.e. HAL2 uses
! the primitives of HAL1. Only chip dependent application may wire to
! HAL1 or HAL2 i.e. platform independent applications MUST NOT wire to
HAL1 or HAL2.</p>
<div class="section" id="hardware-adaptation-sublayer1-hal1">
--- 626,631 ----
AcquireDataNow interface) and HAL1 (for the 'traditional' HAL). In the
hardware stack for the ADC the HAL1 resides below HAL2, i.e. HAL2 uses
! the primitives of HAL1. Only chip dependent applications may wire to
! HAL1 or HAL2, i.e. platform independent applications MUST NOT wire to
HAL1 or HAL2.</p>
<div class="section" id="hardware-adaptation-sublayer1-hal1">
***************
*** 668,673 ****
operations on the ADC12, it then MUST release the ADC12 via the
Resource interface. In the meantime the ADC12 will be blocked
! for all other requests, therefore an application SHOULD
! minimize this reservation period. Every application MUST
conform to this policy. The HAL1 MAY check at runtime whether a
data request maps to the application that has reserved the ADC, but
--- 668,673 ----
operations on the ADC12, it then MUST release the ADC12 via the
Resource interface. In the meantime the ADC12 will be blocked
! for all other applications, therefore an application SHOULD
! minimize the reservation period. Every application MUST
conform to this policy. The HAL1 MAY check at runtime whether a
data request maps to the application that has reserved the ADC, but
***************
*** 700,704 ****
unsigned int sampcon_ssel: 2; // clock source sampcon signal
unsigned int sampcon_id: 2; // clock divider sampcon
- unsigned int : 0; // align to a word boundary
} msp430adc12_channel_config_t;
</pre>
--- 700,703 ----
***************
*** 730,735 ****
</ol>
<p>In the current implementation on the Atmel an ADC channel is
! exhaustively defined by the port numer, i.e. there is no bind
! mechanism (e.g. like for the MSP430):</p>
<pre class="literal-block">
configuration HALADCC
--- 729,734 ----
</ol>
<p>In the current implementation on the Atmel an ADC channel is
! exhaustively defined by the port numer, i.e. there is no
! configuration mechanism (e.g. like for the MSP430):</p>
<pre class="literal-block">
configuration HALADCC
***************
*** 755,759 ****
performed all desired operations on the ADC, it then MUST
release the ADC via the Resource interface. In the meantime
! the ADC will be blocked for all other request, therefore an
application SHOULD minimize this reservation period.</p>
</blockquote>
--- 754,758 ----
performed all desired operations on the ADC, it then MUST
release the ADC via the Resource interface. In the meantime
! the ADC will be blocked for all other applications, therefore an
application SHOULD minimize this reservation period.</p>
</blockquote>
***************
*** 782,786 ****
interface AcquireData[uint8_t port];
interface AcquireDataNow[uint8_t port];
! interface AcquireDataBuffered[uint8_t port];
}
} implementation {
--- 781,785 ----
interface AcquireData[uint8_t port];
interface AcquireDataNow[uint8_t port];
! interface AcquireDataBuffered[uint8_t port]; } }
}
} implementation {
***************
*** 788,799 ****
}
</pre>
! <p>The name of a HAL2 configuration is chip specific (it can be,
! but doesn't have to be "ADCC"). An HAL2 module will perform a
! mapping of the chip specific HAL1 interfaces to the above shown
! standard TinyOS interfaces. Note that, although the provided
! interfaces are standard TinyOS interfaces, the fact that they
! are parameterized by a port identifier makes the HAL2
! representation platform dependent. Platform independent
! applications SHOULD NOT wire to HAL2.</p>
</blockquote>
</li>
--- 787,799 ----
}
</pre>
! <p>The name of a HAL2 configuration is chip specific (it can be, but
! doesn't have to be "ADCC"). In the AcquireData, AcquireDataNow and
! AcquireDataBuffered the respective <em>dataReady</em> events return
! uninterpreted 16-bit values. An HAL2 module will perform a mapping of
! the chip specific HAL1 interfaces to the above shown standard TinyOS
! interfaces. Note that, although the provided interfaces are standard
! TinyOS interfaces, the fact that they are parameterized by a port
! identifier makes the HAL2 representation platform dependent. Platform
! independent applications SHOULD NOT wire to HAL2.</p>
</blockquote>
</li>
***************
*** 852,860 ****
}
</pre>
! <p>ADCM MAY signal the <em>getConfigurationData()</em> event for channels
0-7 and MSP430ADC12ChannelConfigM MUST return the corresponding
! configuration data for the platform or sensorboard. The event
! MAY be signalled multiple times and MSP430ADC12ChannelConfigM
! MUST always return the same configuration data.</p>
<p>ii. For the ADC on the ATmega128 in the current implementation
a port number exhaustively defines all relevant settings.</p>
--- 852,858 ----
}
</pre>
! <p>ADCM will signal the <em>getConfigurationData()</em> event for channels
0-7 and MSP430ADC12ChannelConfigM MUST return the corresponding
! configuration data for the platform or sensorboard.</p>
<p>ii. For the ADC on the ATmega128 in the current implementation
a port number exhaustively defines all relevant settings.</p>
***************
*** 887,893 ****
<div class="section" id="implementation">
<h1><a name="implementation">Implementation</a></h1>
! <p>See the tinyos-2.x/tos/ tree. Interfaces are in interfaces/ and HPL,
! HAL1 and HAL2 components in chips/. Arbitration service components are
! in lib/adc. A test application can be found at tinyos-2.x/apps/TestADC.</p>
</div>
<div class="section" id="author-s-address">
--- 885,894 ----
<div class="section" id="implementation">
<h1><a name="implementation">Implementation</a></h1>
! <p>See the tinyos-2.x/tos/ tree. Interfaces are in interfaces/
! and HPL, HAL1 and HAL2 components in chips/ , e.g.
! chips/msp430/adc12. Arbitration service components are in
! lib/adc. An example for MSP430ADC12ChannelConfigM is in
! tos/platforms/eyesIFX. A test application can be found in
! tinyos-2.x/apps/TestADC.</p>
</div>
<div class="section" id="author-s-address">
More information about the Tinyos-beta-commits
mailing list