From: scipio Date: Wed, 2 Jul 2008 19:38:46 +0000 (+0000) Subject: Spelling errors, removed "asynchronicity", cut down on verbiage in intro. X-Git-Tag: release_tinyos_2_1_0_0~117 X-Git-Url: https://oss.titaniummirror.com/gitweb/?p=tinyos-2.x.git;a=commitdiff_plain;h=a7909413602e026f1e03a29a4a314fde7d9d4376 Spelling errors, removed "asynchronicity", cut down on verbiage in intro. --- diff --git a/doc/txt/tep114.txt b/doc/txt/tep114.txt index c1f8b116..c2e646cb 100644 --- a/doc/txt/tep114.txt +++ b/doc/txt/tep114.txt @@ -5,8 +5,7 @@ SIDs: Source and Sink Independent Drivers :TEP: 114 :Group: Core Working Group :Type: Documentary -:Status: Draft -:TinyOS-Version: 2.x +:Status: Final :Author: Gilman Tolle, Philip Levis, and David Gay :Draft-Created: 30-Oct-2005 @@ -54,13 +53,12 @@ and sensor values are always 16 bits, although only some subset of the bits may be significant (e.g., a 12-bit value). Because sensing is an integral part of high-level application logic, -the asynchronicity of these events means that high-level components -must work with atomic section, even if the sampling rate is very low +having asynchronous events means that high-level components +must work with atomic sections, even if the sampling rate is very low (e.g., every five minutes) and so could be easily placed in a task. Race conditions are problematic and possible in any real time multi-tasking design. Race conditions are a failure in design, and -especially difficult to detect at low sampling rates. Careful and -skillful design review practices flush out race conditions early on. +especially difficult to detect at low sampling rates. Additionally, not all sensors require ADC conversions from the MCU. Many sensors today are digital. To sample these sensors, the MCU sends @@ -135,7 +133,7 @@ If the ``result`` parameter of the ``Read.readDone`` and ``val`` parameter MUST be filled with zeroes. If the call to ``read`` has returned SUCCESS, but the ``readDone`` -event has not yet been signalled, then a subsequent call to ``read`` +event has not yet been signaled, then a subsequent call to ``read`` MUST return EBUSY or FAIL. This simple locking technique, as opposed to a more complex system in which multiple read/readDone pairs may be outstanding, is intended to reduce the complexity of SID client code. @@ -230,7 +228,7 @@ building a linked list. After posting at least one buffer, the client can call read() with a specified sample period in terms of microseconds. The driver then -begins to fill the buffers in the queue, signalling the bufferDone() +begins to fill the buffers in the queue, signaling the bufferDone() event when a buffer has been filled. The client MAY call postBuffer() after read() in order to provide the device with new storage for future reads.