[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep1.txt, 1.2,
1.3 tep101.txt, 1.2, 1.3 tep106.txt, 1.4, 1.5
Ion Yannopoulos
ion- at users.sourceforge.net
Tue Jan 18 14:34:27 PST 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25526/txt
Modified Files:
tep1.txt tep101.txt tep106.txt
Log Message:
Updating TEPs with 2.0 information instead of 1.2.
Index: tep1.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep1.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** tep1.txt 10 Dec 2004 21:00:47 -0000 1.2
--- tep1.txt 18 Jan 2005 22:34:00 -0000 1.3
***************
*** 12,16 ****
:Draft-Version: $Revision$
:Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-1.2WG List <tinyos at barnowl.org>
.. Note::
--- 12,16 ----
:Draft-Version: $Revision$
:Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-2.0 Working Group list <tinyos-2.0wg at mail.millenium.berkeley.edu>
.. Note::
Index: tep101.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep101.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** tep101.txt 10 Jan 2005 11:46:14 -0000 1.2
--- tep101.txt 18 Jan 2005 22:34:03 -0000 1.3
***************
*** 1,383 ****
! ===================================
! ADCs (analog-to-digital converters)
! ===================================
! :TEP: 101
! :Group: Core Working Group
! :Type: Documentary
! :Status: Draft
! :TinyOS-Version: 1.2
! :Author: Jan-Hinrich Hauer, Vlado Handziski, Joe Polastre, Lama Nachman
!
! :Draft-Created: 20-Dec-2004
! :Draft-Version: $Revision$
! :Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-1.2WG List <tinyos at barnowl.org>
!
! .. Note::
!
! This memo documents a part of TinyOS for the TinyOS Community, and
! requests discussion and suggestions for improvements. Distribution
! of this memo is unlimited. This memo is in full compliance with
! TEP 1.
!
!
! Abstract
! ====================================================================
!
! This TEP proposes a new hardware abstraction for the analog-to-digital
! converters (ADCs) in TinyOS 1.2. It focuses on aligning the ADC
! abstraction with the three-layer Hardware Abstraction Architecture
! (HAA).
!
! 1. Introduction
! ====================================================================
!
! Internal ADCs
! -------------
!
! There are two different internal ADCs in use for the TinyOS platforms:
! The internal ADC of the Atmel Atmega 128 and the ADC12 of TI MSP430.
! Their characteristics are compared in the following table:
!
! +----------------------+----------------------+---------------------+
! | | Atmel Atmega 128 | TI MSP430 ADC12 |
! +======================+======================+=====================+
! |Resolution | 10-bit | 12-bit |
! +----------------------+----------------------+---------------------+
! |channels |- 8 multiplexed |- 8 individually |
! | | external channels | configurable |
! | |- 16 differential | external channels |
! | | voltage input |- internal channels |
! | | combinations | (AVcc, temperature,|
! | |- 2 differential | reference voltages)|
! | | inputs with gain | |
! | | amplification | |
! +----------------------+----------------------+---------------------+
! |internal reference | 2.56V | 1.5V or 2.5V |
! |voltage | | |
! +----------------------+----------------------+---------------------+
! |conversion reference |- positive terminal: | individually |
! | | AVcc or 2.56V or | selectable per |
! | | AREF (external) | channel: |
! | |- negative terminal: | |
! | | GND |- AVcc and AVss |
! | | |- Vref+ and AVss |
! | | |- Veref+ and AVss |
! | | |- AVcc and (Vref- or |
! | | | Veref-) |
! | | |- AVref+ and (Vref- |
! | | | or Veref-) |
! | | |- Veref+ and (Vref- |
! | | | or Veref-) |
! +----------------------+----------------------+---------------------+
! |conversion modes |- single channel |- single conversion |
! | | conversion mode | mode |
! | |- free running mode |- repeat single |
! | | (repeated single | conversion mode |
! | | channel conversion) |- sequence mode |
! | | | (sequence <= 16 |
! | | | channels) |
! | | |- repeat sequence |
! | | | mode |
! +----------------------+----------------------+---------------------+
! |conversion clock |clkADC with prescaler |ACLK, MCLK, SMCLK or |
! |source | |ADC-oscillator (5MHz)|
! | | |with prescaler |
! | | |respectively |
! +----------------------+----------------------+---------------------+
! |sample-hold-time |1.5 clock cycles |selectable values |
! | |(fixed) |from 4 to 1024 clock |
! | | |cycles |
! +----------------------+----------------------+---------------------+
! |conversion triggering |by software |by software or timers|
! +----------------------+----------------------+---------------------+
! |conversion during |yes |yes |
! |sleep mode possible | | |
! +----------------------+----------------------+---------------------+
! |interrupts |after each conversion |after single or |
! | | |sequence conversion |
! +----------------------+----------------------+---------------------+
!
!
! External ADCs
! -------------
!
! In addition to the above internal ADCs, some of the TinyOS platforms
! use dedicated ADCs like ADS1242, ADS7828, ADS1251, ADS8345, ADS8325,
! ADS1100 (all by TI). They differ in resolution (12-bit to 24 -bit),
! interfaces (SPI, I2C), channel numbers (1 to 8), reference voltages
! and conversion rates. Implementation of the three layers of the HAA
! will be considerably different from internal ADCs, as issues like bus
! arbitration or communication errors have to be taken into
! consideration. Although the particular implementation will vary
! according to chip and platform, each HIL (`Hardware Interface Layer
! (HIL)`_) will export the standard *ADCSingle* and *ADCMultiple*
! interface, providing a uniform application-level OS service. External
! ADCs will influence the HIL interfaces and the layering in the
! following ways:
!
! - An additional command *reserveADC* will be included in the
! HIL interfaces. This command will guarantee a minimum
! delay between the next invocation of *getData* and the actual
! sampling of the channel.
! - The HIL will provide a mechanism to signal an error that
! occurred during the sampling process.
! - A more general architectural issue is how to structure the
! communication between the HPL of the external ADC and the HPL
! of the particular bus implementation.
! We propose to deal with bus arbitration and related tasks
! on the level of the HALs. I.e. the HAL\_ADC module will wire to
! e.g. HAL\_SPI module to perform bus arbitration while HPL\_ADC
! will wire to HPL\_SPI. HPL\_ADC is unaware of bus arbitration
! and will always assume to be owner of the bus. This ensures
! that
!
! - The HPL can be kept stateless.
! - The HAL is capable of deciding how long to maintain a certain
! state in bus arbitration. If there is, for example, a request
! for a continuous or sequence conversion the HAL could refrain
! from releasing the bus after each single conversion.
!
!
! 2. Architecture
! ====================================================================
!
! The proposed architecture aligns with the three-layer Hardware
! Abstraction Architecture (HAA).
!
! Hardware Presentation Layer (HPL)
! ---------------------------------
!
! a. Implementation: chip/platform dependent
! b. Presentation: chip dependent
! c. Stateless
! d. General structure:
!
! i. StdControl (init, start, stop) for power management to work
! ii. get/set commands for the registers that control the hardware
! iii. additional commands for the frequently used operations
! iv. commands for enabling/disabling of interrupts
! v. service routines for the ADC interrupt
!
! e. The HPL for an external ADC SHOULD follow the general structure
! described above by wiring to the respective hardware module's HPL
! to access the bus and relevant pins (see `External ADCs`_).
!
! Hardware Adaptation Layer (HAL)
! -------------------------------
!
! For the HAL presentation, the idea of binding an interface to ADC
! settings is extended. This mechanism was introduced in the
! ``ADCControl`` interface, but was only applied to channels. Instead of
! only binding to a channel, all settings supported by the interface
! SHOULD be passed to a ``bind`` commandhandler once at initialization.
! For all subsequent calls on the interface instance these settings are
! then valid.
!
! a. Implementation: chip/platform dependent
! b. Presentation: chip dependent
! c. MSP430:
!
! To offload the interfaces, the four supported conversion modes of the
! MSP430 are separated into two separate interfaces: *MSP430ADC12Single* and
! *MSP430ADC12Multiple*, for single and multiple conversions,
! respectively. Both interfaces provide two commands which allow the
! conversion(s) to be performed once or repeatedly. One
! characteristic of the MSP430 ADC12 is the ability to define the
! time interval between subsequent conversions. This is reflected by
! an additional parameter *jiffies* in the relevant commands of the
! HAL interfaces.
!
! A new return datatype ``msp430ADCresult_t`` is introduced, which
! not only includes MSP430ADC12_FAIL and MSP430ADC12_SUCCESS but
! also MSP430ADC12_QUEUED to queue commands.
! This is necessary to deal with a possible 17ms delay when
! starting the internal reference voltage generator.
! HAL-configuration, interfaces and datatypes are as follows (see
! `3. Implementation`_ for where to find commented versions).::
!
! configuration MSP430ADC12C
! {
! provides interface StdControl;
! provides interface MSP430ADC12Single[uint8_t id];
! provides interface MSP430ADC12Multiple[uint8_t id];
! }
!
! interface MSP430ADC12Single
! {
! command result_t bind(MSP430ADC12Settings_t settings);
! async command msp430ADCresult_t getData();
! async command msp430ADCresult_t getDataRepeat(uint16_t jiffies);
! async command result_t reserve();
! async command result_t reserveRepeat(uint16_t jiffies);
! async command result_t unreserve();
! async event result_t dataReady(uint16_t data);
! }
!
! interface MSP430ADC12Multiple
! {
! command result_t bind( MSP430ADC12Settings_t settings);
! async command msp430ADCresult_t getData(uint16_t *buf, uint16_t length,
! uint16_t jiffies);
! async command msp430ADCresult_t getDataRepeat(uint16_t *buf, uint8_t length,
! uint16_t jiffies);
! async command result_t reserve(uint16_t *buf, uint16_t length, uint16_t jiffies);
! async command result_t reserveRepeat(uint16_t *buf, uint8_t length, uint16_t jiffies);
! async command result_t unreserve();
! async event uint16_t* dataReady(uint16_t *buf, uint16_t length);
! }
!
! typedef struct
! {
! unsigned int refVolt2_5: 1; // reference voltage level
! unsigned int clockSourceSHT: 2; // clock source sample-hold-time
! unsigned int clockSourceSAMPCON: 2; // clock source sampcon signal
! unsigned int clockDivSAMPCON: 2; // clock divider sampcon
! unsigned int referenceVoltage: 3; // reference voltage
! unsigned int clockDivSHT: 3; // clock divider sample-hold-time
! unsigned int inputChannel: 4; // input channel
! unsigned int sampleHoldTime: 4; // sample-hold-time
! } MSP430ADC12Settings_t;
!
! typedef union
! {
! uint32_t i;
! MSP430ADC12Settings_t s;
! } MSP430ADC12Settings_ut;
!
! typedef enum
! {
! MSP430ADC12_FAIL = 0,
! MSP430ADC12_SUCCESS = 1,
! MSP430ADC12_QUEUED = 2
! } msp430ADCresult_t;
!
! d. Atmega 128:
! To maintain compatibility with the existing code the
! original ADC interface will be provided with one extension,
! a *reserveADC* command.
!
! i. interface Atmega128ADC::
!
! interface Atmega128ADC
! {
! async command result_t getData();
! async command result_t getContinuousData();
! async command result_t reserveADC();
! async event result_t dataReady(uint16_t data);
! }
!
!
! ii. interface ADCControl::
!
! /* the original ADCControl interface from tos/interfaces/ */
!
! command result_t init();
! command result_t setSamplingRate(uint8_t rate);
! command result_t bindPort(uint8_t port, uint8_t adcPort);
!
! e. External ADCs:
! The HALs of external ADCs are chip and platform dependent. Their
! interfaces SHOULD be defined with regard to the HIL
! interfaces specified below. As stated above (`External ADCs`_),
! HALs for external ADCs might also have to deal with bus arbitration
! and related tasks.
!
! Hardware Interface Layer (HIL)
! ------------------------------
!
! An HIL provides application-level OS services via platform independent
! interfaces. The ADC's HIL interface should abstract from platform
! dependent settings as a platform independent application is not in a
! position to deal with platform dependent settings such as a channel
! number or sample-hold-time. In HIL a translation from a platform
! independent representation of a sensor to platform dependent settings
! for a HAL's *bind* needs to be performed. Also, the HIL is responsible
! for translating an application request to HAL primitives.
!
! The current practice of having wrappers represent sensors is
! maintained: A wrapper configuration will provide a *StdControl*, the
! *ADCSingle* and the *ADCMultiple* interface. A wrapper thus
! represents the HIL in the ADC's hardware abstraction, i.e. it sits on
! top of the native HAL component. Its task is to bind to HAL with the
! appropriate settings (typically done in StdControl.init) and to
! forward commands, possibly adding slight changes to translate them to
! the HAL interface. Since an HAL interface is designed with the HIL
! interfaces in mind wrappers will typically be fairly lightweight. An
! example configuration for a temperature sensor wrapper on the msp430
! platform would look like this::
!
! StdControl
! | ADCSingle
! | | ADCMultiple
! | | |
! +------|----|----|------------------------------------------+
! | | | | Temperature |
! | v v v |
! | +--------------------+ MSP430ADC12Single +------------+ |
! | | TemperatureM |-------------------->|MSP430ADC12C| |
! | | | MSP430ADC12Multiple | | |
! | | |-------------------->| | |
! | +--------------------+ +------------+ |
! +-----------------------------------------------------------+
!
! On the level of HIL two interfaces MUST be provided: ADCSingle and
! ADCMultiple. ADCSingle is used for single conversions (once or
! repeated) and ADCMultiple is used for multiple conversions (once or
! repeated).
!
! Both interfaces must take into account that some (e.g. external ADCs)
! may face errors during the sampling process which can lead to invalid
! results. Therefore events in the ADCSingle and ADCMultiple interfaces
! not only return the conversion result(s) but also additional error
! information contained in a new datatype adcresult_t.
!
! The returned conversion results are uninterpreted 16-bit values. Note
! that still multiple results can be combined by an application to
! create a mean or median.
!
! a. Implementation: platform dependent
! b. Presentation: application-level OS service (see
! `3. Implementation`_ for where to find the commented version).::
!
! interface ADCSingle
! {
! async command adcresult_t getData();
! async command adcresult_t getDataContinuous();
! async command adcresult_t reserve();
! async command adcresult_t reserveContinuous();
! async command adcresult_t unreserve();
! async event result_t dataReady(adcresult result, uint16_t data);
! }
!
! interface ADCMultiple
! {
! async command adcresult_t getData(uint16_t *buf, uint16_t length);
! async command adcresult_t getDataContinuous(uint16_t *buf, uint16_t length);
! async command adcresult_t reserve(uint16_t *buf, uint16_t length);
! async command adcresult_t reserveContinuous(uint16_t *buf, uint16_t length);
! async command adcresult_t unreserve();
! async event uint16_t* dataReady(adcresult result, uint16_t *buf, uint16_t length);
! }
!
!
! 3. Implementation
! ====================================================================
!
! The ADCSingle and ADCMultiple interfaces and ADCHIL.h (containing the
! definition of adcresult_t) can be found in tos/interfaces. Interfaces
! relating to msp430 are in tos/platform/msp430. The HAL implementation
! of the msp430 as well as wrappers (HIL) for internal temperature and
! internal voltage of the msp430 can also be found in
! tos/platform/msp430. A test application for the msp430 platform is
! tinyos-1.x/contrib/eyes/apps/TestADC.
!
! 4. Author's Address
! ====================================================================
!
! | Jan Hauer <hauer at tkn.tu-berlin.de>,
! | Vlado Handziski <handzisk at tkn.tu-berlin.de>,
! | Joe Polastre <polastre at cs.berkeley.edu>,
! | Lama Nachman <lama.nachman at intel.com>
!
!
--- 1,383 ----
! ===================================
! ADCs (analog-to-digital converters)
! ===================================
! :TEP: 101
! :Group: Core Working Group
! :Type: Documentary
! :Status: Draft
! :TinyOS-Version: 2.x
! :Author: Jan-Hinrich Hauer, Vlado Handziski, Joe Polastre, Lama Nachman
!
! :Draft-Created: 20-Dec-2004
! :Draft-Version: $Revision$
! :Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-2.0 Working List <tinyos-2.0wg at mail.millenium.berkeley.edu>
!
! .. Note::
!
! This memo documents a part of TinyOS for the TinyOS Community, and
! requests discussion and suggestions for improvements. Distribution
! of this memo is unlimited. This memo is in full compliance with
! TEP 1.
!
!
! Abstract
! ====================================================================
!
! This TEP proposes a new hardware abstraction for the analog-to-digital
! converters (ADCs) in TinyOS 1.2. It focuses on aligning the ADC
! abstraction with the three-layer Hardware Abstraction Architecture
! (HAA).
!
! 1. Introduction
! ====================================================================
!
! Internal ADCs
! -------------
!
! There are two different internal ADCs in use for the TinyOS platforms:
! The internal ADC of the Atmel Atmega 128 and the ADC12 of TI MSP430.
! Their characteristics are compared in the following table:
!
! +----------------------+----------------------+---------------------+
! | | Atmel Atmega 128 | TI MSP430 ADC12 |
! +======================+======================+=====================+
! |Resolution | 10-bit | 12-bit |
! +----------------------+----------------------+---------------------+
! |channels |- 8 multiplexed |- 8 individually |
! | | external channels | configurable |
! | |- 16 differential | external channels |
! | | voltage input |- internal channels |
! | | combinations | (AVcc, temperature,|
! | |- 2 differential | reference voltages)|
! | | inputs with gain | |
! | | amplification | |
! +----------------------+----------------------+---------------------+
! |internal reference | 2.56V | 1.5V or 2.5V |
! |voltage | | |
! +----------------------+----------------------+---------------------+
! |conversion reference |- positive terminal: | individually |
! | | AVcc or 2.56V or | selectable per |
! | | AREF (external) | channel: |
! | |- negative terminal: | |
! | | GND |- AVcc and AVss |
! | | |- Vref+ and AVss |
! | | |- Veref+ and AVss |
! | | |- AVcc and (Vref- or |
! | | | Veref-) |
! | | |- AVref+ and (Vref- |
! | | | or Veref-) |
! | | |- Veref+ and (Vref- |
! | | | or Veref-) |
! +----------------------+----------------------+---------------------+
! |conversion modes |- single channel |- single conversion |
! | | conversion mode | mode |
! | |- free running mode |- repeat single |
! | | (repeated single | conversion mode |
! | | channel conversion) |- sequence mode |
! | | | (sequence <= 16 |
! | | | channels) |
! | | |- repeat sequence |
! | | | mode |
! +----------------------+----------------------+---------------------+
! |conversion clock |clkADC with prescaler |ACLK, MCLK, SMCLK or |
! |source | |ADC-oscillator (5MHz)|
! | | |with prescaler |
! | | |respectively |
! +----------------------+----------------------+---------------------+
! |sample-hold-time |1.5 clock cycles |selectable values |
! | |(fixed) |from 4 to 1024 clock |
! | | |cycles |
! +----------------------+----------------------+---------------------+
! |conversion triggering |by software |by software or timers|
! +----------------------+----------------------+---------------------+
! |conversion during |yes |yes |
! |sleep mode possible | | |
! +----------------------+----------------------+---------------------+
! |interrupts |after each conversion |after single or |
! | | |sequence conversion |
! +----------------------+----------------------+---------------------+
!
!
! External ADCs
! -------------
!
! In addition to the above internal ADCs, some of the TinyOS platforms
! use dedicated ADCs like ADS1242, ADS7828, ADS1251, ADS8345, ADS8325,
! ADS1100 (all by TI). They differ in resolution (12-bit to 24 -bit),
! interfaces (SPI, I2C), channel numbers (1 to 8), reference voltages
! and conversion rates. Implementation of the three layers of the HAA
! will be considerably different from internal ADCs, as issues like bus
! arbitration or communication errors have to be taken into
! consideration. Although the particular implementation will vary
! according to chip and platform, each HIL (`Hardware Interface Layer
! (HIL)`_) will export the standard *ADCSingle* and *ADCMultiple*
! interface, providing a uniform application-level OS service. External
! ADCs will influence the HIL interfaces and the layering in the
! following ways:
!
! - An additional command *reserveADC* will be included in the
! HIL interfaces. This command will guarantee a minimum
! delay between the next invocation of *getData* and the actual
! sampling of the channel.
! - The HIL will provide a mechanism to signal an error that
! occurred during the sampling process.
! - A more general architectural issue is how to structure the
! communication between the HPL of the external ADC and the HPL
! of the particular bus implementation.
! We propose to deal with bus arbitration and related tasks
! on the level of the HALs. I.e. the HAL\_ADC module will wire to
! e.g. HAL\_SPI module to perform bus arbitration while HPL\_ADC
! will wire to HPL\_SPI. HPL\_ADC is unaware of bus arbitration
! and will always assume to be owner of the bus. This ensures
! that
!
! - The HPL can be kept stateless.
! - The HAL is capable of deciding how long to maintain a certain
! state in bus arbitration. If there is, for example, a request
! for a continuous or sequence conversion the HAL could refrain
! from releasing the bus after each single conversion.
!
!
! 2. Architecture
! ====================================================================
!
! The proposed architecture aligns with the three-layer Hardware
! Abstraction Architecture (HAA).
!
! Hardware Presentation Layer (HPL)
! ---------------------------------
!
! a. Implementation: chip/platform dependent
! b. Presentation: chip dependent
! c. Stateless
! d. General structure:
!
! i. StdControl (init, start, stop) for power management to work
! ii. get/set commands for the registers that control the hardware
! iii. additional commands for the frequently used operations
! iv. commands for enabling/disabling of interrupts
! v. service routines for the ADC interrupt
!
! e. The HPL for an external ADC SHOULD follow the general structure
! described above by wiring to the respective hardware module's HPL
! to access the bus and relevant pins (see `External ADCs`_).
!
! Hardware Adaptation Layer (HAL)
! -------------------------------
!
! For the HAL presentation, the idea of binding an interface to ADC
! settings is extended. This mechanism was introduced in the
! ``ADCControl`` interface, but was only applied to channels. Instead of
! only binding to a channel, all settings supported by the interface
! SHOULD be passed to a ``bind`` commandhandler once at initialization.
! For all subsequent calls on the interface instance these settings are
! then valid.
!
! a. Implementation: chip/platform dependent
! b. Presentation: chip dependent
! c. MSP430:
!
! To offload the interfaces, the four supported conversion modes of the
! MSP430 are separated into two separate interfaces: *MSP430ADC12Single* and
! *MSP430ADC12Multiple*, for single and multiple conversions,
! respectively. Both interfaces provide two commands which allow the
! conversion(s) to be performed once or repeatedly. One
! characteristic of the MSP430 ADC12 is the ability to define the
! time interval between subsequent conversions. This is reflected by
! an additional parameter *jiffies* in the relevant commands of the
! HAL interfaces.
!
! A new return datatype ``msp430ADCresult_t`` is introduced, which
! not only includes MSP430ADC12_FAIL and MSP430ADC12_SUCCESS but
! also MSP430ADC12_QUEUED to queue commands.
! This is necessary to deal with a possible 17ms delay when
! starting the internal reference voltage generator.
! HAL-configuration, interfaces and datatypes are as follows (see
! `3. Implementation`_ for where to find commented versions).::
!
! configuration MSP430ADC12C
! {
! provides interface StdControl;
! provides interface MSP430ADC12Single[uint8_t id];
! provides interface MSP430ADC12Multiple[uint8_t id];
! }
!
! interface MSP430ADC12Single
! {
! command result_t bind(MSP430ADC12Settings_t settings);
! async command msp430ADCresult_t getData();
! async command msp430ADCresult_t getDataRepeat(uint16_t jiffies);
! async command result_t reserve();
! async command result_t reserveRepeat(uint16_t jiffies);
! async command result_t unreserve();
! async event result_t dataReady(uint16_t data);
! }
!
! interface MSP430ADC12Multiple
! {
! command result_t bind( MSP430ADC12Settings_t settings);
! async command msp430ADCresult_t getData(uint16_t *buf, uint16_t length,
! uint16_t jiffies);
! async command msp430ADCresult_t getDataRepeat(uint16_t *buf, uint8_t length,
! uint16_t jiffies);
! async command result_t reserve(uint16_t *buf, uint16_t length, uint16_t jiffies);
! async command result_t reserveRepeat(uint16_t *buf, uint8_t length, uint16_t jiffies);
! async command result_t unreserve();
! async event uint16_t* dataReady(uint16_t *buf, uint16_t length);
! }
!
! typedef struct
! {
! unsigned int refVolt2_5: 1; // reference voltage level
! unsigned int clockSourceSHT: 2; // clock source sample-hold-time
! unsigned int clockSourceSAMPCON: 2; // clock source sampcon signal
! unsigned int clockDivSAMPCON: 2; // clock divider sampcon
! unsigned int referenceVoltage: 3; // reference voltage
! unsigned int clockDivSHT: 3; // clock divider sample-hold-time
! unsigned int inputChannel: 4; // input channel
! unsigned int sampleHoldTime: 4; // sample-hold-time
! } MSP430ADC12Settings_t;
!
! typedef union
! {
! uint32_t i;
! MSP430ADC12Settings_t s;
! } MSP430ADC12Settings_ut;
!
! typedef enum
! {
! MSP430ADC12_FAIL = 0,
! MSP430ADC12_SUCCESS = 1,
! MSP430ADC12_QUEUED = 2
! } msp430ADCresult_t;
!
! d. Atmega 128:
! To maintain compatibility with the existing code the
! original ADC interface will be provided with one extension,
! a *reserveADC* command.
!
! i. interface Atmega128ADC::
!
! interface Atmega128ADC
! {
! async command result_t getData();
! async command result_t getContinuousData();
! async command result_t reserveADC();
! async event result_t dataReady(uint16_t data);
! }
!
!
! ii. interface ADCControl::
!
! /* the original ADCControl interface from tos/interfaces/ */
!
! command result_t init();
! command result_t setSamplingRate(uint8_t rate);
! command result_t bindPort(uint8_t port, uint8_t adcPort);
!
! e. External ADCs:
! The HALs of external ADCs are chip and platform dependent. Their
! interfaces SHOULD be defined with regard to the HIL
! interfaces specified below. As stated above (`External ADCs`_),
! HALs for external ADCs might also have to deal with bus arbitration
! and related tasks.
!
! Hardware Interface Layer (HIL)
! ------------------------------
!
! An HIL provides application-level OS services via platform independent
! interfaces. The ADC's HIL interface should abstract from platform
! dependent settings as a platform independent application is not in a
! position to deal with platform dependent settings such as a channel
! number or sample-hold-time. In HIL a translation from a platform
! independent representation of a sensor to platform dependent settings
! for a HAL's *bind* needs to be performed. Also, the HIL is responsible
! for translating an application request to HAL primitives.
!
! The current practice of having wrappers represent sensors is
! maintained: A wrapper configuration will provide a *StdControl*, the
! *ADCSingle* and the *ADCMultiple* interface. A wrapper thus
! represents the HIL in the ADC's hardware abstraction, i.e. it sits on
! top of the native HAL component. Its task is to bind to HAL with the
! appropriate settings (typically done in StdControl.init) and to
! forward commands, possibly adding slight changes to translate them to
! the HAL interface. Since an HAL interface is designed with the HIL
! interfaces in mind wrappers will typically be fairly lightweight. An
! example configuration for a temperature sensor wrapper on the msp430
! platform would look like this::
!
! StdControl
! | ADCSingle
! | | ADCMultiple
! | | |
! +------|----|----|------------------------------------------+
! | | | | Temperature |
! | v v v |
! | +--------------------+ MSP430ADC12Single +------------+ |
! | | TemperatureM |-------------------->|MSP430ADC12C| |
! | | | MSP430ADC12Multiple | | |
! | | |-------------------->| | |
! | +--------------------+ +------------+ |
! +-----------------------------------------------------------+
!
! On the level of HIL two interfaces MUST be provided: ADCSingle and
! ADCMultiple. ADCSingle is used for single conversions (once or
! repeated) and ADCMultiple is used for multiple conversions (once or
! repeated).
!
! Both interfaces must take into account that some (e.g. external ADCs)
! may face errors during the sampling process which can lead to invalid
! results. Therefore events in the ADCSingle and ADCMultiple interfaces
! not only return the conversion result(s) but also additional error
! information contained in a new datatype adcresult_t.
!
! The returned conversion results are uninterpreted 16-bit values. Note
! that still multiple results can be combined by an application to
! create a mean or median.
!
! a. Implementation: platform dependent
! b. Presentation: application-level OS service (see
! `3. Implementation`_ for where to find the commented version).::
!
! interface ADCSingle
! {
! async command adcresult_t getData();
! async command adcresult_t getDataContinuous();
! async command adcresult_t reserve();
! async command adcresult_t reserveContinuous();
! async command adcresult_t unreserve();
! async event result_t dataReady(adcresult result, uint16_t data);
! }
!
! interface ADCMultiple
! {
! async command adcresult_t getData(uint16_t *buf, uint16_t length);
! async command adcresult_t getDataContinuous(uint16_t *buf, uint16_t length);
! async command adcresult_t reserve(uint16_t *buf, uint16_t length);
! async command adcresult_t reserveContinuous(uint16_t *buf, uint16_t length);
! async command adcresult_t unreserve();
! async event uint16_t* dataReady(adcresult result, uint16_t *buf, uint16_t length);
! }
!
!
! 3. Implementation
! ====================================================================
!
! The ADCSingle and ADCMultiple interfaces and ADCHIL.h (containing the
! definition of adcresult_t) can be found in tos/interfaces. Interfaces
! relating to msp430 are in tos/platform/msp430. The HAL implementation
! of the msp430 as well as wrappers (HIL) for internal temperature and
! internal voltage of the msp430 can also be found in
! tos/platform/msp430. A test application for the msp430 platform is
! tinyos-1.x/contrib/eyes/apps/TestADC.
!
! 4. Author's Address
! ====================================================================
!
! | Jan Hauer <hauer at tkn.tu-berlin.de>,
! | Vlado Handziski <handzisk at tkn.tu-berlin.de>,
! | Joe Polastre <polastre at cs.berkeley.edu>,
! | Lama Nachman <lama.nachman at intel.com>
!
!
Index: tep106.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep106.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** tep106.txt 18 Dec 2004 00:21:58 -0000 1.4
--- tep106.txt 18 Jan 2005 22:34:04 -0000 1.5
***************
*** 12,16 ****
:Draft-Version: $Revision$
:Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-1.2WG List <tinyos at barnowl.org>
.. Note::
--- 12,16 ----
:Draft-Version: $Revision$
:Draft-Modified: $Date$
! :Draft-Discuss: TinyOS-2.0 Working Group list <tinyos-2.0wg at mail.millenium.berkeley.edu>
.. Note::
More information about the Tinyos-beta-commits
mailing list