-<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
-</tr>
</tbody>
</table>
<div class="note">
</tbody>
</table>
<div class="note">
@@ -342,13+334,12 @@ interrupt-driven sampling. All of its commands and events are async
and sensor values are always 16 bits, although only some subset of the
bits may be significant (e.g., a 12-bit value).</p>
<p>Because sensing is an integral part of high-level application logic,
and sensor values are always 16 bits, although only some subset of the
bits may be significant (e.g., a 12-bit value).</p>
<p>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
(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.</p>
+especially difficult to detect at low sampling rates.</p>
<p>Additionally, not all sensors require ADC conversions from the MCU.
Many sensors today are digital. To sample these sensors, the MCU sends
a sample command and receives the corresponding data over a bus (e.g.,
<p>Additionally, not all sensors require ADC conversions from the MCU.
Many sensors today are digital. To sample these sensors, the MCU sends
a sample command and receives the corresponding data over a bus (e.g.,
<tt class="docutils literal"><span class="pre">ReadWrite.readDone</span></tt> events is not SUCCESS, then the memory of the
<tt class="docutils literal"><span class="pre">val</span></tt> parameter MUST be filled with zeroes.</p>
<p>If the call to <tt class="docutils literal"><span class="pre">read</span></tt> has returned SUCCESS, but the <tt class="docutils literal"><span class="pre">readDone</span></tt>
<tt class="docutils literal"><span class="pre">ReadWrite.readDone</span></tt> events is not SUCCESS, then the memory of the
<tt class="docutils literal"><span class="pre">val</span></tt> parameter MUST be filled with zeroes.</p>
<p>If the call to <tt class="docutils literal"><span class="pre">read</span></tt> has returned SUCCESS, but the <tt class="docutils literal"><span class="pre">readDone</span></tt>
-event has not yet been signalled, then a subsequent call to <tt class="docutils literal"><span class="pre">read</span></tt>
+event has not yet been signaled, then a subsequent call to <tt class="docutils literal"><span class="pre">read</span></tt>
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.</p>
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.</p>
@@ -523,7+514,7 @@ drivers that may store the queue of buffers and count sizes by
building a linked list.</p>
<p>After posting at least one buffer, the client can call read() with a
specified sample period in terms of microseconds. The driver then
building a linked list.</p>
<p>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.</p>
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.</p>
@@ -570,12+561,12 @@ connect a sensor into a more general system.</p>