resource arbitration and power management - tinyos documentation wiki.htm

从官方网站上下载tinyos2.0的学习指南

href="http://docs.tinyos.net/index.php/Image:Shared_resource_graph.png"><IMG 
height=277 
alt="This is a picture of how a shared resource works together with an arbiter and a power manager" 
src="Resource Arbitration and Power Management - TinyOS Documentation Wiki.files/450px-Shared_resource_graph.png" 
width=450 border=0></A><BR>Figure 2: Shared Resource Configuration </CENTER>
<P>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. </P>
<P>The rest of this tutorial is dedicated to teaching users how to use shared 
resources and show them how wiring is done between all components that make them 
up. </P>
<P>Specifically, this tutorial will teach users how to: </P>
<OL>
  <LI>Wire in a shared resource for use by a client. 
  <LI>Use the <TT>Resource</TT> interface to gain access to a shared resource. 
  <LI>Change the arbitration policy used by a particular shared resource. 
  <LI>Wire up a power manager for use by a shared resource. </LI></OL><A 
name=Working_with_Shared_Resources></A>
<H1><SPAN class=mw-headline>Working with Shared Resources</SPAN></H1>
<P>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. </P>
<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. </P>
<P>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> </P><PRE>configuration SharedResourceDemoAppC{
}
implementation {
  components MainC,LedsC, SharedResourceDemoC as App,
  new TimerMilliC() as Timer0,
  new TimerMilliC() as Timer1,
  new TimerMilliC() as Timer2;
  App -&gt; MainC.Boot;
  App.Leds -&gt; LedsC;
  App.Timer0 -&gt; Timer0;
  App.Timer1 -&gt; Timer1;
  App.Timer2 -&gt; Timer2;
  
  components
  new SharedResourceC() as SharedResource0,
  new SharedResourceC() as SharedResource1, 
  new SharedResourceC() as SharedResource2;
  App.Resource0 -&gt; SharedResource0;
  App.Resource1 -&gt; SharedResource1;
  App.Resource2 -&gt; SharedResource2;
  App.ResourceOperations0 -&gt; SharedResource0;
  App.ResourceOperations1 -&gt; SharedResource1;
  App.ResourceOperations2 -&gt; SharedResource2;
}
</PRE>
<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>
<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 <B>EXAMPLE</B> 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. </P>
<P>Let's take a look at the <CODE>SharedResourceDemoC</CODE> to see how access 
is actually granted to a Resource. </P><PRE>module SharedResourceDemoC {
  uses {
    interface Boot;  
    interface Leds;
    interface Timer as Timer0;
    interface Timer as Timer1;
    interface Timer as Timer2;
    
    interface Resource as Resource0;
    interface ResourceOperations as ResourceOperations0;
    
    interface Resource as Resource1;
    interface ResourceOperations as ResourceOperations1;
    
    interface Resource as Resource2;
    interface ResourceOperations as ResourceOperations2;
  }
}
</PRE>
<P>Each pair of <CODE>Resource/ResourceOperations</CODE> interfaces reperesents 
a different client of the shared resource used by this application. At boot 
time, we put in a request for the shared resource through each of these clients 
in the order (0,2,1). </P><PRE>event void Boot.booted() {
  call Resource0.request();
  call Resource2.request();
  call Resource1.request();
}
</PRE>
<P>Each of these requests is serviced in the order of the arbitration policy 
used by the shared resource. In the case of <CODE>SharedResourceC</CODE>, a 
Round-Robin policy is used, so these requests are serviced in the order (0,1,2). 
If a first-come-first-serve policy were in use, they would we be serviced in the 
order the were put in, i.e. (0,2,1). </P>
<P>Whenever a client's request for a resource has been granted, the 
<CODE>Resource.granted()</CODE> event for that client gets signaled. In this 
application, the body of the granted event for each client simply performs an 
operation on the resource as provided through the 
<CODE>ResourceOperations</CODE> interface. </P><PRE>event void Resource0.granted() {
  call ResourceOperations0.operation();   
}  
event void Resource1.granted() {
  call ResourceOperations1.operation();
}  
event void Resource2.granted() {
  call ResourceOperations2.operation();
} 
</PRE>
<P>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. </P><PRE> #define HOLD_PERIOD 250
 
 event void ResourceOperations0.operationDone(error_t error) {
   call Timer0.startOneShot(HOLD_PERIOD);  
   call Leds.led0Toggle();
 }
 event void ResourceOperations1.operationDone(error_t error) {
   call Timer1.startOneShot(HOLD_PERIOD);  
   call Leds.led1Toggle();
 }
 event void ResourceOperations2.operationDone(error_t error) {
   call Timer2.startOneShot(HOLD_PERIOD);  
   call Leds.led2Toggle();
 }
 
</PRE>
<P>Whenever one of these timers goes off, the client that started it releases 
the resource and immediately puts in a request for it again. </P><PRE>event void Timer0.fired() {
  call Resource0.release();
  call Resource0.request();
}
event void Timer1.fired() {
  call Resource1.release();
  call Resource1.request();
}
event void Timer2.fired() {
  call Resource2.release();
  call Resource2.request();
}
</PRE>
<P>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. </P>
<TABLE>
  <TBODY>
  <TR>
    <TD><B>RoundRobinArbiter</B> </TD>
    <TD><B>FcfsArbiter</B> </TD></TR>
  <TR>
    <TD><PRE>configuration SharedResourceP {
	provides interface Resource[uint8_t id];
	provides interface ResourceRequested[uint8_t id];
	provides interface ResourceOperations[uint8_t id];
	uses interface ResourceConfigure[uint8_t id];
}
implementation {
  components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
  ...
  ...
}
</PRE></TD>
    <TD><PRE>configuration SharedResourceP {
	provides interface Resource[uint8_t id];
	provides interface ResourceRequested[uint8_t id];
	provides interface ResourceOperations[uint8_t id];
	uses interface ResourceConfigure[uint8_t id];
}
implementation {
  components new FcfsArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
  ...
  ...
}
</PRE></TD></TR></TBODY></TABLE>
<P>Looking through the rest of this component, you can see how its wiring 
matches the connections shown in Figure 2. </P><PRE> #define UQ_SHARED_RESOURCE   "Shared.Resource"
 configuration SharedResourceP {
 	provides interface Resource[uint8_t id];
 	provides interface ResourceRequested[uint8_t id];
 	provides interface ResourceOperations[uint8_t id];
 	uses interface ResourceConfigure[uint8_t id];
 }