[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep113.txt,1.6,1.7

[Ben Greenstein]

Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv11231/doc/txt

Modified Files:
	tep113.txt 
Log Message:
cleaned up document


Index: tep113.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep113.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep113.txt	24 Jan 2007 17:18:20 -0000	1.6
--- tep113.txt	6 Feb 2007 02:39:43 -0000	1.7
***************
*** 39,43 ****
  
  Users need to read data out of a TinyOS network. The most common
! approach is to attach a mote to a PC or latop with a wired
  connection. While the interface on the PC side can vary from a serial
  cable to a USB device to IP, the mote generally talks to a serial port
--- 39,43 ----
  
  Users need to read data out of a TinyOS network. The most common
! approach is to attach a mote to a PC or laptop with a wired
  connection. While the interface on the PC side can vary from a serial
  cable to a USB device to IP, the mote generally talks to a serial port
***************
*** 48,54 ****
  support multiple UART packet formats simultaneously.  This allows
  transparent bridging (e.g., an 802.15.4 base station) to exist in
! parallel with platform-independent communication, which allows
! simplifies the PC toolchain. This memo documents the protocols and
! structure of the TinyOS 2.x serial communication stack.
  
  2. Serial Stack Structure
--- 48,54 ----
  support multiple UART packet formats simultaneously.  This allows
  transparent bridging (e.g., an 802.15.4 base station) to exist in
! parallel with platform-independent communication, which simplifies the
! PC toolchain. This memo documents the protocols and structure of the
! TinyOS 2.x serial communication stack.
  
  2. Serial Stack Structure
***************
*** 94,98 ****
  The lowest level of the stack is the raw UART. This HIL component
  provides functionality for configuring the UART (speed, stop bytes,
! etc.) as well as sending/receiving bytes.
  
  The Encoder/Framer sits above the raw UART. This component translates
--- 94,98 ----
  The lowest level of the stack is the raw UART. This HIL component
  provides functionality for configuring the UART (speed, stop bytes,
! etc.), sending/receiving bytes, and flushing the UART.
  
  The Encoder/Framer sits above the raw UART. This component translates
***************
*** 124,128 ****
  
  Section 2 describes the basic structure of the TinyOS 2.x serial
! stack structure. This section describes its actual implementation,
  including SerialActiveMessageC, which sits on top of the Dispatcher.
  All of the components except for UartC are part of the serial
--- 124,128 ----
  
  Section 2 describes the basic structure of the TinyOS 2.x serial
! stack. This section describes its actual implementation,
  including SerialActiveMessageC, which sits on top of the Dispatcher.
  All of the components except for UartC are part of the serial
***************
*** 159,164 ****
  
    interface SerialFlush {
!     async command void flush();
!     async event void flushDone();
    }
  
--- 159,164 ----
  
    interface SerialFlush {
!     command void flush();
!     event void flushDone();
    }
  
***************
*** 216,222 ****
  management are left to higher layers in the serial stack. The protocol
  is currently stop-and-wait in the host-to-mote direction and best
! effort in the mote-to-host direction. The first performance upgrade of
! this module will be to implement sliding window reliability in both
! directions.
  
  SerialP provides two byte-level interfaces to the upper layer for
--- 216,220 ----
  management are left to higher layers in the serial stack. The protocol
  is currently stop-and-wait in the host-to-mote direction and best
! effort in the mote-to-host direction. 
  
  SerialP provides two byte-level interfaces to the upper layer for
***************
*** 226,235 ****
  On the sending side, SerialP is responsible for encapsulation of upper
  layer packets. An upper layer component such as SerialDispatcherC
! initiates the sending of a packet by calling startSend, passing the
  first byte to send. SerialP collects subsequent bytes by signalling
! nextByte. Within the nextByte handler or between calls to nextByte,
  the upper layer should indicate the end-of-packet by calling
! completeSend. If completeSend is called from within a nextByte
! handler, SerialP will ignore the return of the call to nextByte.
  
  ::
--- 224,233 ----
  On the sending side, SerialP is responsible for encapsulation of upper
  layer packets. An upper layer component such as SerialDispatcherC
! initiates the sending of a packet by calling startSend(), passing the
  first byte to send. SerialP collects subsequent bytes by signalling
! nextByte(). Within the nextByte handler or between calls to nextByte(),
  the upper layer should indicate the end-of-packet by calling
! completeSend(). If completeSend is called from within a nextByte()
! handler, SerialP will ignore the return of the call to nextByte().
  
  ::
***************
*** 245,258 ****
  the upper layer and not yet sent to the UART. Depending on the timing
  requirements of the underlying UART, the size of this window can be
! changed.  SerialP uses repeated calls to nextByte to keep this window
  filled.
  
! SerialP uses SerialFrameComm to send a delimiter between frames, 
! a serial-level type field, the bytes of the packet, and a two-byte
! frame CRC. For mote-to-host gap detection and link reliability, a
! sequence number may also be sent (not currently activated).
  
! After sending an entire frame and receiving the last putDone event
! from below, SerialP signals sendCompleted to indicate the success or
  failure of a requested transmission.
  
--- 243,256 ----
  the upper layer and not yet sent to the UART. Depending on the timing
  requirements of the underlying UART, the size of this window can be
! changed.  SerialP uses repeated calls to nextByte() to keep this window
  filled.
  
! SerialP uses SerialFrameComm to send a delimiter between frames, a
! serial-level type field, the bytes of the packet, and a two-byte frame
! CRC. For mote-to-host gap detection and link reliability, a sequence
! number may also be sent (not activated in the default implementation).
  
! After sending an entire frame and receiving the last putDone() event
! from below, SerialP signals sendCompleted() to indicate the success or
  failure of a requested transmission.
  
***************
*** 270,274 ****
  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
--- 268,272 ----
  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
***************
*** 311,320 ****
  When SerialDispatcherC receives the first data byte of a packet from
  SerialP, it stores it as the packet type and calls
! SerialPacketInfo.offset() to determine where in a message_t that
  packet format begins. It then spools data bytes in, filling them into
  its message_t buffer. Similarly, on the send side, it first sends the
  type byte and spools out data bytes starting from the index denoted by
  the call to offset(). SerialDispatcherC uses the two length commands,
! dataLinkLength and upperLength, to translate between the two notions
  of packet length: above, length refers to the payload excluding
  header, while below it refers to the payload plus header.
--- 309,318 ----
  When SerialDispatcherC receives the first data byte of a packet from
  SerialP, it stores it as the packet type and calls
! offset() to determine where in a message_t that
  packet format begins. It then spools data bytes in, filling them into
  its message_t buffer. Similarly, on the send side, it first sends the
  type byte and spools out data bytes starting from the index denoted by
  the call to offset(). SerialDispatcherC uses the two length commands,
! dataLinkLength() and upperLength(), to translate between the two notions
  of packet length: above, length refers to the payload excluding
  header, while below it refers to the payload plus header.
***************
*** 438,442 ****
  implementation schedulers the packets in these queues using some form
  of fair-share queueing. SerialAMReceiverC provides the virtualized
! abstraction for reception. These abstraction are very similar to
  TinyOS's radio abstractions, namely, AMSenderC and AMReceiverC. See
  Section 4 of TEP 116[TEP116_] for more information. Unlike the
--- 436,440 ----
  implementation schedulers the packets in these queues using some form
  of fair-share queueing. SerialAMReceiverC provides the virtualized
! abstraction for reception. These abstractions are very similar to
  TinyOS's radio abstractions, namely, AMSenderC and AMReceiverC. See
  Section 4 of TEP 116[TEP116_] for more information. Unlike the