[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep109.txt, 1.1.2.7, 1.1.2.8

[Gilman Tolle]

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

Modified Files:
      Tag: tinyos-2_0_devel-BRANCH
	tep109.txt 
Log Message:
Took out some confusing wording about 'sensorboard directory' in the intro. Added an explicit reference to the arbiter TEP and a link to the example in the appendix. Fixed a typo that left out the 'chips' directory.

Index: tep109.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep109.txt,v
retrieving revision 1.1.2.7
retrieving revision 1.1.2.8
diff -C2 -d -r1.1.2.7 -r1.1.2.8
*** tep109.txt	6 Dec 2006 18:35:28 -0000	1.1.2.7
--- tep109.txt	10 Jan 2007 18:03:33 -0000	1.1.2.8
***************
*** 58,63 ****
  allows the compilation process to minimize the amount of code
  included. A sensor board containing multiple sensors SHOULD be
! represented as a collection of components, one for each sensor,
! contained within a sensor board directory.
  
  Sensors, being physical devices that can be shared, can benefit from
--- 58,62 ----
  allows the compilation process to minimize the amount of code
  included. A sensor board containing multiple sensors SHOULD be
! represented as a collection of components, one for each sensor. 
  
  Sensors, being physical devices that can be shared, can benefit from
***************
*** 103,110 ****
  access to the sensor. A sensor device driver can provide such
  virtualization for itself by defining a nesC generic client
! component. When a client component is being used, a call to a
! top-level SID interface SHOULD be delayed when the device is busy,
! rather than failing. Using one of the system arbiters can make the
! implementation of this requirement easier to accomplish.
  
  For example::
--- 102,106 ----
  access to the sensor. A sensor device driver can provide such
  virtualization for itself by defining a nesC generic client
! component. 
  
  For example::
***************
*** 123,126 ****
--- 119,128 ----
    }
  
+ When a client component is being used, a call to a top-level SID
+ interface should be delayed when the device is busy, rather than
+ failing. This virtualization may be easier to accomplish by using one
+ of the arbiters provided by the system [TEP108]_, as shown in the
+ `arbiter example`_ in Appendix A, Section 3.
+ 
  When a HIL component is being used, the sensor MUST initialize itself,
  either by including the `MainC` component and wiring to the
***************
*** 291,295 ****
  Sensors that exist as part of a larger chip, like a MCU internal
  voltage sensor, SHOULD be placed in a subdirectory of the chip's
! directory. "tos/<chip>/sensors/<sensor>".
  
  The `.platform` and `.sensor` files need to include enough `-I`
--- 293,297 ----
  Sensors that exist as part of a larger chip, like a MCU internal
  voltage sensor, SHOULD be placed in a subdirectory of the chip's
! directory. "tos/chips/<chip>/sensors/<sensor>".
  
  The `.platform` and `.sensor` files need to include enough `-I`
***************
*** 349,352 ****
--- 351,355 ----
  
  .. [TEP2] TEP 2: Hardware Abstraction Architecture
+ .. [TEP108] TEP 108: Resource Arbitration
  .. [TEP114] TEP 114: SIDs: Source and Sink Indepedent Drivers
  .. [TEP115] TEP 115: Power Management of Non-Virtualized Devices
***************
*** 712,715 ****
--- 715,720 ----
    
    }
+ 
+ This section includes an _`arbiter example`.
    
  ::