[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep101.txt, 1.11, 1.12
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/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12563/beta/teps/txt
Modified Files:
tep101.txt
Log Message:
Polished once more so it can be made public to ask for general feedback.
Index: tep101.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep101.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** tep101.txt 8 Jun 2005 22:50:18 -0000 1.11
--- tep101.txt 6 Jul 2005 03:43:57 -0000 1.12
***************
*** 41,54 ****
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 [tep109]_.
TinyOS platforms are based on many different hardware chips, whose
--- 41,55 ----
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 [tep109]_.
TinyOS platforms are based on many different hardware chips, whose
***************
*** 110,117 ****
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.
--- 111,118 ----
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.
***************
*** 131,136 ****
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.::
--- 132,137 ----
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.::
***************
*** 165,170 ****
| ADCC |
HAL2: | (MSP430 specific | location: tinyos-2.x/tos/chips/msp430
! | implementation and |
! | representation) |
+---------------------+
^
--- 166,170 ----
| ADCC |
HAL2: | (MSP430 specific | location: tinyos-2.x/tos/chips/msp430
! | implementation) |
+---------------------+
^
***************
*** 198,202 ****
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:
--- 198,202 ----
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:
***************
*** 282,287 ****
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.
--- 282,287 ----
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.
***************
*** 321,326 ****
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
--- 321,326 ----
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
***************
*** 354,358 ****
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;
--- 354,357 ----
***************
*** 387,392 ****
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)::
configuration HALADCC
--- 386,391 ----
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)::
configuration HALADCC
***************
*** 412,416 ****
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.
--- 411,415 ----
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.
***************
*** 435,439 ****
interface AcquireData[uint8_t port];
interface AcquireDataNow[uint8_t port];
! interface AcquireDataBuffered[uint8_t port];
}
} implementation {
--- 434,438 ----
interface AcquireData[uint8_t port];
interface AcquireDataNow[uint8_t port];
! interface AcquireDataBuffered[uint8_t port]; } }
}
} implementation {
***************
*** 441,453 ****
}
! 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.
!
b. Implementation: Chip dependent
--- 440,453 ----
}
! 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 *dataReady* 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.
!
b. Implementation: Chip dependent
***************
*** 504,512 ****
}
! ADCM MAY signal the *getConfigurationData()* 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.
ii. For the ADC on the ATmega128 in the current implementation
--- 504,510 ----
}
! ADCM will signal the *getConfigurationData()* event for channels
0-7 and MSP430ADC12ChannelConfigM MUST return the corresponding
! configuration data for the platform or sensorboard.
ii. For the ADC on the ATmega128 in the current implementation
***************
*** 540,546 ****
====================================================================
! 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.
4. Author's Address
--- 538,547 ----
====================================================================
! 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.
4. Author's Address
More information about the Tinyos-beta-commits
mailing list