[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/html tep103.html,
NONE, 1.1 tep105.html, NONE, 1.1 tep102.html, 1.1, 1.2
Ion Yannopoulos
ion- at users.sourceforge.net
Mon Jan 31 15:10:04 PST 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/html
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26485/html
Modified Files:
tep102.html
Added Files:
tep103.html tep105.html
Log Message:
Clean up RST so HTML will generate properly.
--- NEW FILE: tep103.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>Storage (permanent (e.g., flash) data storage)</title>
<meta name="author" content="David Gay, Jonathan Hui" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2005/01/31 23:09:57 $
: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="storage-permanent-e-g-flash-data-storage">
<h1 class="title">Storage (permanent (e.g., flash) data storage)</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">103</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.0</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>David Gay, Jonathan Hui</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">27-Sep-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-26</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-2.0WG List <tinyos at barnowl.org></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 covers permanent storage abstractions for TinyOS 2.0, and the
HPL and HAL layers for various flash chips.</p>
</div>
<div class="section" id="introduction">
<h1><a name="introduction">1. Introduction</a></h1>
<div class="section" id="hardware-differences-between-the-current-platforms">
<h2><a name="hardware-differences-between-the-current-platforms">Hardware differences between the current platforms</a></h2>
<p>There are three different flash chip families under use or consideration
for TinyOS platforms: the Atmel AT45DB family (Mica family, Telos rev. A),
the ST M25P family (Telos rev. B, eyes) and the Intel Strataflash (imote2).
All three are "NOR" flash chips, but the AT45DB has fairly different
characteristics (see below). There also "NAND" flash chips which have
rather different tradeoffs from NOR flash. Compact flash/etc cards use
NAND flash but present a disk-like block interface.</p>
<p>A common restriction of flash technology is that each bit can only be
written once between erases. The table below summarizes the differences
between the various flash technologies:</p>
<pre class="literal-block">
NOR AT45DB NAND
Erase : Slow (seconds) Fast (ms) Fast (ms)
Erase unit : Large (64KB-128KB) Small (256B) Medium (8K-32KB)
Writes : Slow (100s kB/s) Slow (60kB/s) Fast (MBs/s)
Write unit : 1 bit 256B 100's of bytes
Bit-errors : Low Low High (requires ECC,
bad-block mapping)
Read : Fast* Slow+I/O bus Fast (but limited by
I/O bus)
Erase cycles : 10^4 - 10^5 10^4 ** 10^5 - 10^7
Intended use : Code storage Data storage Data storage
* imote2 NOR flash is memory mapped (reads are very fast and can
directly execute code)
** Or infinite? Data sheet just says that every page within a sector
must be written every 10^4 writes within that sector
</pre>
<p>From the power consumption for erasing and writing, we can derive an
energy cost/byte written (for NAND flash, taken from a Samsung datasheet):</p>
<blockquote>
Energy/byte: 1uJ 1uJ .01uJ</blockquote>
<p>Energy/byte for reads appears to depend mostly on how long the read takes
(the power consumptions are comparable), i.e., on the efficiency of the bus
+ processor...</p>
</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="hpl-hal-hil-structure">
<h2><a name="hpl-hal-hil-structure">HPL/HAL/HIL Structure</a></h2>
<p>The very significant differences between the flash chips used in TinyOS
preclude common, low-level HIL interfaces such as a disk-like block
interface. Instead, we propose that the HIL interfaces correspond to
high-level storage services useful for sensor network applications. We
have identified three storage abstractions:</p>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Large objects (Deluge, Large Data Transfer):</p>
<blockquote>
<p>This scenario involves getting a large (100's bytes to kilobytes or
more) free chunk (through alloc or erase), writing to each
byte/block once in any arbitrary order, and "committing" when the
chunk is filled.</p>
</blockquote>
<p>Size: large
Reads: random
Writes: random (minimum block size?), each block written once
Failure model: no fault tolerance (crash before commit leads to
object loss)
Other: a commit operation terminates writes, a validate operation
checks the object.</p>
</li>
<li><p class="first">Small objects (Deluge metadata, many other apps):</p>
<blockquote>
<p>This scenario involves keeping a small chunk (less than 100
some bytes). Requires multiple and random reads/writes.</p>
</blockquote>
<p>Size: small
Reads: random
Writes: random, no minimum block size, rewrite ok
Failure model: writes are atomic, failure during/between writes
does not lead to object loss</p>
</li>
<li><p class="first">Large sequential objects (Logs)</p>
<blockquote>
<p>Some applications (e.g., low-rate data collection, SNMS events) may
want to log all their results in a reliable fashion, possibly
in a circular buffer.</p>
</blockquote>
<p>Size: large
Reads: from memorized write points or beginning
Writes: sequential, object is linear or circular
Failure model: writes are atomic, failure during/between writes
does not lead to whole object loss, but may lead to loss of
some entries (but see sync)
Note: failure during write may lead to (minor) capacity reduction
Other: sync: guarantees already written data will not be lost to
(crash-style) failure</p>
</li>
</ol>
</blockquote>
<p>These interfaces will be offered on top of a uniform method of sharing
the flash. Volumes are allocated in a similar way to fdisk. Volumes
will be allocated and a partition table kept in non-volatile
storage. To use a volume, it must be mounted. Thus, volumes exist
independent of which components the applications are compiled
with. This allows switching of applications while managing the sharing
of flash.</p>
<p>We envision separate implementations of these abstractions for each class
of storage chip; these implementations will be found in the new
tos/chips/CHIPNAME hierarchy.</p>
</div>
<div class="section" id="hardware-presentation-layer-hpl">
<h2><a name="hardware-presentation-layer-hpl">Hardware Presentation Layer (HPL)</a></h2>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Implementation: system dependent</p>
</li>
<li><p class="first">Presentation: chip (family?) dependent (common HPL for same chip
(family?) on different systems)</p>
</li>
<li><p class="first">Stateless</p>
</li>
<li><p class="first">Atmel 45DB family low-level interfaces</p>
<blockquote>
<p>select, send/receive SPI byte, idle detection
(no commands, as efficiency dictates their integration in the HAL)
See tos/platform/mica/HPLFlashM</p>
</blockquote>
</li>
<li><p class="first">Intel Strataflash</p>
<blockquote>
<p>write data, erase, lock/unlock blocks, read config data, etc.
details omitted - main interesting point is lack of reads, as device
is memory mapped</p>
</blockquote>
</li>
<li><p class="first">M25P family</p>
<blockquote>
<p>r/w data, erase (sector or chip), r/w status, etc
(full details omitted)</p>
</blockquote>
</li>
</ol>
</blockquote>
</div>
<div class="section" id="hardware-adaptation-layer-hal">
<h2><a name="hardware-adaptation-layer-hal">Hardware Adaptation Layer (HAL)</a></h2>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Implementation: chip dependent</p>
</li>
<li><p class="first">Presentation: chip dependent</p>
</li>
<li><p class="first">Atmel 45DB:
i. read, write, erase pages
ii. compute page crc
iii. automatic buffer management (+ sync, flush)
iv. see tos/platform/mica/PageEEPROM|PageEEPROMM.nc</p>
</li>
<li><p class="first">Intel Strataflash (should extend to other memory-mapped NOR flashes):</p>
<pre class="literal-block">
interface HALStrata { /* In flux until higher level stuff written */
command result_t lockRange(uint32_t from, uint32_t count);
command result_t unlockRange(uint32_t from, uint32_t count);
/* These return to read array mode when done */
command result_t write(uint32_t address, uint16_t *data, uint8_t count);
event void writeDone(result_t success);
command result_t erase(uint32_t block);
event void eraseDone(result_t success);
/* Will probably want to read some amount of device info. Not clear what
yet, exactly. */
}
</pre>
</li>
<li><p class="first">M25P:</p>
<pre class="literal-block">
interface {
command result_t read(addr_t addr, void* dest, addr_t len);
event result_t readDone(result_t result);
command result_t write(addr_t addr, void* source, addr_t len);
event result_t writeDone(result_t result);
command result_t erase(sector_t sector);
event result_t eraseDone(result_t result);
command result_t bulkErase();
event result_t bulkEraseDone();
}
</pre>
</li>
</ol>
</blockquote>
</div>
<div class="section" id="hardware-interface-layer-hil">
<h2><a name="hardware-interface-layer-hil">Hardware Interface Layer (HIL)</a></h2>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Implementation: Chip dependent</p>
</li>
<li><p class="first">Presentation: application-level OS service (see discussion above)</p>
</li>
<li><p class="first">Space allocation</p>
<p>This is similar to fdisk. Allocation of volumes can only occur
between calls to init() and commit(). init() wipes the volume
table clean and commit() writes out the volume table:</p>
<pre class="literal-block">
interface FStorage {
command result_t init();
command result_t allocate(uint8_t id, addr_t size);
command result_t allocateFixed(uint8_t id, addr_t addr, addr_t size);
command result_t commit();
event void commitDone(storage_result_t result, uint8_t id);
}
</pre>
<p>The mount interface is used to setup access to a specific
volume:</p>
<pre class="literal-block">
interface Mount {
command result_t mount(uint8_t id);
event void mountDone(storage_result_t result, uint8_t id);
}
</pre>
<p>This interface is provided by the components implementing
BlockRead/Write, ConfigStorage, and LogRead/Write. This
interface is necessary for components to setup any required
metadata. For example, ConfigRead may need to know where to
read a specific configuration. LogWrite may need to search for
the current offset:</p>
<pre class="literal-block">
interface VolumeInit {
command result_t init();
event void initDone(storage_result_t result);
}
</pre>
</li>
<li><p class="first">Large object:</p>
<pre class="literal-block">
interface BlockWrite {
// compile-time block storage size constant available,
// varies by platform. Len must be a multiple of this.
command result_t write(addr_t addr, void* source, addr_t len);
event void writeDone(storage_result_t result);
command result_t erase();
event void eraseDone(storage_result_t result);
command result_t commit();
event void commitDone(storage_result_t result);
}
interface BlockRead {
command result_t read(addr_t addr, void* dest, addr_t len);
event void readDone(storage_result_t result);
command result_t verify();
event void verifyDone(storage_result_t result);
}
</pre>
</li>
<li><p class="first">Small object:</p>
<pre class="literal-block">
interface ConfigStorage {
command result_t read(addr_t addr, void* dest, addr_t len);
event void readDone(storage_result_t result);
command result_t write(addr_t addr void* source, addr_t len);
event void writeDone(storage_result_t result);
command result_t commit();
event void commitDone(storage_result_t result);
}
</pre>
</li>
<li><p class="first">Large sequential object:</p>
<pre class="literal-block">
interface LogWrite {
command result_t erase();
event void eraseDone(storage_result_t success);
command result_t append(uint8_t* data, uint32_t numBytes);
event void appendDone(uint8_t* data, uint32_t numBytes, result_t success);
command uint32_t currentOffset();
command result_t sync();
event void syncDone(storage_result_t success);
}
interface LogRead {
command result_t read(uint8_t* data, uint32_t numBytes);
event void readDone(uint8_t* data, uint32_t numBytes, result_t success);
command result_t seek(uint32_t cookie);
event void seekDone(storage_result_t success);
}
</pre>
</li>
</ol>
<blockquote>
The circular-vs-linear distinction is made by offering separate
instances of the LogData, LogRead interfaces.</blockquote>
</blockquote>
</div>
</div>
<div class="section" id="implementation">
<h1><a name="implementation">3. Implementation</a></h1>
<p>An STM25P implementation can be found in tinyos-1.x/beta/STM25P.</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">David Gay <dgay at acm.org>,</div>
<div class="line">Jonathan Hui <jwhui at cs.berkeley.edu></div>
</div>
</div>
</div>
</body>
</html>
--- NEW FILE: tep105.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>Link Layer Primitives in TinyOS</title>
<meta name="author" content="Joe Polastre" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2005/01/31 23:09:57 $
: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="link-layer-primitives-in-tinyos">
<h1 class="title">Link Layer Primitives in TinyOS</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">105</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>Joe Polastre</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">13-Oct-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-24</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-2.0WG List <tinyos at barnowl.org></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 covers the primitives addressed by the link layer
and the architecture for composing services at the link layer</p>
</div>
<div class="section" id="overview">
<h1><a name="overview">Overview</a></h1>
<p>TinyOS now has platforms with bit/byte/packet level interfaces.
Link layers must be written to expose a common interface to the radio,
provide feedback from the physical layer to services, but still expose
critical information (data, timing, power) in an independent manner.
This TEP proposes the HPL and HIL components of the link protocol stack.
While a description of the HAL is provided, its implementation
and composition will vary widely from radio to radio.</p>
</div>
<div class="section" id="hardware-presentation-layer-hpl">
<h1><a name="hardware-presentation-layer-hpl">Hardware Presentation Layer (HPL)</a></h1>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Implementation: platform dependent</p>
</li>
<li><p class="first">Presentation: radio dependent (common HPL for same radio)</p>
</li>
<li><p class="first">Mostly stateless, but may need to include some state to address race
conditions in event-driven operations and buffer swapping</p>
</li>
<li><dl class="first docutils">
<dt>HPL for control:</dt>
<dd><ul class="first last simple">
<li>Chipcon CC1000 register-based radios:
- read/write registers
- interrupts and timer capture events (general I/O)</li>
<li>Chipcon CC2420 buffer-based radios:
- read/write registers
- read/write RAM
- interrupts and timer capture events (general I/O)</li>
</ul>
</dd>
</dl>
</li>
</ol>
<blockquote>
<pre class="literal-block">
interface HPLCC2420
{
async command uint8_t cmd(uint8_t addr);
async command uint8_t write(uint8_t addr, uint16_t data);
async command uint16_t read(uint8_t addr);
}
// a subset of the capture provided by the hardware
interface HPLCC2420Capture
{
async command result_t enableCapture(bool low_to_high);
async event result_t captured(uint16_t val);
async command result_t disable();
}
</pre>
</blockquote>
<ol class="loweralpha" start="5">
<li><dl class="first docutils">
<dt>HPL for data</dt>
<dd><ul class="first last simple">
<li>Chipcon CC1000 register-based radios:
- read/write byte</li>
<li>Chipcon CC2420 buffer-based radios:
- read/write 128-byte FIFO</li>
</ul>
</dd>
</dl>
<pre class="literal-block">
interface HPLCC2420FIFO
{
async command cc2420_result_t readRXFIFO(uint8_t length, uint8_t *data);
async command cc2420_result_t writeTXFIFO(uint8_t length, uint8_t *data);
async event result_t RXFIFODone(uint8_t length, uint8_t *data, cc2420_result_t success);
async event result_t TXFIFODone(uint8_t length, uint8_t *data, cc2420_result_t success);
}
</pre>
</li>
<li><p class="first">The HPL interfaces reside in the radio's "chips" directory while
the underlying HPL implementations (*C, *M) reside in
a microcontroller or platform directory.</p>
</li>
</ol>
</blockquote>
</div>
<div class="section" id="hardware-adaptation-layer-hal">
<h1><a name="hardware-adaptation-layer-hal">Hardware Adaptation Layer (HAL)</a></h1>
<blockquote>
<ol class="loweralpha">
<li><p class="first">Implementation: microcontroller independent, radio dependent</p>
</li>
<li><p class="first">Presentation: radio dependent</p>
</li>
<li><p class="first">The HAL may be broken into a number of parts that communicate with
each other. As we approach the radio's interface
(whether it be bit, byte, or packet), translations may occur
on the data--coding, cryptography etc.
(see Figure 2 of RadioActive networks paper)</p>
<p>This PHY/MAC split currently exists in TinyOS with
portions of the Mica high speed radio stack. (see tinyos-1.x/doc)
Note that the Mica high speed radio stack provides a horizontal
component as well for CSMA. The same may exist for security
(ie: perform a translation on this packet for encryption).</p>
<p>The "MAC" is a separate configurable component that includes the
interfaces exposed to the AM/Comm layers. The PHY/MAC do not do
any packet filtering (including CRC).</p>
</li>
</ol>
</blockquote>
</div>
<div class="section" id="hardware-independent-layer-hil">
<h1><a name="hardware-independent-layer-hil">Hardware Independent Layer (HIL)</a></h1>
<blockquote>
<p>The "MAC" provides the typical send and receive packet interfaces.
Additionally, the MAC provides control interfaces similar to B-MAC,
including the ability to turn on or off CSMA, acks, and low power
listening:</p>
<pre class="literal-block">
interface CSMAControl
{
async command result_t enableCCA();
async command result_t disableCCA();
async command result_t enableAck();
async command result_t disableAck();
async command TOSMsg* HaltTx();
}
</pre>
<p>The units of the CSMA Backoff are <em>SYMBOL PERIODS</em> of the radio.
See the RadioControl interface below to convert symbol periods into
normal time units:</p>
<pre class="literal-block">
interface CSMABackoff
{
async event int16_t initial(TOSMsg* m);
async event int16_t congestion(TOSMsg* m);
}
</pre>
<p>Low Power Listening provides additional challenges as the notation
used for LPL changes from radio to radio. On an RFM, bit based
radio, LPL has no notion of long preambles. On the CC1000, a long
preamble is used for LPL. On the CC2420, cyclical packets must be
used for LPL (due to the HW constraints, long preambles are not an
option). A proposal:</p>
<pre class="literal-block">
interface LowPowerListening
{
async command result_t SetMode(lpl_mode_t mode);
async command lpl_mode_t GetMode();
async command result_t SetListeningMode(lpl_mode_t mode);
async command lpl_mode_t GetListeningMode();
async command result_t SetTransmitMode(lpl_mode_t mode);
async command lpl_mode_t GetTransmitMode();
}
</pre>
<p>The lpl_mode_t values are mapped by the specific radio implementation
to identical idle listening cost across platforms (cost when there
is no traffic on the channel). The TX cost may be higher, and must
be documented as to its value on each radio.</p>
<p>Additional HAL-level interface for Low Power Listening in a radio
dependent manner:</p>
<pre class="literal-block">
interface CC1000LowPowerListening
{
async command result_t SetPreambleLength(uint16_t bytes);
async command uint16_t GetPreambleLength();
async command result_t SetCheckInterval(uint16_t ms);
async command uint16_t GetCheckInterval();
}
</pre>
<p>The "mode" options provide a level of abstraction above the
CC1000 specific preamble-length and check-interface functions.
A generic mode setting interface may be provided separately from the
radio specific parameters that may be set.</p>
<p>Support for Time Synchronization services
Currently we have RadioCoordinator, put in place by UCLA and Kamin
Whitehouse. RadioCoordinator is renamed into an HIL interface
called RadioTimeStamping. It provides the time that an event occurred
and the message buffer being received at that start of frame
delimiter. The time value is always a 32768Hz 16-bit value .
CC1000RadioTimeStamping is an example of an expanded time HAL interface
specific to the CC1000 radio:</p>
<pre class="literal-block">
interface RadioTimeStamping
{
async event void SFD(uint16_t time, TOSMsg* msgBuff);
}
</pre>
<p>Each platform may be able to provide more information than just the
SFD timestamp. These platforms will have their own HAL interfaces
with additional time information:</p>
<pre class="literal-block">
interface CC1000RadioTimeStamping
{
async event void startSymbol(uint8_t bitsPerBlock, uint8_t offset, TOSMsg* msgBuff);
async event void byte(TOSMsg* msg, uint8_t byteCount);
async event void blockTimer();
}
</pre>
<p>The 16-bit "time" field of TOSMsg is the 16-bit 32768Hz timer value
corresponding to the SFD event. Upper layers are responsible for
expanding the 16-bit 32768Hz value into a larger 32-bit or 64-bit
value for higher level services.</p>
<p>Being able to control the radio independent of the underlying hardware
is extremely important for cross-platform applications. In the
RadioControl interface, we export a new notion of "TinyOS channels".
Each "TinyOS channel" is non-overlapping and the maximum number of
available channels on a platform are available through a command.
Likewise, output RF power is determined by a virtual scale from
0 to 255, where 0 is the radio's minimum output power and 255 is the
radio's maximum output power. Simple conversion functions allow
the user to convert dB values into the virtual scale and vice versa.
Radio timing information, such as bit, byte, and symbol times are
provided through the RadioControl interface. See the RadioControl
interface defintion in tinyos-2.x/tos/interfaces:</p>
<pre class="literal-block">
interface RadioControl
{
command result_t SetRFChannel(uint8_t channel);
command uint8_t GetRFChannel();
command uint8_t GetMaxChannels();
command result_t SetRFPower(uint8_t power);
command uint8_t GetRFPower();
command uint8_t RFtoDB(uint8_t power);
command uint8_t DBtoRF(int8_t dbm);
command uint16_t getTimeBit();
command uint16_t getTimeByte();
command uint16_t getTimeSymbol();
}
</pre>
<p>The TOSMsg structure is created such that each radio implementation
may define its own header, footer, and metadata. Since each
radio's layout will be distinct, common fields must be exposed
through a unified interface, known as RadioPacket.
Platform indpendent services use RadioPacket to access common
message fields; whereas platform dependent services directly
access the TOSMsg fields as defined by that radio implementation:</p>
<pre class="literal-block">
interface RadioPacket
{
command uint8_t getLength(TOSMsg* msg);
command result_t setLength(TOSMsg* msg, uint8_t length);
command uint8_t* getData(TOSMsg* msg);
command uint16_t getAddress(TOSMsg* msg);
command result_t setAddress(TOSMsg* msg, uint16_t addr);
command uint16_t getGroup(TOSMsg* msg);
command result_t setGroup(TOSMsg* msg, uint16_t group);
command uint16_t getTime(TOSMsg* msg);
command bool isAck(TOSMsg* msg);
}
</pre>
<p>The radio interfaces come together in the new RadioC module.
The interfaces described below are required by every RadioC module.
RadioC, for CSMA radios, is built above another configuration called
CSMARadioC to differentiate it from non-CSMA radios. For most operations,
users will wire to CSMARadioC; however RadioC provides a more general
fallback for cross-platform application development.
The configurations look like the following, such as
in tos/chips/CC2420:</p>
<pre class="literal-block">
configuration RadioC
{
provides
{
// split phase startup and shutdown of the radio
interface SplitControl;
// change frequency, power, etc.
interface RadioControl;
// send a message
interface Send;
// receive a message
interface Receive;
}
}
implementation
{
components CSMARadioC as CC2420RadioC;
SplitControl = CC2420RadioC;
RadioControl = CC2420RadioC;
Send = CC2420RadioC;
Receive = CC2420RadioC;
}
</pre>
<p>Then, if the radio supports CSMA, it also provides a
CSMARadioC configuration. Services wire to RadioC to be
radio-agnostic, and CSMARadioC if they wish to use the CSMA
control functionality but restrict their service's portability
to CSMA radios:</p>
<pre class="literal-block">
configuration CSMARadioC
{
provides
{
// split phase startup and shutdown of the radio
interface SplitControl;
// change frequency, power, etc.
interface RadioControl;
// send a message
interface Send;
// receive a message
interface ReceiveMsg as Receive;
// enable/disable csma, acks
interface CSMAControl;
// change the backoff on a per-packet basis
interface CSMABackoff;
// duty cycle the radio with preamble sampling
interface LowPowerListening;
}
}
implementation {
components CC2420RadioM ...
}
</pre>
</blockquote>
</div>
<div class="section" id="future-work">
<h1><a name="future-work">FUTURE WORK:</a></h1>
<p>Address interrupts and timer captures in a hardware-independent manner.
Allows elimination of HPLCC2420Capture and HPLCC2420Interrupt interfaces.</p>
</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">Joe Polastre</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">email - polastre AT cs.berkeley.edu</div>
</div>
</div>
</div>
</body>
</html>
Index: tep102.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/html/tep102.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep102.html 19 Jan 2005 22:14:33 -0000 1.1
--- tep102.html 31 Jan 2005 23:09:57 -0000 1.2
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.8: http://docutils.sourceforge.net/" />
<title>Timers</title>
<meta name="author" content="Cory Sharp" />
--- 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>Timers</title>
<meta name="author" content="Cory Sharp" />
***************
*** 296,302 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2005-01-19</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>
--- 296,302 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">22-Sep-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-24</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>
***************
*** 323,337 ****
system:</p>
<ul class="simple">
! <li>Low frequency alarms, synchronous, periodic and oneshot, for</li>
</ul>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 40)</p>
- Bullet list ends without a blank line; unexpected unindent.</div>
- <p>user/app timers
- * High frequency alarms, asynchronous, periodic and oneshot, for adc
- sampling
- * Stop watches, timing information
- * Local time, time origin
- * Time synchronization</p>
<p>Two fundamental properties of timers are <em>precision</em> and <em>resolution</em>.
Satisfying all possible precisions (milli, 32khz, micro, etc) and
--- 323,334 ----
system:</p>
<ul class="simple">
! <li>Low frequency alarms, synchronous, periodic and oneshot, for
! user/app timers</li>
! <li>High frequency alarms, asynchronous, periodic and oneshot, for adc
! sampling</li>
! <li>Stop watches, timing information</li>
! <li>Local time, time origin</li>
! <li>Time synchronization</li>
</ul>
<p>Two fundamental properties of timers are <em>precision</em> and <em>resolution</em>.
Satisfying all possible precisions (milli, 32khz, micro, etc) and
***************
*** 342,351 ****
the following about timer resolution</p>
<ul class="simple">
! <li>All exposed timer values should be unsigned 32-bit integers (uint32_t)</li>
</ul>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 56)</p>
- Bullet list ends without a blank line; unexpected unindent.</div>
- <p>regardless of precision</p>
<p>A single timer interface common across all precisions would enable subtle
wiring errors that are hard to detect at run-time. To prevent this, we
--- 339,345 ----
the following about timer resolution</p>
<ul class="simple">
! <li>All exposed timer values should be unsigned 32-bit integers (uint32_t)
! regardless of precision</li>
</ul>
<p>A single timer interface common across all precisions would enable subtle
wiring errors that are hard to detect at run-time. To prevent this, we
***************
*** 372,376 ****
<p>Five interfaces are presented:</p>
<ul class="simple">
! <li>TimeCount<frequency_tag></li>
<li>Alarm<frequency_tag></li>
<li>Timer<frequency_tag></li>
--- 366,370 ----
<p>Five interfaces are presented:</p>
<ul class="simple">
! <li>Counter<frequency_tag></li>
<li>Alarm<frequency_tag></li>
<li>Timer<frequency_tag></li>
***************
*** 379,384 ****
</ul>
<p>Low frequency alarms are satisfied by Timer<frequency_tag>, derived from
! one or more Alarm's. TinyOS will provide Timer<TMilli> and Timer<T32khz>
! through the standard timer component TimerC.</p>
<p>High frequency alarms are satisfied by TimerAsync<frequency_tag>, derived
from some number of Alarm's. TinyOS will provide TimerAsync<T32khz> and
--- 373,378 ----
</ul>
<p>Low frequency alarms are satisfied by Timer<frequency_tag>, derived from
! one or more Alarm's. TinyOS will provide Timer<TMilli> through the
! standard timer component TimerC.</p>
<p>High frequency alarms are satisfied by TimerAsync<frequency_tag>, derived
from some number of Alarm's. TinyOS will provide TimerAsync<T32khz> and
***************
*** 386,391 ****
TimerC.</p>
<p>Time elapsed measurements are provided by Stopwatch<frequency_tag>, which
! are derived from a TimeCount.</p>
! <p>Local time is provided by TimeCount. The time origin is relative to when
the mote was booted.</p>
<p>Time synchronization and the time origin are not addressed directly in
--- 380,385 ----
TimerC.</p>
<p>Time elapsed measurements are provided by Stopwatch<frequency_tag>, which
! are derived from a Counter.</p>
! <p>Local time is provided by Counter. The time origin is relative to when
the mote was booted.</p>
<p>Time synchronization and the time origin are not addressed directly in
***************
*** 476,494 ****
<li>Presentation: System independent</li>
<li>Async</li>
! <li>TimeCount<frequency_tag></li>
</ol>
<blockquote>
<ol class="lowerroman simple">
! <li>Get current time as a uint32_t in whatever units are specified by</li>
! </ol>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 167)</p>
! Enumerated list ends without a blank line; unexpected unindent.</div>
! <blockquote>
! the interface tag frequency_tag</blockquote>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 168)</p>
! Block quote ends without a blank line; unexpected unindent.</div>
! <ol class="lowerroman simple" start="2">
<li>Manage overflows</li>
</ol>
--- 470,479 ----
<li>Presentation: System independent</li>
<li>Async</li>
! <li>Counter<frequency_tag></li>
</ol>
<blockquote>
<ol class="lowerroman simple">
! <li>Get current time as a uint32_t in whatever units are specified by
! the interface tag frequency_tag</li>
<li>Manage overflows</li>
</ol>
***************
*** 500,525 ****
<ol class="lowerroman" start="3">
<li><p class="first">Interface:</p>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 174)</p>
! <p>Literal block expected; none found.</p>
! </div>
</li>
</ol>
- <blockquote>
- <p>interface TimeCount<frequency_tag>
- {</p>
- <div class="system-message">
- <p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep102.txt</tt>, line 176)</p>
- Unexpected indentation.</div>
- <blockquote>
- async command uint32_t get();
- async command bool isOverflowPending();
- async command bool clearOverflow();
- async event void overflow();</blockquote>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 180)</p>
- Block quote ends without a blank line; unexpected unindent.</div>
- <p>}</p>
- </blockquote>
</blockquote>
<ol class="loweralpha simple" start="5">
--- 485,499 ----
<ol class="lowerroman" start="3">
<li><p class="first">Interface:</p>
! <pre class="literal-block">
! interface Counter<frequency_tag>
! {
! async command uint32_t get();
! async command bool isOverflowPending();
! async command bool clearOverflow();
! async event void overflow();
! }
! </pre>
</li>
</ol>
</blockquote>
<ol class="loweralpha simple" start="5">
***************
*** 538,567 ****
</blockquote>
<ol class="lowerroman" start="3">
! <li><p class="first">The time base of an Alarm must correspond to an appropriate TimeCount</p>
</li>
<li><p class="first">Interface:</p>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 194)</p>
! <p>Literal block expected; none found.</p>
! </div>
</li>
</ol>
- <blockquote>
- <p>interface Alarm<frequency_tag>
- {</p>
- <div class="system-message">
- <p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep102.txt</tt>, line 196)</p>
- Unexpected indentation.</div>
- <blockquote>
- async command uint32_t get();
- async command bool isSet();
- async command void cancel();
- async command void set( uint32_t t0, uint32_t dt );
- async event void fired();</blockquote>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 201)</p>
- Block quote ends without a blank line; unexpected unindent.</div>
- <p>}</p>
- </blockquote>
<p>v. The AlarmC configuration exposes a distinct set of alarms
<em>required</em> by standard TinyOS components. This is necessary if the
--- 512,530 ----
</blockquote>
<ol class="lowerroman" start="3">
! <li><p class="first">The time base of an Alarm must correspond to an appropriate Counter</p>
</li>
<li><p class="first">Interface:</p>
! <pre class="literal-block">
! interface Alarm<frequency_tag>
! {
! async command uint32_t get();
! async command bool isSet();
! async command void cancel();
! async command void set( uint32_t t0, uint32_t dt );
! async event void fired();
! }
! </pre>
</li>
</ol>
<p>v. The AlarmC configuration exposes a distinct set of alarms
<em>required</em> by standard TinyOS components. This is necessary if the
***************
*** 622,664 ****
</ol>
<blockquote>
! <ol class="lowerroman simple">
! <li>Synchronous</li>
! <li>Parameterized by time precision</li>
! <li>Provides periodic and one shot timers</li>
! </ol>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 260)</p>
! Enumerated list ends without a blank line; unexpected unindent.</div>
! <p>iv. May have moderate computational overhead, probably all Timers for
a given timer precision are multiplexed from a single hardware
resource</p>
! <ol class="loweralpha" start="22">
<li><p class="first">Interface:</p>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 266)</p>
! <p>Literal block expected; none found.</p>
! </div>
</li>
</ol>
- <blockquote>
- <p>interface Timer<frequency_tag>
- {</p>
- <div class="system-message">
- <p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep102.txt</tt>, line 268)</p>
- Unexpected indentation.</div>
- <blockquote>
- command result_t setPeriodic( uint32_t dt );
- command result_t setOneShot( uint32_t dt );
- command result_t stop();
- command bool isSet();
- command bool isPeriodic();
- command bool isOneShot();
- command uint32_t getPeriod();
- event result_t fired();</blockquote>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 276)</p>
- Block quote ends without a blank line; unexpected unindent.</div>
- <p>}</p>
- </blockquote>
</blockquote>
<ol class="loweralpha simple" start="4">
--- 585,615 ----
</ol>
<blockquote>
! <ol class="lowerroman">
! <li><p class="first">Synchronous</p>
! </li>
! <li><p class="first">Parameterized by time precision</p>
! </li>
! <li><p class="first">Provides periodic and one shot timers</p>
! </li>
! <li><p class="first">May have moderate computational overhead, probably all Timers for
a given timer precision are multiplexed from a single hardware
resource</p>
! </li>
<li><p class="first">Interface:</p>
! <pre class="literal-block">
! interface Timer<frequency_tag>
! {
! command result_t setPeriodic( uint32_t dt );
! command result_t setOneShot( uint32_t dt );
! command result_t stop();
! command bool isSet();
! command bool isPeriodic();
! command bool isOneShot();
! command uint32_t getPeriod();
! event void fired();
! }
! </pre>
</li>
</ol>
</blockquote>
<ol class="loweralpha simple" start="4">
***************
*** 666,707 ****
</ol>
<blockquote>
! <ol class="lowerroman simple">
! <li>Asynchronous</li>
! <li>Parameterized by time precision</li>
! <li>Provides periodic and one shot timers</li>
! </ol>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 283)</p>
! Enumerated list ends without a blank line; unexpected unindent.</div>
! <p>iv. Should have minimal computational overhead, probably each
TimerAsync is based on a single hardware resource</p>
! <ol class="loweralpha" start="22">
<li><p class="first">Interface:</p>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 288)</p>
! <p>Literal block expected; none found.</p>
! </div>
</li>
</ol>
- <blockquote>
- <p>interface TimerAsync<frequency_tag>
- {</p>
- <div class="system-message">
- <p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep102.txt</tt>, line 290)</p>
- Unexpected indentation.</div>
- <blockquote>
- async command result_t setPeriodic( uint32_t dt );
- async command result_t setOneShot( uint32_t dt );
- async command result_t stop();
- async command bool isSet();
- async command bool isPeriodic();
- async command bool isOneShot();
- async command uint32_t getPeriod();
- async event result_t fired();</blockquote>
- <div class="system-message">
- <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 298)</p>
- Block quote ends without a blank line; unexpected unindent.</div>
- <p>}</p>
- </blockquote>
</blockquote>
<ol class="loweralpha simple" start="5">
--- 617,646 ----
</ol>
<blockquote>
! <ol class="lowerroman">
! <li><p class="first">Asynchronous</p>
! </li>
! <li><p class="first">Parameterized by time precision</p>
! </li>
! <li><p class="first">Provides periodic and one shot timers</p>
! </li>
! <li><p class="first">Should have minimal computational overhead, probably each
TimerAsync is based on a single hardware resource</p>
! </li>
<li><p class="first">Interface:</p>
! <pre class="literal-block">
! interface TimerAsync<frequency_tag>
! {
! async command result_t setPeriodic( uint32_t dt );
! async command result_t setOneShot( uint32_t dt );
! async command result_t stop();
! async command bool isSet();
! async command bool isPeriodic();
! async command bool isOneShot();
! async command uint32_t getPeriod();
! async event void fired();
! }
! </pre>
</li>
</ol>
</blockquote>
<ol class="loweralpha simple" start="5">
***************
*** 709,724 ****
</ol>
<blockquote>
! <ol class="lowerroman simple">
! <li>Asynchronous</li>
! <li>Parameterized by time precision</li>
! <li>Provides elapsed time readings from a specified start</li>
! <li>Indicates if an overflow occurred for the returned value</li>
! </ol>
! <div class="system-message">
! <p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep102.txt</tt>, line 306)</p>
! Enumerated list ends without a blank line; unexpected unindent.</div>
! <p>v. Stopwatches only depend on measurements from an appropriate
! TimeCount.
! v. Interface:</p>
<pre class="literal-block">
typedef struct
--- 648,664 ----
</ol>
<blockquote>
! <ol class="lowerroman">
! <li><p class="first">Asynchronous</p>
! </li>
! <li><p class="first">Parameterized by time precision</p>
! </li>
! <li><p class="first">Provides elapsed time readings from a specified start</p>
! </li>
! <li><p class="first">Indicates if an overflow occurred for the returned value</p>
! </li>
! <li><p class="first">Stopwatches only depend on measurements from an appropriate
! Counter.</p>
! </li>
! <li><p class="first">Interface:</p>
<pre class="literal-block">
typedef struct
***************
*** 735,738 ****
--- 675,680 ----
}
</pre>
+ </li>
+ </ol>
</blockquote>
</blockquote>
More information about the Tinyos-beta-commits
mailing list