[Tinyos-2-commits] CVS: tinyos-2.x/doc/html/tutorial lesson8.html, 1.1.2.6, 1.1.2.7

Fri Nov 3 10:45:07 PST 2006

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

Modified Files:
      Tag: tinyos-2_0_devel-BRANCH
	lesson8.html 
Log Message:
Update of tutorial based on comments from Jan...

Index: lesson8.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial/lesson8.html,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -C2 -d -r1.1.2.6 -r1.1.2.7
*** lesson8.html	31 Oct 2006 21:24:00 -0000	1.1.2.6
--- lesson8.html	3 Nov 2006 18:45:05 -0000	1.1.2.7
***************
*** 52,56 ****

! Currently, the power states of all dedicated resources are controlled by one of these three interfaces. They are only allow to enter one of two logical power states (on/off), regardless of the number of physical power states provided by the hardware on top of which their resource abstraction has been built. Which of these interfaces is provided by a particular resource depends on the timing requirements for physically powering it on or off.

--- 52,56 ----

! Currently, the power states of all dedicated resources are controlled by one of these three interfaces. They are only allowed to enter one of two logical power states (on/off), regardless of the number of physical power states provided by the hardware on top of which their resource abstraction has been built. Which of these interfaces is provided by a particular resource depends on the timing requirements for physically powering it on or off.

***************
*** 80,84 ****

! Shared resources are essentially built on top of dedicated resources, with access to them being controlled by an arbiter component. In this way, power managers can be used to automatically control the power state of these resources through their <tt>AsyncStdControl</tt>, <tt>StdControl</tt>, or <tt>SplitControl</tt> interfaces. They communicate with the arbiter, monitoring whether the resource is being used by any of its clients at any given moment and powering it on/off accordingly. The figure below shows how an arbiter component and a power manager can be wired together to provide arbitration and automatic power management for a shared resource.

--- 80,84 ----

! Shared resources are essentially built on top of dedicated resources, with access to them being controlled by an arbiter component. In this way, power managers can be used to automatically control the power state of these resources through their <tt>AsyncStdControl</tt>, <tt>StdControl</tt>, or <tt>SplitControl</tt> interfaces. They communicate with the arbiter (through the use of a <tt>ResourceController</tt> interface), monitoring whether the resource is being used by any of its clients and powering it on/off accordingly. The figure below shows how an arbiter component and a power manager can be wired together to provide arbitration and automatic power management for a shared resource.

***************
*** 106,110 ****

! From this figure, we see that the only interfaces exposed to a client through the shared resource abstraction are the <tt>Resource</tt> and <tt>ResourceRequested</tt> interfaces provided by the arbiter as well as any resource specific interfaces provided by the resource itself. It also uses a <tt>ResourceConfigure</tt> interface, expecting it to be properly implemented by its clients. A client requests access to a shared resource through the <tt>Resource</tt> interface and runs operations on it using whatever resource specific interfaces are provided. A client may choose to wire itself to the <tt>ResourceRequested</tt> interface if it wishes to hold onto a resource indefinitely and be informed whenever other clients request its use.

--- 106,110 ----

! From this figure, we see that the only interfaces exposed to a client through the shared resource abstraction are the <tt>Resource</tt> and <tt>ResourceRequested</tt> interfaces provided by the arbiter as well as any resource specific interfaces provided by the resource itself. It also uses a <tt>ResourceConfigure</tt> interface, expecting it to be implemented on a client by client basis depending on their requirements. A client requests access to a shared resource through the <tt>Resource</tt> interface and runs operations on it using whatever resource specific interfaces are provided. A client may choose to wire itself to the <tt>ResourceRequested</tt> interface if it wishes to hold onto a resource indefinitely and be informed whenever other clients request its use.

***************
*** 121,126 ****
  </p>

! <h1>Using a Shared Resource</h1>
! This section shows you how to gain access to and use shared resources in TinyOS. It walks through the process of making a request through the <code>Resource</code> interface and handling the granted event that is signaled back. We will connect multiple clients to a single shared resources and see how access to each of them gets arbitrated. We also show how to hold onto a resource until another client has requested it by implementing the <tt>ResourceRequested</tt> interface.

--- 121,126 ----
  </p>

! <h1>Working with Shared Resources</h1>
! This section shows you how to gain access to and use shared resources in TinyOS. It walks through the process of making a request through the <code>Resource</code> interface and handling the <tt>granted</tt> event that is signaled back. We will connect multiple clients to a single shared resources and see how access to each of them gets arbitrated. We also show how to hold onto a resource until another client has requested it by implementing the <tt>ResourceRequested</tt> interface.

***************
*** 158,162 ****
  <p>Other than the instantiation and wiring of the interfaces provided by the <code>SharedResourceC</code> component, this configuration is identical to the one presented in Lesson 1 for the Blink Application.</p>  

! All shared resources in TinyOS are provided through a generic component similar to the <code>SharedResourceC</code> component. A resource client simply instantiates a new instance of this component and wires to the interfaces it provides. In this application, three instances of the <code>SharedResourceC</code> component are instantiated and wired to three different clients from the <code>TestSharedResourceC</code> component. Each instantiation provides a <tt>Resource</tt>, <tt>ResourceOperations</tt>, and <tt>ResourceRequested</tt> interface (although no clients are wiring to this interface in this example). The <tt>ResourceOperations</tt> interface represents a resource specific interface that can be used to perform operations on the resource. Calls to commands through this interface will only succeed if the client calling them happens to have access to the resource when they are called.

