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

[Vlado Handziski]

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

Modified Files:
	tep2.txt 
Log Message:
Add reference to TEP116, clean Fig.3, fix docutils errors

Index: tep2.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep2.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep2.txt	28 Feb 2007 18:06:49 -0000	1.5
--- tep2.txt	28 Feb 2007 18:31:47 -0000	1.6
***************
*** 496,503 ****
  concept of a *HIL*. It also uses the following differentiation:
  
! - *platform-defined X* X is defined on all platforms, but the
    definition may be different
  
! - *platform-specific X* X is defined on just one platform
  
  
--- 496,503 ----
  concept of a *HIL*. It also uses the following differentiation:
  
! - *platform-defined X:* X is defined on all platforms, but the
    definition may be different
  
! - *platform-specific X:* X is defined on just one platform
  
  
***************
*** 505,515 ****
  ----------------
  
! *Strong Real HILs* mean that "code using these abstractions can
  reasonably be expected to behave the same on all implementations".
! This matches the original definition of the *HIL*-level according to
  the *HAA*.  Examples include the *HIL* for the Timer (TimerMilliC,
! [TEP102]_), for LEDs (LedsC), active messages (ActiveMessageC, if not
! using any radio metadata at least), sensor wrappers (DemoSensorC,
! [TEP109]_) or storage ([TEP103]_). Strong *HIL*s may use
  platform-defined types if they also provide operations to manipulate
  them (i.e., they are platform-defined abstract data types), for
--- 505,515 ----
  ----------------
  
! *Strong/Real HILs* mean that "code using these abstractions can
  reasonably be expected to behave the same on all implementations".
! This matches the original definition of the *HIL* level according to
  the *HAA*.  Examples include the *HIL* for the Timer (TimerMilliC,
! [TEP102]_), for LEDs (LedsC), active messages (ActiveMessageC,
! [TEP116]_, if not using any radio metadata at least), sensor wrappers
! (DemoSensorC, [TEP109]_) or storage ([TEP103]_). Strong *HILs* may use
  platform-defined types if they also provide operations to manipulate
  them (i.e., they are platform-defined abstract data types), for
***************
*** 534,542 ****
  readings.
  
! The benefit from weak *HIL* are that one can write portable utility
  code, e.g., a repeated sampling for an ADC on top of the data path.
  While code using these abstractions may not be fully portable, it will
! still be easier to port than code built on top of *HAL*s, because weak
! *HIL*s involve some guidelines on how to expose some functionality,
  which should help programmers and provide guidance to platform
  developers.
--- 534,542 ----
  readings.
  
! The benefit from weak *HILs* are that one can write portable utility
  code, e.g., a repeated sampling for an ADC on top of the data path.
  While code using these abstractions may not be fully portable, it will
! still be easier to port than code built on top of *HALs*, because weak
! *HILs* involve some guidelines on how to expose some functionality,
  which should help programmers and provide guidance to platform
  developers.
***************
*** 646,649 ****
--- 646,651 ----
              Levis, "Power Management of Non-Virtualised Devices"
  
+ .. [TEP116] Philip Levis, "Packet Protocols"
+ 
  .. [TEP117] Phil Buonadonna, Jonathan Hui, "Low-Level I/O"