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

Fri Jul 13 16:43:19 PDT 2007

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

Modified Files:
	lesson8.html 
Log Message:
Moved the apps/tests/TestSharedResources application into the tutorials directory and gave it a new name to fit more appropriately in there.  Also modified the tutorial itself to reflect these changes and added / deleted dsome obsolete text from it.

Index: lesson8.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial/lesson8.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** lesson8.html	4 Feb 2007 19:54:42 -0000	1.5
--- lesson8.html	13 Jul 2007 23:43:17 -0000	1.6
***************
*** 125,137 ****
  </p>

! To begin, go to the <tt>tinyos-2.x/apps/tests/TestSharedResource</tt> directory and install this application on a mote. After installing the application you should see three leds flashing in sequence.

! Let's take a look at the different components contained in this directory to see whats going on. Start with the top level application component: <code>TestSharedResourceAppC</code>

  <pre>
! configuration TestSharedResourceAppC{
  }
  implementation {
!   components MainC,LedsC, TestSharedResourceC as App,
    new TimerMilliC() as Timer0,
    new TimerMilliC() as Timer1,
--- 125,137 ----
  </p>

! To begin, go to the <tt>tinyos-2.x/apps/tutorials/SharedResourceDemo</tt> directory and install this application on a mote. After installing the application you should see three leds flashing in sequence.

! Let's take a look at the different components contained in this directory to see whats going on. Start with the top level application component: <code>SharedResourceDemoAppC</code>

  <pre>
! configuration SharedResourceDemoAppC{
  }
  implementation {
!   components MainC,LedsC, SharedResourceDemoC as App,
    new TimerMilliC() as Timer0,
    new TimerMilliC() as Timer1,
***************
*** 158,169 ****
  <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.

! Let's take a look at the <code>TestSharedResourceC</code> to see how access is actually granted to a Resource.

  <pre>
! module TestSharedResourceC {
    uses {
      interface Boot;  
--- 158,169 ----
  <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>SharedResourceDemoC</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.

! Let's take a look at the <code>SharedResourceDemoC</code> to see how access is actually granted to a Resource.

  <pre>
! module SharedResourceDemoC {
    uses {
      interface Boot;  
***************
*** 247,251 ****
  </pre>

! In this way, requests are continuously put in by each client, allowing the application to continuously flash the LEDs in the order in which requests are being serviced. As stated before, the <code>SharedResourceC</code> component services these requests in a round-robin fashion. If you would like to see the requests serviced in the order they are received (and see the LEDs flash accordingly), you can open up the <code>SharedResourceP</code> component in the <tt>apps/tests/TestSharedResource</tt> directory and replace the <code>RoundRobinArbiter</code> component with the <code>FcfsArbiter</code> component.

  <table>
--- 247,251 ----
  </pre>

! In this way, requests are continuously put in by each client, allowing the application to continuously flash the LEDs in the order in which requests are being serviced. As stated before, the <code>SharedResourceC</code> component services these requests in a round-robin fashion. If you would like to see the requests serviced in the order they are received (and see the LEDs flash accordingly), you can open up the <code>SharedResourceP</code> component in the <tt>apps/tutorials/SharedResourceDemo</tt> directory and replace the <code>RoundRobinArbiter</code> component with the <code>FcfsArbiter</code> component.

  <table>
***************
*** 260,264 ****
  }
  implementation {
!   components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;
    ...
    ...
--- 260,264 ----
  }
  implementation {
!   components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
    ...
    ...
***************
*** 276,280 ****
  }
  implementation {
!   components new FcfsArbiterC(TEST_SHARED_RESOURCE) as Arbiter;
    ...
    ...
--- 276,280 ----
  }
  implementation {
!   components new FcfsArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
    ...
    ...
***************
*** 290,294 ****

  <pre>
! #define TEST_SHARED_RESOURCE   "Test.Shared.Resource"
  configuration SharedResourceP {
  	provides interface Resource[uint8_t id];
--- 290,294 ----

  <pre>
! #define UQ_SHARED_RESOURCE   "Shared.Resource"
  configuration SharedResourceP {
  	provides interface Resource[uint8_t id];
***************
*** 298,302 ****
  }
  implementation {
!   components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;
    components new SplitControlPowerManagerC() as PowerManager;
    components ResourceP;
--- 298,302 ----
  }
  implementation {
!   components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
    components new SplitControlPowerManagerC() as PowerManager;
    components ResourceP;
***************
*** 320,324 ****

  <pre>
! components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;
  components new SplitControlPowerManagerC() as PowerManager;
  components ResourceP;
--- 320,324 ----

<pre>
! components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
 components new SplitControlPowerManagerC() as PowerManager;
 components ResourceP;
***************
*** 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.

--- 346,350 ----

! While the power managers presented in this tutorial are powerful components for providing power management of shared resources, 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. The LPL implementation for the cc2420 can be found under <tt>tinyos-2.x/tos/chips/cc2420</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.