Add SharedSplitControlC, for N clients needing shared access to something.

[tinyos-2.x.git] / doc / txt / tep113.txt

diff --git a/doc/txt/tep113.txt b/doc/txt/tep113.txt
index eec500426994d2a035973fa0c816fd7e60e55cc8..c631df7c2cacb5db2ef774e4c64924a733575b5a 100644 (file)
--- a/doc/txt/tep113.txt
+++ b/doc/txt/tep113.txt
@@ -5,15 +5,10 @@ Serial Communication
 :TEP: 113
 :Group: Core Working Group 
 :Type: Documentary
-:Status: Draft
+:Status: Final
 :TinyOS-Version: 2.x
 :Author: Ben Greenstein and Philip Levis
 
-:Draft-Created: 11-Jul-2005
-:Draft-Version: $Revision$
-:Draft-Modified: $Date$
-:Draft-Discuss: TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>
-
 .. Note::
 
    This memo documents a part of TinyOS for the TinyOS Community, and
@@ -162,9 +157,8 @@ but NOT that the UART is idle.
     event void flushDone();
   }
 
-It also provides interfaces for configuring the serial port. *NOTE:
-These are not codified yet, and so working out the UART HIL seems like
-a good idea.*
+It may provide additional interfaces for configuring the serial
+port. This TEP does not consider this topic.
 
 
 3.2 Encoder/Framer: HdlcTranslateC
@@ -267,14 +261,10 @@ provided to the upper layer is ReceiveBytePacket:
 
 Upon receiving an interframe delimiter and a new frame's header,
 SerialP signals the upper layer indicating that a packet is
-arriving. For each byte received, SerialP signals byteReceived(). (Note:
-SerialP signals on byte k-2 when byte k arrives, because the
-implementation precludes it from knowing when it has encountered the
-2-byte CRC in the frame footer until after it has received it. Lagging
-behind by two bytes makes it possible to hide all frame details from
-the upper layer.) Once SerialP receives the complete frame it signals
-endPacket with a value of SUCCESS. If instead it loses sync during
-reception it signals endPacket with FAIL.
+arriving. For each byte received, SerialP signals byteReceived().
+Once SerialP receives the complete frame it signals endPacket with a
+value of SUCCESS. If instead it loses sync during reception it signals
+endPacket with FAIL.
 
 SerialP acknowledges frames it receives. Acknowledgements have a
 higher priority than data transmissions and consequently, data frames
@@ -283,6 +273,25 @@ stored in a queue separate from the data buffer, so a data packet to
 be transmitted may begin spooling into SerialP while SerialP is
 actively sending an acknowledgement.
 
+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.
+
 
 3.4 Dispatcher: SerialDispatcherC
 --------------------------------------------------------------------
@@ -472,6 +481,8 @@ no snooping capabilities.
 
 .. [TEP116] TEP 116: Packet Protocols. tinyos-2.x/doc/txt/tep116.txt
  
+.. [TEP117] TEP 117: Low-Level I/O. tinyos-2.x/doc/txt/tep117.txt
+
 .. [HDLC] International Organization For Standardization, ISO Standard 3309-1979, "Data communication - High-level data link control procedures - Frame structure", 1979.
 
 .. [RFC1662] PPP in HDLC-like Framing, Internet Engineering Task Force (IETF), 1994