[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep101.txt, NONE, 1.1
Jan-Hinrich Hauer
janhauer at users.sourceforge.net
Tue Jan 4 09:11:32 PST 2005
- Previous message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/Deluge/Deluge Deluge.h,
1.3, 1.4 DelugeM.nc, 1.4, 1.5 DelugeMetadataM.nc, 1.4,
1.5 DelugeMsgs.h, 1.2, 1.3 DelugePageTransfer.nc, 1.2,
1.3 DelugePageTransferM.nc, 1.3, 1.4 DelugeImgDescStorage.nc,
1.1, NONE DelugePageTransfer.h, 1.1, NONE
- Next message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/platform/imote2
.platform, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30252/beta/teps/txt
Added Files:
tep101.txt
Log Message:
ADC tep.
--- NEW FILE: tep101.txt ---
===================================
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: 1.1 $
:Draft-Modified: $Date: 2005/01/04 17:11:30 $
: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 *ADCHILSingle* and *ADCHILMultiple*
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_ut 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_ut 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
*ADCHILSingle* and the *ADCHILMultiple* 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
| ADCHILSingle
| | ADCHILMultiple
| | |
+------|----|----|------------------------------------------+
| | | | Temperature |
| v v v |
| +--------------------+ MSP430ADC12Single +------------+ |
| | TemperatureM |-------------------->|MSP430ADC12C| |
| | | MSP430ADC12Multiple | | |
| | |-------------------->| | |
| +--------------------+ +------------+ |
+-----------------------------------------------------------+
On the level of HIL two interfaces MUST be provided: ADCHILSingle and
ADCHILMultiple. ADCHILSingle is used for single conversions (once or
repeated) and ADCHILMultiple 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 ADCHILSingle and ADCHILMultiple
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 ADCHILSingle
{
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 ADCHILMultiple
{
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 ADCHILSingle and ADCHILMultiple 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.
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>
- Previous message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/Deluge/Deluge Deluge.h,
1.3, 1.4 DelugeM.nc, 1.4, 1.5 DelugeMetadataM.nc, 1.4,
1.5 DelugeMsgs.h, 1.2, 1.3 DelugePageTransfer.nc, 1.2,
1.3 DelugePageTransferM.nc, 1.3, 1.4 DelugeImgDescStorage.nc,
1.1, NONE DelugePageTransfer.h, 1.1, NONE
- Next message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/platform/imote2
.platform, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-beta-commits
mailing list