[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/html tep101.html,
NONE, 1.1 tep106.html, NONE, 1.1 tep1.html, 1.3, 1.4
Ion Yannopoulos
ion- at users.sourceforge.net
Tue Jan 18 14:34:39 PST 2005
- Previous message: [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
- Next message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/Drip Drip.h, NONE,
1.1 Drip.nc, NONE, 1.1 DripC.nc, NONE, 1.1 DripM.nc, NONE,
1.1 DripState.nc, NONE, 1.1 DripStateC.nc, NONE,
1.1 DripStateM.nc, NONE, 1.1 DripStateMgr.nc, NONE,
1.1 README.txt, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/html
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25526/html
Modified Files:
tep1.html
Added Files:
tep101.html tep106.html
Log Message:
Updating TEPs with 2.0 information instead of 1.2.
--- NEW FILE: tep101.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<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>ADCs (analog-to-digital converters)</title>
<meta name="author" content="Jan-Hinrich Hauer, Vlado Handziski, Joe Polastre, Lama Nachman" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2005/01/18 22:33:59 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
/* Uncomment (& remove this text!) to get bold-faced definition list terms
dt {
font-weight: bold }
*/
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee }
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {
background-color: #eeeeee }
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="adcs-analog-to-digital-converters">
<h1 class="title">ADCs (analog-to-digital converters)</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">101</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Jan-Hinrich Hauer, Vlado Handziski, Joe Polastre, Lama Nachman</td></tr>
<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.2</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2005-01-10</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-2.0 Working List <tinyos-2.0wg at mail.millenium.berkeley.edu></td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">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.</p>
</div>
<div class="section" id="abstract">
<h1><a name="abstract">Abstract</a></h1>
<p>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).</p>
</div>
<div class="section" id="introduction">
<h1><a name="introduction">1. Introduction</a></h1>
<div class="section" id="internal-adcs">
<h2><a name="internal-adcs">Internal ADCs</a></h2>
<p>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:</p>
<table border="1" class="docutils">
<colgroup>
<col width="34%" />
<col width="34%" />
<col width="32%" />
</colgroup>
<thead valign="bottom">
<tr><th> </th>
<th>Atmel Atmega 128</th>
<th>TI MSP430 ADC12</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Resolution</td>
<td>10-bit</td>
<td>12-bit</td>
</tr>
<tr><td>channels</td>
<td><ul class="first last simple">
<li>8 multiplexed
external channels</li>
<li>16 differential
voltage input
combinations</li>
<li>2 differential
inputs with gain
amplification</li>
</ul>
</td>
<td><ul class="first last simple">
<li>8 individually
configurable
external channels</li>
<li>internal channels
(AVcc, temperature,
reference voltages)</li>
</ul>
</td>
</tr>
<tr><td>internal reference
voltage</td>
<td>2.56V</td>
<td>1.5V or 2.5V</td>
</tr>
<tr><td>conversion reference</td>
<td><ul class="first last simple">
<li>positive terminal:
AVcc or 2.56V or
AREF (external)</li>
<li>negative terminal:
GND</li>
</ul>
</td>
<td><blockquote class="first">
individually
selectable per
channel:</blockquote>
<ul class="last simple">
<li>AVcc and AVss</li>
<li>Vref+ and AVss</li>
<li>Veref+ and AVss</li>
<li>AVcc and (Vref- or
Veref-)</li>
<li>AVref+ and (Vref-
or Veref-)</li>
<li>Veref+ and (Vref-
or Veref-)</li>
</ul>
</td>
</tr>
<tr><td>conversion modes</td>
<td><ul class="first last simple">
<li>single channel
conversion mode</li>
<li>free running mode
(repeated single
channel conversion)</li>
</ul>
</td>
<td><ul class="first last simple">
<li>single conversion
mode</li>
<li>repeat single
conversion mode</li>
<li>sequence mode
(sequence <= 16
channels)</li>
<li>repeat sequence
mode</li>
</ul>
</td>
</tr>
<tr><td>conversion clock
source</td>
<td>clkADC with prescaler</td>
<td>ACLK, MCLK, SMCLK or
ADC-oscillator (5MHz)
with prescaler
respectively</td>
</tr>
<tr><td>sample-hold-time</td>
<td>1.5 clock cycles
(fixed)</td>
<td>selectable values
from 4 to 1024 clock
cycles</td>
</tr>
<tr><td>conversion triggering</td>
<td>by software</td>
<td>by software or timers</td>
</tr>
<tr><td>conversion during
sleep mode possible</td>
<td>yes</td>
<td>yes</td>
</tr>
<tr><td>interrupts</td>
<td>after each conversion</td>
<td>after single or
sequence conversion</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="external-adcs">
<h2><a name="external-adcs">External ADCs</a></h2>
<p>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 (<a class="reference" href="#hardware-interface-layer-hil">Hardware Interface Layer
(HIL)</a>) will export the standard <em>ADCSingle</em> and <em>ADCMultiple</em>
interface, providing a uniform application-level OS service. External
ADCs will influence the HIL interfaces and the layering in the
following ways:</p>
<ul>
<li><p class="first">An additional command <em>reserveADC</em> will be included in the
HIL interfaces. This command will guarantee a minimum
delay between the next invocation of <em>getData</em> and the actual
sampling of the channel.</p>
</li>
<li><p class="first">The HIL will provide a mechanism to signal an error that
occurred during the sampling process.</p>
</li>
<li><p class="first">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</p>
<blockquote>
<ul class="simple">
<li>The HPL can be kept stateless.</li>
<li>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.</li>
</ul>
</blockquote>
</li>
</ul>
</div>
</div>
<div class="section" id="architecture">
<h1><a name="architecture">2. Architecture</a></h1>
<p>The proposed architecture aligns with the three-layer Hardware
Abstraction Architecture (HAA).</p>
<div class="section" id="hardware-presentation-layer-hpl">
<h2><a name="hardware-presentation-layer-hpl">Hardware Presentation Layer (HPL)</a></h2>
<ol class="loweralpha simple">
<li>Implementation: chip/platform dependent</li>
<li>Presentation: chip dependent</li>
<li>Stateless</li>
<li>General structure:<ol class="lowerroman">
<li>StdControl (init, start, stop) for power management to work</li>
<li>get/set commands for the registers that control the hardware</li>
<li>additional commands for the frequently used operations</li>
<li>commands for enabling/disabling of interrupts</li>
<li>service routines for the ADC interrupt</li>
</ol>
</li>
<li>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 <a class="reference" href="#external-adcs">External ADCs</a>).</li>
</ol>
</div>
<div class="section" id="hardware-adaptation-layer-hal">
<h2><a name="hardware-adaptation-layer-hal">Hardware Adaptation Layer (HAL)</a></h2>
<p>For the HAL presentation, the idea of binding an interface to ADC
settings is extended. This mechanism was introduced in the
<tt class="docutils literal"><span class="pre">ADCControl</span></tt> 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 <tt class="docutils literal"><span class="pre">bind</span></tt> commandhandler once at initialization.
For all subsequent calls on the interface instance these settings are
then valid.</p>
<ol class="loweralpha">
<li><p class="first">Implementation: chip/platform dependent</p>
</li>
<li><p class="first">Presentation: chip dependent</p>
</li>
<li><p class="first">MSP430:</p>
<p>To offload the interfaces, the four supported conversion modes of the
MSP430 are separated into two separate interfaces: <em>MSP430ADC12Single</em> and
<em>MSP430ADC12Multiple</em>, 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 <em>jiffies</em> in the relevant commands of the
HAL interfaces.</p>
<p>A new return datatype <tt class="docutils literal"><span class="pre">msp430ADCresult_t</span></tt> 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
<a class="reference" href="#implementation">3. Implementation</a> for where to find commented versions).:</p>
<pre class="literal-block">
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;
</pre>
</li>
<li><p class="first">Atmega 128:
To maintain compatibility with the existing code the
original ADC interface will be provided with one extension,
a <em>reserveADC</em> command.</p>
<ol class="lowerroman">
<li><p class="first">interface Atmega128ADC:</p>
<pre class="literal-block">
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);
}
</pre>
</li>
<li><p class="first">interface ADCControl:</p>
<pre class="literal-block">
/* 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);
</pre>
</li>
</ol>
</li>
<li><p class="first">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 (<a class="reference" href="#external-adcs">External ADCs</a>),
HALs for external ADCs might also have to deal with bus arbitration
and related tasks.</p>
</li>
</ol>
</div>
<div class="section" id="hardware-interface-layer-hil">
<h2><a name="hardware-interface-layer-hil">Hardware Interface Layer (HIL)</a></h2>
<p>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 <em>bind</em> needs to be performed. Also, the HIL is responsible
for translating an application request to HAL primitives.</p>
<p>The current practice of having wrappers represent sensors is
maintained: A wrapper configuration will provide a <em>StdControl</em>, the
<em>ADCSingle</em> and the <em>ADCMultiple</em> 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:</p>
<pre class="literal-block">
StdControl
| ADCSingle
| | ADCMultiple
| | |
+------|----|----|------------------------------------------+
| | | | Temperature |
| v v v |
| +--------------------+ MSP430ADC12Single +------------+ |
| | TemperatureM |-------------------->|MSP430ADC12C| |
| | | MSP430ADC12Multiple | | |
| | |-------------------->| | |
| +--------------------+ +------------+ |
+-----------------------------------------------------------+
</pre>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<ol class="loweralpha">
<li><p class="first">Implementation: platform dependent</p>
</li>
<li><p class="first">Presentation: application-level OS service (see
<a class="reference" href="#implementation">3. Implementation</a> for where to find the commented version).:</p>
<pre class="literal-block">
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);
}
</pre>
</li>
</ol>
</div>
</div>
<div class="section" id="implementation">
<h1><a name="implementation">3. Implementation</a></h1>
<p>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.</p>
</div>
<div class="section" id="author-s-address">
<h1><a name="author-s-address">4. Author's Address</a></h1>
<div class="line-block">
<div class="line">Jan Hauer <hauer at tkn.tu-berlin.de>,</div>
<div class="line">Vlado Handziski <handzisk at tkn.tu-berlin.de>,</div>
<div class="line">Joe Polastre <polastre at cs.berkeley.edu>,</div>
<div class="line">Lama Nachman <lama.nachman at intel.com></div>
</div>
</div>
</div>
</body>
</html>
--- NEW FILE: tep106.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<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>Schedulers and Tasks</title>
<meta name="author" content="Philip Levis and Cory Sharp" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2005/01/18 22:33:59 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
/* Uncomment (& remove this text!) to get bold-faced definition list terms
dt {
font-weight: bold }
*/
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee }
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {
background-color: #eeeeee }
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="schedulers-and-tasks">
<h1 class="title">Schedulers and Tasks</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">106</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Philip Levis and Cory Sharp</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.4</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2004-12-18</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-2.0 Working Group list <tinyos-2.0wg at mail.millenium.berkeley.edu></td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">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.</p>
</div>
<div class="section" id="abstract">
<h1><a name="abstract">Abstract</a></h1>
<p>This memo documents the structure and implementation of TinyOS tasks
and task schedulers in TinyOS 2.x.</p>
</div>
<div class="section" id="introduction">
<h1><a name="introduction">1. Introduction</a></h1>
<p>TinyOS has two basic computational abstractions: asynchronous events
and tasks. Prior versions of TinyOS provided a single type of task --
parameter free -- and only a FIFO scheduling policy. While changing
the latter was possible, the incorporation of tasks into the nesC
language made it very difficult. Presenting task schedulers as a
TinyOS component enables much easier customization, and allowing tasks
to be presented as an interface enables extending the classes of tasks
available. TinyOS 2.0 takes both approaches, and this memo documents
the structure of how it does so.</p>
</div>
<div class="section" id="tasks-and-the-scheduler-in-tinyos-1-x">
<h1><a name="tasks-and-the-scheduler-in-tinyos-1-x">2. Tasks and the Scheduler in TinyOS 1.x</a></h1>
<p>Tasks in TinyOS are a form of deferred procedure call (DPC)[1], which
enable a program to defer a computation or operation until a later
time. TinyOS tasks run to completion and do not pre-empt one
another[2]. These two constraints mean that code called from tasks
runs synchonously with respect to other tasks. Put another way, tasks
are atomic with respect to other tasks[3].</p>
<p>In TinyOS 1.x, the nesC language supports tasks through two
mechanisms, <tt class="docutils literal"><span class="pre">task</span></tt> declarations and <tt class="docutils literal"><span class="pre">post</span></tt> expressions:</p>
<div class="line-block">
<div class="line"><tt class="docutils literal"><span class="pre">task</span> <span class="pre">void</span> <span class="pre">computeTask()</span> <span class="pre">{</span></tt></div>
<div class="line-block">
<div class="line"><tt class="docutils literal"><span class="pre">//</span> <span class="pre">Code</span> <span class="pre">here</span></tt></div>
</div>
<div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
</div>
<p>and</p>
<div class="line-block">
<div class="line"><tt class="docutils literal"><span class="pre">result_t</span> <span class="pre">rval</span> <span class="pre">=</span> <span class="pre">post</span> <span class="pre">computeTask();</span></tt></div>
</div>
<p>TinyOS 1.x provides a single kind of task, a parameter-free function,
and a single scheduling policy, FIFO. <tt class="docutils literal"><span class="pre">post</span></tt> expressions can return
FAIL, to denote that TinyOS was unable to post the task. Tasks can be
posted multiple times. For example, if a task is posted twice in quick
succession and the first succeeds while the second fails, then the
task will be run in the future; for this reason, even if a <tt class="docutils literal"><span class="pre">post</span></tt>
fails, the task may run.</p>
<p>The TinyOS 1.x scheduler is implemented as a set of C functions in the
file <tt class="docutils literal"><span class="pre">sched.c</span></tt>. Modifying the scheduler requires replacing or
changing this file. Additionally, as tasks are supported solely through
nesC <tt class="docutils literal"><span class="pre">task</span></tt> declarations and <tt class="docutils literal"><span class="pre">post</span></tt> expressions, which assume
a parameter-free function, modifying the syntax or capabilities of
tasks is not possible.</p>
<p>The task queue in TinyOS 1.x is implemented as a fixed size circular
buffer of function pointers. Posting a task puts the task's function
pointer in the next free element of the buffer; if there are no free
elements, the <tt class="docutils literal"><span class="pre">post</span></tt> returns fail. This model has several issues:</p>
<blockquote>
<ol class="arabic simple">
<li>Some components do not have a reasonable response to a failed <tt class="docutils literal"><span class="pre">post</span></tt></li>
<li>As a given task can be posted multiple times, it can consume more than one element in the buffer</li>
<li>All tasks from all components share a single resource: one misbehaving component cause other's posts to fail</li>
</ol>
</blockquote>
<p>The combination of the above three issues mean that one misbehaving
component can cause TinyOS to hang. Consider, for example, this
scenario (a real and encountered problem on the Telos platform):</p>
<blockquote>
<ul class="simple">
<li>A packet-based hardware radio, which issues an interrupt only when it finishes sending a packet</li>
<li>A networking component that handles the interrupt to post a task to signal <tt class="docutils literal"><span class="pre">SendMsg.sendDone</span></tt>.</li>
<li>A sensing component that posts a task when it handles an <tt class="docutils literal"><span class="pre">ADC.dataReady</span></tt> event</li>
<li>An application component that sends a packet and then sets its ADC sampling rate too high</li>
</ul>
</blockquote>
<p>In this scenario, the sensing component will start handling events at
a faster rate than it can process them. It will start posting tasks to
handle the data it receives, until it fills the task queue. At some
point later, the radio finishes sending a packet and signals its
interrupt. The networking component, however, is unable to post its
task that signals <tt class="docutils literal"><span class="pre">SendMsg.sendDone()</span></tt>, losing the event. The
application component does not try to send another packet until it
knows the one it is sending completes (so it can re-use the
buffer). As the <tt class="docutils literal"><span class="pre">sendDone()</span></tt> event was lost, this will never occur,
and the application stops sending network traffic.</p>
<p>The solution to this problem in TinyOS 1.x is to signal sendDone() in
the radio send complete interrupt if the post fails: this violates the
sync/async boundary, but the justification is that a <em>possible</em> rare
race condition is better than <em>certain</em> failure. The TinyOS 1.x model
prevents it from doing any better.</p>
</div>
<div class="section" id="tasks-in-tinyos-2-x">
<h1><a name="tasks-in-tinyos-2-x">3. Tasks in TinyOS 2.x</a></h1>
<p>TinyOS 2.x takes the position that the basic use case of tasks should
remain simple and easy to use, but that it should be possible to
introduce new kinds of tasks beyond the basic use case. TinyOS
actualizes this by keeping <tt class="docutils literal"><span class="pre">post</span></tt> and <tt class="docutils literal"><span class="pre">task</span></tt> for the basic case,
and introducing task interfaces for additional ones.</p>
<p>Task interfaces allow users to extend the syntax and semantics of
tasks. Generally, a task interface has an <tt class="docutils literal"><span class="pre">async</span></tt> command, <tt class="docutils literal"><span class="pre">post</span></tt>,
and an event, <tt class="docutils literal"><span class="pre">run</span></tt>. The exact signature of these functions are
up to the interface. For example, a task interface that allows a task
to take an integer parameter could look like this:</p>
<div class="line-block">
<div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">TaskParameter</span> <span class="pre">{</span></tt></div>
<div class="line-block">
<div class="line"><tt class="docutils literal"><span class="pre">async</span> <span class="pre">result_t</span> <span class="pre">command</span> <span class="pre">post(uint16_t</span> <span class="pre">param);</span></tt></div>
<div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">run(uin16_t</span> <span class="pre">param);</span></tt></div>
</div>
<div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
</div>
<p>Using this task interface, a component could post a task with a
<tt class="docutils literal"><span class="pre">uint16_t</span></tt> parameter. When the scheduler runs the task, it will
signal the <tt class="docutils literal"><span class="pre">run</span></tt> event with the passed parameter, which contains
the task's logic.</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">Need to settle on exact basic task semantics.</p>
</div>
</div>
<div class="section" id="the-scheduler-in-tinyos-2-x">
<h1><a name="the-scheduler-in-tinyos-2-x">4. The Scheduler in TinyOS 2.x</a></h1>
<p>In TinyOS 2.x, the scheduler is a TinyOS component. Every scheduler
must support basic nesC tasks. It may also support any number of
additional task interfaces. The scheduler component is resonsible for
the policy of reconciling different task types (e.g., earliest
deadline first tasks vs. priority tasks).</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">The format and implementation of basic tasks greatly depends on their semantics. Need to hash this out.</p>
</div>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">Need a better story on this. Separate component? Main?</p>
</div>
</div>
<div class="section" id="author-s-address">
<h1><a name="author-s-address">6. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
<div class="line">467 Soda Hall</div>
<div class="line">UC Berkeley</div>
<div class="line">Berkeley, CA 94720</div>
<div class="line"><br /></div>
<div class="line">phone - +1 510 290 5283</div>
<div class="line"><br /></div>
<div class="line">email - <a class="reference" href="mailto:pal@cs.berkeley.edu">pal@cs.berkeley.edu</a></div>
</div>
</div>
<div class="section" id="citations">
<h1><a name="citations">7. Citations</a></h1>
<table class="docutils citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="rst">[rst]</a></td><td>reStructuredText Markup Specification. <<a class="reference" href="http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html">http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html</a>></td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
Index: tep1.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/html/tep1.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep1.html 18 Dec 2004 00:21:58 -0000 1.3
--- tep1.html 18 Jan 2005 22:33:47 -0000 1.4
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>TEP structure and key words</title>
<meta name="author" content="Philip Levis" />
--- 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>TEP structure and key words</title>
<meta name="author" content="Philip Levis" />
***************
*** 276,279 ****
--- 276,280 ----
</head>
<body>
+ <div class="document" id="tep-structure-and-key-words">
<h1 class="title">TEP structure and key words</h1>
<table class="docinfo" frame="void" rules="none">
***************
*** 299,307 ****
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2004-12-10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-1.2WG List <tinyos at barnowl.org></td>
</tr>
</tbody>
</table>
- <div class="document" id="tep-structure-and-key-words">
<div class="note">
<p class="first admonition-title">Note</p>
--- 300,307 ----
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2004-12-10</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-2.0 Working Group list <tinyos-2.0wg at mail.millenium.berkeley.edu></td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
- Previous message: [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
- Next message: [Tinyos-beta-commits] CVS: tinyos-1.x/beta/Drip Drip.h, NONE,
1.1 Drip.nc, NONE, 1.1 DripC.nc, NONE, 1.1 DripM.nc, NONE,
1.1 DripState.nc, NONE, 1.1 DripStateC.nc, NONE,
1.1 DripStateM.nc, NONE, 1.1 DripStateMgr.nc, NONE,
1.1 README.txt, NONE, 1.1
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-beta-commits
mailing list