[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep108.txt, 1.3, 1.4

[David Gay]

Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2686

Modified Files:
	tep108.txt 
Log Message:
virtualised+reserved resources
cross-component reservation (e.g., ti msp 430 uart+spi+i2c)


Index: tep108.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep108.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep108.txt	31 Mar 2005 22:02:42 -0000	1.3
--- tep108.txt	19 Apr 2005 22:07:55 -0000	1.4
***************
*** 98,101 ****
--- 98,103 ----
  ====================================================================
  
+ The resource interface is defined as follows:
+ 
  interface Resource {
    /**
***************
*** 125,135 ****
  }
  
! The Resource interface is offered as a parameterised interface by
! services which wish to provide access to a shared resource. The
! interface's parameter represents client ids, which clients can obtain
! via the special unique() function. For instance, the I2C service might
! look like this:
  
! #define I2C_RESOURCE "I2C.Resource"
  configuration I2CPacketC {
    provides {
--- 127,138 ----
  }
  
! This Resource interface is offered as a parameterised interface by services
! which wish to provide access to a shared resource. The interface's
! parameter represents client ids. A component SomeNameC must #define
! SOME_NAME_RESOURCE to a string which can be passed to the special unique()
! function to obtain a client id. For instance, the I2C service might look
! like this:
  
! #define I2CPACKET_RESOURCE "I2CPacket.Resource"
  configuration I2CPacketC {
    provides {
***************
*** 167,170 ****
--- 170,205 ----
  reservation is purely a reservation of the software component itself.
  
+ 3.1 Cross-component reservation
+ -------------------------------
+ 
+ In some cases, it is desireable to share reservation of resources across
+ components. For example, on the TI MSP 430, the same pins can be used as
+ an I2C bus, a UART, or an SPI connection. Clearly, on this chip, a reservation
+ of the I2C bus implicitly reserves the corresponding UART and SPI. This can
+ be accomplished in the framework described above by:
+ 1) using the same unique string for all three resources
+ 2) wiring the three parameterised Resource interfaces to the same arbiter
+ 
+ This could be done as follows (the UART and SPI components are omitted, they
+ are similar to I2CC):
+ I2CC.nc (a low-level I2C component):
+ #define I2C_RESOURCE MSP_BUS_RESOURCE
+ configuration I2CC {
+   provides interface Resource[uint8_t clientId];
+   provides interface I2C;
+ }
+ implementation {
+   components MspBusC, I2CM;
+ 
+   Resource = MspBusC.Resource;
+   I2C = I2CM.I2C;
+ }
+ 
+ MspBusC (the arbiter for the MSP bus):
+ #define MSP_BUS_RESOURCE "MspBus.Resource"
+ configuration {
+   provides interface Resource[uint8_t clientId];
+ } ...
+ 
  4. Default arbiters
  ====================================================================
***************
*** 239,242 ****
--- 274,288 ----
  scope of this document.
  
+ We also note that some queued/virtualised services may wish to also support
+ reservation, e.g., an A/D conveter which wants to support low-latency
+ requests.  Such components will use the same id for their service and
+ resource interfaces, e.g.:
+ #define ADC_RESOURCE "Adc.resource"
+ #define ADC_SERVICE ADC_RESOURCE
+ configuration ADCC {
+   provides interface ADC[uint8_t id];
+   provides interface Resource[uint8_t id];
+ } ...
+ 
  
  6. Author's Address