X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=doc%2Fhtml%2Ftep113.html;h=4bcc3f8000016441b8e28fffe038a2a0fbe9329b;hb=280c1821f287389e7d13ee048e0f3a28927d1302;hp=1d0a36eeffd2df7f16c27d73b2e5173e7a10debb;hpb=ace2e1376f6c85defb0a5fe22ca43456a796ce05;p=tinyos-2.x.git diff --git a/doc/html/tep113.html b/doc/html/tep113.html index 1d0a36ee..4bcc3f80 100644 --- a/doc/html/tep113.html +++ b/doc/html/tep113.html @@ -41,11 +41,6 @@ blockquote.epigraph { 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 } @@ -296,19 +291,11 @@ ul.auto-toc {
Only the PC-to-mote communication path supports acknowledgements. +SerialP does not request acknowledgements from the PC for two reasons. +First, acks are not perfect reliable: they are used on the +PC-to-mote path to raise reliability to a usable level. In the case of +the PC-to-mote path, the UART receive buffer is typically a single +byte, so a high interrupt load can easily lose (and sometimes does) a +byte. This is in contrast to the PC receive buffer, which is much +larger and does not have to deal with overflow. Second, adding support +for acks would increase the code size and complexity of the serial +stack. As code space is often at a premium, this would add little +needed functionality at significant cost. Of course, any application +that requires perfect reliability may layer its own scheme on top of +the serial protocol.
+The acknowledgement protocol is stop-and-wait to minimize buffering on +the mote side. This is considered more important on memory constrained +devices than increased throughput in the PC-to-mote direction, which +most applications only use for occasional control transmissions.