--- 158,162 ----
  <p>Other than the instantiation and wiring of the interfaces provided by the <code>SharedResourceC</code> component, this configuration is identical to the one presented in Lesson 1 for the Blink Application.</p>  

! All shared resources in TinyOS are provided through a generic component similar to the <code>SharedResourceC</code> component. A resource client simply instantiates a new instance of this component and wires to the interfaces it provides. In this application, three instances of the <code>SharedResourceC</code> component are instantiated and wired to three different clients from the <code>TestSharedResourceC</code> component. Each instantiation provides a <tt>Resource</tt>, <tt>ResourceOperations</tt>, and <tt>ResourceRequested</tt> interface, and uses a <tt>ResourceConfgigure</tt> interface. In this example, no wiring is done to the <tt>ResourceConfigure</tt> or <tt>ResourceRequested</tt> interface as wiring to to these interfaces is optional. The <tt>ResourceOperations</tt> interface is an EXAMPLE of a resource specific interface that a resource may provide to perform operations on it. Calls to commands through this interface will only succeed if the client calling them happens to have access to the resource when they are called.

***************
*** 211,215 ****
  </pre>

! Whenever one of these operations completes, a <code>ResourceOperations.operationDone()</code> event is signaled. Once this event is received by each client, a timer is started to hold onto the resource for 250 ms and an LED corresponding to that client is toggled.

  <pre>
--- 211,215 ----
  </pre>

! Whenever one of these operations completes, a <code>ResourceOperations.operationDone()</code> event is signaled. Once this event is received by each client, a timer is started to hold onto the resource for 250 (binary) ms and an LED corresponding to that client is toggled.

  <pre>
***************
*** 330,333 ****
--- 330,337 ----
  </p>

+ <p>
+ If you would like to see more examples of how to use the different arbiters and power managers provided in the default TinyOS distribution, please refer to the test applications located in <tt>tinyos-2.x/apps/tests/TestArbiter</tt> and <tt>tinyos-2.x/apps/tests/TestPowerManager</tt>.  This tutorial has provided enough background information on how to use these components in order for you to sift through these applications on your own. 
+ </p>
+ 
  <h1>Conclusion</h1>
  <p>
***************
*** 335,339 ****
  <ol> 
  <li> Wiring in a shared resource for use by a client.
! <li> Useing the <tt>Resource</tt> interface to gain access to a shared resource.</li>
  <li> Changing the arbitration policy used by a particular shared resource.</li>
  <li> Wrapping a dedicated resource and wiring in a power manager in order to create a shared resource.</li>
--- 339,343 ----
  <ol> 
  <li> Wiring in a shared resource for use by a client.
! <li> Using the <tt>Resource</tt> interface to gain access to a shared resource.</li>
  <li> Changing the arbitration policy used by a particular shared resource.</li>
  <li> Wrapping a dedicated resource and wiring in a power manager in order to create a shared resource.</li>
***************
*** 342,346 ****

! While the power managers presented in this tutorial are powerful components for providing power management of shared reosurces, they are not the only power management mechanisms provided by TinyOS. Microcontroller power management is also preformed as outlined in TEP115. Whenever the task queue empties, the lowest power state that the microcontroller is capapble of dropping to is automatically calculated and then switched to. In this way, the user is not burdened with explicity controlling these power states. The cc1000 and cc2420 radio implementations also provide "Low Power Listening" (LPL) interfaces for controlling their duty cycles. Although these interfaces differ somewhat, they are both able to provide energy savings not achieveable through other means. Ideally, the components providing this LPL interface could be thought of as power manager components for the radio resource and be wired to the radio in the same way as the other power managers described in this tutorial. The LPL implementation for the cc2420 can be found under <tt>tinyos-2.x/tos/chips/cc2420_lpl</tt> and the LPL implementation for the cc1000 can be found under <tt>tinyos-2.x/tos/chips/cc1000</tt>. As these interfaces begin to mature and merge into one, this tutorial will be updated appropriately to accomodate the change.

--- 346,350 ----

! While the power managers presented in this tutorial are powerful components for providing power management of shared reosurces, they are not the only power management mechanisms provided by TinyOS. Microcontroller power management is also preformed as outlined in TEP115. Whenever the task queue empties, the lowest power state that the microcontroller is capapble of dropping to is automatically calculated and then switched to. In this way, the user is not burdened with explicity controlling these power states. The cc1000 and cc2420 radio implementations also provide "Low Power Listening" (LPL) interfaces for controlling their duty cycles. Although the LPL interface used by each radio stack differs somewhat, they are both able to provide energy savings not achieveable through other means. Ultimately we would like to see the components providing this LPL interface implemented as power manager components for the "radio resource" and be wired to the radio in the same way as the other power managers described in this tutorial. The LPL implementation for the cc2420 can be found under <tt>tinyos-2.x/tos/chips/cc2420_lpl</tt> and the LPL implementation for the cc1000 can be found under <tt>tinyos-2.x/tos/chips/cc1000</tt>. As these interfaces begin to mature and merge into one, this tutorial will be updated appropriately to accomodate the change.