[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep111.txt, 1.1.2.9, 1.1.2.10

Fri Jun 9 10:57:47 PDT 2006

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

Modified Files:
      Tag: tinyos-2_0_devel-BRANCH
	tep111.txt 
Log Message:
Fixed citations.

Index: tep111.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/Attic/tep111.txt,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -C2 -d -r1.1.2.9 -r1.1.2.10
*** tep111.txt	1 Jun 2006 19:31:39 -0000	1.1.2.9
--- tep111.txt	9 Jun 2006 17:57:45 -0000	1.1.2.10
***************
*** 32,39 ****
  ====================================================================

! In TinyOS 1.x, a message buffer is a TOS_Msg. A buffer contains an
  active message (AM) packet as well as packet metadata, such as timestamps,
  acknowledgement bits, and signal strength if the packet was received.
! TOS_Msg is a fixed size structure whose size is defined by the maximum
  AM payload length (the default is 29 bytes). Fixed sized buffers allows
  TinyOS 1.x to have zero-copy semantics: when a component receives a
--- 32,39 ----
  ====================================================================

! In TinyOS 1.x, a message buffer is a ``TOS_Msg``. A buffer contains an
  active message (AM) packet as well as packet metadata, such as timestamps,
  acknowledgement bits, and signal strength if the packet was received.
! ``TOS_Msg`` is a fixed size structure whose size is defined by the maximum
  AM payload length (the default is 29 bytes). Fixed sized buffers allows
  TinyOS 1.x to have zero-copy semantics: when a component receives a
***************
*** 42,55 ****
  packet.

! One issue that arises is what defines the TOS_Msg structure, as different
  link layers may require different layouts. For example, 802.15.4 radio 
  hardware (such as the CC2420, used in the Telos and micaZ platforms) 
  may require 802.15.4 headers, while a software stack built on top of
  byte radios (such as the CC1000, used in the mica2 platform) can specify 
! its own packet format. This means that TOS_Msg may be different on
  different platforms.

  The solution to this problem in TinyOS 1.x is for there to be a standard
! definition of TOS_Msg, which a platform (e.g., the micaZ) can
  redefine to match its radio. For example, a mica2 mote uses the standard 
  definition, which is::
--- 42,55 ----
  packet.

! One issue that arises is what defines the ``TOS_Msg`` structure, as different
  link layers may require different layouts. For example, 802.15.4 radio 
  hardware (such as the CC2420, used in the Telos and micaZ platforms) 
  may require 802.15.4 headers, while a software stack built on top of
  byte radios (such as the CC1000, used in the mica2 platform) can specify 
! its own packet format. This means that ``TOS_Msg`` may be different on
  different platforms.

  The solution to this problem in TinyOS 1.x is for there to be a standard
! definition of ``TOS_Msg``, which a platform (e.g., the micaZ) can
  redefine to match its radio. For example, a mica2 mote uses the standard 
  definition, which is::
***************
*** 76,80 ****
    } TOS_Msg;

! while on a mote with a CC420 radio (e.g., micaZ), TOS_Msg is defined as::

    typedef struct TOS_Msg {
--- 76,80 ----
    } TOS_Msg;

! while on a mote with a CC420 radio (e.g., micaZ), ``TOS_Msg`` is defined as::

    typedef struct TOS_Msg {
***************
*** 108,112 ****
  and the structure layout. For example, many network services built on
  top of data link layers care whether sent packets are acknowledged. They
! therefore check the ``ack`` field of TOS_Msg. If a link layer does not 
  provide acknowledgements, it must still include the ``ack`` field
  and always set it to 0, wasting a byte of RAM per buffer.
--- 108,112 ----
  and the structure layout. For example, many network services built on
  top of data link layers care whether sent packets are acknowledged. They
! therefore check the ``ack`` field of ``TOS_Msg``. If a link layer does not 
  provide acknowledgements, it must still include the ``ack`` field
  and always set it to 0, wasting a byte of RAM per buffer.
***************
*** 116,120 ****
  defined in the structure and directly access them. If a platform
  has two different link layers (e.g., a CC1000 *and* a CC2420 radio),
! then a TOS_Msg needs to allocate the right amount of space for both
  of their headers while allowing implementations to directly access
  header fields. This is very difficult to do in C.
--- 116,120 ----
  defined in the structure and directly access them. If a platform
  has two different link layers (e.g., a CC1000 *and* a CC2420 radio),
! then a ``TOS_Msg`` needs to allocate the right amount of space for both
  of their headers while allowing implementations to directly access
  header fields. This is very difficult to do in C.
***************
*** 125,129 ****
  preceding it might have different lengths, and packet-level radios
  often require packets to be contiguous memory regions. Overall, these 
! complexities make specifying the format of TOS_Msg very difficult.

  2. message_t
--- 125,129 ----
  preceding it might have different lengths, and packet-level radios
  often require packets to be contiguous memory regions. Overall, these 
! complexities make specifying the format of ``TOS_Msg`` very difficult.

  2. message_t
***************
*** 187,191 ****
  named ``platform_message.h``. The mica2 platform, for example, has
  two data link layers: the CC1000 radio and the TinyOS serial
! stack (TEP 113). The serial packet format does not have a footer
  or metadata section. The ``platform_message.h`` of the mica2
  looks like this::
--- 187,191 ----
  named ``platform_message.h``. The mica2 platform, for example, has
  two data link layers: the CC1000 radio and the TinyOS serial
! stack [1]_. The serial packet format does not have a footer
  or metadata section. The ``platform_message.h`` of the mica2
  looks like this::
***************
*** 248,252 ****
  The most basic of these interfaces is Packet, which provides
  access to a packet payload. TEP 116 describes common TinyOS 
! packet ADT interfaces. 

  Link layer components MAY access packet fields differently than other 
--- 248,252 ----
  The most basic of these interfaces is Packet, which provides
  access to a packet payload. TEP 116 describes common TinyOS 
! packet ADT interfaces [2]_. 

  Link layer components MAY access packet fields differently than other 
***************
*** 277,281 ****
  a 12-byte serial packet on the Telos platform::

!               11 bytes         TOSH_DATA_LENGTH           7 bytes
              +-----------+-----------------------------+-------+
    message_t |  header   |          data               | meta  |
--- 277,281 ----
  a 12-byte serial packet on the Telos platform::

!               11 bytes         TOSH_DATA_LENGTH        7 bytes
              +-----------+-----------------------------+-------+
    message_t |  header   |          data               | meta  |
***************
*** 394,398 ****
  ====================================================================

! .. [tep113] TEP 113: Serial Communication.
! .. [tep116] TEP 116: Packet Protocols.

--- 394,400 ----
  ====================================================================

! .. [1] TEP 113: Serial Communication.
! 
! .. [2] TEP 116: Packet Protocols.
! 