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

[Phil Levis]

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

Modified Files:
	tep116.txt 
Log Message:
Incorporated comments.


Index: tep116.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep116.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep116.txt	28 Feb 2007 22:33:28 -0000	1.6
--- tep116.txt	14 Mar 2007 01:50:40 -0000	1.7
***************
*** 95,99 ****
  *Send* interfaces are for transmitting packets, and are
  distinguished by their addressing scheme. 
! Finally, the *Receive* interface is for handling packet reception events.
  
  2.1 Packet interfaces
--- 95,102 ----
  *Send* interfaces are for transmitting packets, and are
  distinguished by their addressing scheme. 
! The *Receive* interface is for handling packet reception events.
! Finally, depending on whether the protocol has a dispatch identifier
! field, the Receive and Send interfaces may be parameterized in order
! to support multiple higher-level clients.
  
  2.1 Packet interfaces
***************
*** 270,273 ****
--- 273,294 ----
  both Packet and the sending interface for basic use cases.
  
+ When called with a length that is too long for the underlying
+ maximum transfer unit (MTU), the send command MUST return ESIZE.
+ 
+ The ``Send`` and ``AMSend`` interfaces have an explicit queue of
+ depth one. A call to ``send`` on either of these interfaces MUST 
+ return EBUSY if a prior call to ``send`` returned SUCCESS but no
+ ``sendDone`` event has been signaled yet. More explicitly::
+ 
+   if (call Send.send(...) == SUCCESS &&
+       call Send.send(...) == SUCCESS) {
+      // This block is unreachable.
+   }
+ 
+ Systems that need send queues have two options. They can
+ use a QueueC (found in tos/system) to store pending packet pointers
+ and serialize them onto sending interface, or they can introduce
+ a new sending interface that supports multiple pending transmissions.
+ 
  2.3 Receive interface
  --------------------------------------------------------------------
***************
*** 310,316 ****
  handles a receive event:
  
! 1) Return ``msg`` without touching it.
! 2) Copy some data out of ``payload`` and return ``msg``.
! 3) Store ``msg`` in its local frame and return a different ``message_t*`` for the lower layer to use.
  
  These are simple code examples of the three cases::
--- 331,337 ----
  handles a receive event:
  
!   1) Return ``msg`` without touching it.
!   2) Copy some data out of ``payload`` and return ``msg``.
!   3) Store ``msg`` in its local frame and return a different ``message_t*`` for the lower layer to use.
  
  These are simple code examples of the three cases::
***************
*** 351,356 ****
  
  A packet protocol MAY have a dispatch identifier. This generally manifests
! as the protocol component provided parameterized interfaces (rather than
! a single interface instances). A dispatch identifier allows multiple 
  services to use a protocol independently. If a protocol provides a
  dispatch mechanism, then each dispatch identifier SHOULD correspond to
--- 372,377 ----
  
  A packet protocol MAY have a dispatch identifier. This generally manifests
! as the protocol component providing parameterized interfaces (rather than
! a single interface instance). A dispatch identifier allows multiple 
  services to use a protocol independently. If a protocol provides a
  dispatch mechanism, then each dispatch identifier SHOULD correspond to
***************
*** 488,492 ****
  AMSnooperC, or AMReceiverC with the same am_id_t.
  
! 4.5 AMSender 
  --------------------------------------------------------------------
  
--- 509,513 ----
  AMSnooperC, or AMReceiverC with the same am_id_t.
  
! 4.5 AMSenderC 
  --------------------------------------------------------------------
  
***************
*** 510,514 ****
  available transmission bandwidth.
  
! 4.6 Power Management
  --------------------------------------------------------------------
  
--- 531,542 ----
  available transmission bandwidth.
  
! 5. Power Management and Local Address
! ============================================================================
! 
! In addition to standard datapath interfaces for sending and
! receiving packets, an active message layer also has control interfaces.
! 
! 
! 5.1 Power Management
  --------------------------------------------------------------------
  
***************
*** 521,524 ****
--- 549,564 ----
  "on."
  
+ 5.2 Local Active Message Address
+ --------------------------------------------------------------------
+ 
+ An application can change ActiveMessageC's local AM address 
+ at runtime. This will change which packets a node receives and
+ the source address it embeds in packets. To change the local AM
+ address at runtime, a component can wire to the component
+ ``ActiveMessageAddressC``. This component only changes the
+ AM address of the default radio stack (AMSenderC, etc.); if
+ a radio has multiple stacks those may have other components
+ for changing their addresses in a stack-specific fashion.
+ 
  5. HAL Requirements
  ============================================================================