+++ /dev/null
-COMPONENT=TestSharedResourceAppC
-include $(MAKERULES)
-
+++ /dev/null
-README for TestSharedResource
-Author/Contact: tinyos-help@millennium.berkeley.edu
-@author Kevin Klues <klues@tkn.tu-berlin.de>
-
-Description:
-
-This application is used to test the use of Shared Resources.
-Three Resource users are created and all three request
-control of the resource before any one of them is granted it.
-Once the first user is granted control of the resource, it performs
-some operation on it. Once this operation has completed, a timer
-is set to allow this user to have control of it for a specific
-amount of time. Once this timer expires, the resource is released
-and then immediately requested again. Upon releasing the resource
-control will be granted to the next user that has requested it in
-round robin order. Initial requests are made by the three resource
-users in the following order.
- -- Resource 0
- -- Resource 2
- -- Resource 1
-It is expected then that using a round robin policy, control of the
-resource will be granted in the order of 0,1,2 and the Leds
-corresponding to each resource will flash whenever this occurs.
- -- Led 0 -> Resource 0
- -- Led 1 -> Resource 1
- -- Led 2 -> Resource 2
-
-Tools:
-
-None.
-
-Known bugs/limitations:
-
-None.
-
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- * An EXAMPLE of an interface for performing operations on a resource.
- * In this test application it is provided by the dedicated ResourceP component
- * and passed through all of the proper components before being exposed by the
- * shared resource at the topmost level.
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-interface ResourceOperations {
- command error_t operation();
- event void operationDone(error_t error);
-}
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- * This is an example implementation of a dedicated resource.
- * It provides the SplitControl interface for power management
- * of the resource and an EXAMPLE ResourceOperations interface
- * for performing operations on it.
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-module ResourceP {
- provides {
- interface SplitControl;
- interface ResourceOperations;
- }
-}
-implementation {
-
- bool lock;
-
- task void startDone() {
- lock = FALSE;
- signal SplitControl.startDone(SUCCESS);
- }
-
- task void stopDone() {
- signal SplitControl.stopDone(SUCCESS);
- }
-
- task void operationDone() {
- lock = FALSE;
- signal ResourceOperations.operationDone(SUCCESS);
- }
-
- command error_t SplitControl.start() {
- post startDone();
- return SUCCESS;
- }
-
- command error_t SplitControl.stop() {
- lock = TRUE;
- post stopDone();
- return SUCCESS;
- }
-
- command error_t ResourceOperations.operation() {
- if(lock == FALSE) {
- lock = TRUE;
- post operationDone();
- return SUCCESS;
- }
- return FAIL;
- }
-}
-
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- * SharedResourceC is used to provide a generic configuration around
- * the SharedResourceP component so that new instantiations of
- * it provide a single set of interfaces that are all properly associated
- * with one another rather than requiring the user to deal with the complexity
- * of doing this themselves.
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-#define TEST_SHARED_RESOURCE "Test.Shared.Resource"
-generic configuration SharedResourceC() {
- provides interface Resource;
- provides interface ResourceRequested;
- provides interface ResourceOperations;
- uses interface ResourceConfigure;
-}
-implementation {
- components SharedResourceP;
-
- enum {
- RESOURCE_ID = unique(TEST_SHARED_RESOURCE)
- };
-
- Resource = SharedResourceP.Resource[RESOURCE_ID];
- ResourceRequested = SharedResourceP.ResourceRequested[RESOURCE_ID];
- ResourceOperations = SharedResourceP.ResourceOperations[RESOURCE_ID];
- ResourceConfigure = SharedResourceP.ResourceConfigure[RESOURCE_ID];
-}
-
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- * The SharedResourceImplP component is used to wrap all of the operations
- * from a dedicated resource so that access to them is protected when
- * it is used as a shared resource. It uses the ArbiterInfo interface
- * provided by an Arbiter to accomplish this.
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-module SharedResourceImplP {
- provides {
- interface ResourceOperations as SharedResourceOperations[uint8_t id];
- }
- uses {
- interface ArbiterInfo;
- interface ResourceOperations;
- }
-}
-implementation {
- uint8_t current_id = 0xFF;
-
- event void ResourceOperations.operationDone(error_t error) {
- signal SharedResourceOperations.operationDone[current_id](error);
- }
-
- command error_t SharedResourceOperations.operation[uint8_t id]() {
- if(call ArbiterInfo.userId() == id && call ResourceOperations.operation() == SUCCESS) {
- current_id = id;
- return SUCCESS;
- }
- return FAIL;
- }
-
- default event void SharedResourceOperations.operationDone[uint8_t id](error_t error) {}
-}
-
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- * The SharedResourceP component is used to create a shared resource
- * out of a dedicated one.
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-#define TEST_SHARED_RESOURCE "Test.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];
-}
-implementation {
- components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;
- components new SplitControlPowerManagerC() as PowerManager;
- components ResourceP;
- components SharedResourceImplP;
-
- ResourceOperations = SharedResourceImplP;
- Resource = Arbiter;
- ResourceRequested = Arbiter;
- ResourceConfigure = Arbiter;
- SharedResourceImplP.ArbiterInfo -> Arbiter;
- PowerManager.ResourceDefaultOwner -> Arbiter;
-
- PowerManager.SplitControl -> ResourceP;
- SharedResourceImplP.ResourceOperations -> ResourceP;
-}
-
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-/**
- *
- * This application is used to test the use of Shared Resources.
- * Three Resource users are created and all three request
- * control of the resource before any one of them is granted it.
- * Once the first user is granted control of the resource, it performs
- * some operation on it. Once this operation has completed, a timer
- * is set to allow this user to have control of it for a specific
- * amount of time. Once this timer expires, the resource is released
- * and then immediately requested again. Upon releasing the resource
- * control will be granted to the next user that has requested it in
- * round robin order. Initial requests are made by the three resource
- * users in the following order.<br>
- * <li> Resource 0
- * <li> Resource 2
- * <li> Resource 1
- * <br>
- * It is expected then that using a round robin policy, control of the
- * resource will be granted in the order of 0,1,2 and the Leds
- * corresponding to each resource will flash whenever this occurs.<br>
- * <li> Led 0 -> Resource 0
- * <li> Led 1 -> Resource 1
- * <li> Led 2 -> Resource 2
- * <br>
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-configuration TestSharedResourceAppC{
-}
-implementation {
- components MainC,LedsC, TestSharedResourceC as App,
- new TimerMilliC() as Timer0,
- new TimerMilliC() as Timer1,
- new TimerMilliC() as Timer2;
- App -> MainC.Boot;
- App.Leds -> LedsC;
- App.Timer0 -> Timer0;
- App.Timer1 -> Timer1;
- App.Timer2 -> Timer2;
-
- components
- new SharedResourceC() as Resource0,
- new SharedResourceC() as Resource1,
- new SharedResourceC() as Resource2;
- App.Resource0 -> Resource0;
- App.Resource1 -> Resource1;
- App.Resource2 -> Resource2;
- App.ResourceOperations0 -> Resource0;
- App.ResourceOperations1 -> Resource1;
- App.ResourceOperations2 -> Resource2;
-}
+++ /dev/null
-/*
- * "Copyright (c) 2006 Washington University in St. Louis.
- * All rights reserved.
- *
- * Permission to use, copy, modify, and distribute this software and its
- * documentation for any purpose, without fee, and without written agreement is
- * hereby granted, provided that the above copyright notice, the following
- * two paragraphs and the author appear in all copies of this software.
- *
- * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
- * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
- * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
- * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
- * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
- * MODIFICATIONS."
- */
-
-#include "Timer.h"
-
-/**
- *
- * This application is used to test the use of Shared Resources.
- * Three Resource users are created and all three request
- * control of the resource before any one of them is granted it.
- * Once the first user is granted control of the resource, it performs
- * some operation on it. Once this operation has completed, a timer
- * is set to allow this user to have control of it for a specific
- * amount of time. Once this timer expires, the resource is released
- * and then immediately requested again. Upon releasing the resource
- * control will be granted to the next user that has requested it in
- * round robin order. Initial requests are made by the three resource
- * users in the following order.<br>
- * <li> Resource 0
- * <li> Resource 2
- * <li> Resource 1
- * <br>
- * It is expected then that using a round robin policy, control of the
- * resource will be granted in the order of 0,1,2 and the Leds
- * corresponding to each resource will flash whenever this occurs.<br>
- * <li> Led 0 -> Resource 0
- * <li> Led 1 -> Resource 1
- * <li> Led 2 -> Resource 2
- * <br>
- *
- * @author Kevin Klues (klueska@cs.wustl.edu)
- * @version $Revision$
- * @date $Date$
- */
-
-module TestSharedResourceC {
- uses {
- interface Boot;
- interface Leds;
- interface Timer<TMilli> as Timer0;
- interface Timer<TMilli> as Timer1;
- interface Timer<TMilli> 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;
- }
-}
-implementation {
-
- #define HOLD_PERIOD 250
-
- //All resources try to gain access
- event void Boot.booted() {
- call Resource0.request();
- call Resource2.request();
- call Resource1.request();
- }
-
- //If granted the resource, run some operation
- event void Resource0.granted() {
- call ResourceOperations0.operation();
- }
- event void Resource1.granted() {
- call ResourceOperations1.operation();
- }
- event void Resource2.granted() {
- call ResourceOperations2.operation();
- }
-
- //When the operation completes, flash the LED and hold the resource for a while
- 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();
- }
-
- //After the hold period release the resource and request it again
- 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();
- }
-}
-
--- /dev/null
+COMPONENT=SharedResourceDemoAppC
+include $(MAKERULES)
+
--- /dev/null
+README for SharedResourceDemo
+Author/Contact: tinyos-help@millennium.berkeley.edu
+@author Kevin Klues <klues@tkn.tu-berlin.de>
+
+Description:
+
+This application is used to test the use of Shared Resources.
+Three Resource users are created and all three request
+control of the resource before any one of them is granted it.
+Once the first user is granted control of the resource, it performs
+some operation on it. Once this operation has completed, a timer
+is set to allow this user to have control of it for a specific
+amount of time. Once this timer expires, the resource is released
+and then immediately requested again. Upon releasing the resource
+control will be granted to the next user that has requested it in
+round robin order. Initial requests are made by the three resource
+users in the following order.
+ -- Resource 0
+ -- Resource 2
+ -- Resource 1
+It is expected then that using a round robin policy, control of the
+resource will be granted in the order of 0,1,2 and the Leds
+corresponding to each resource will flash whenever this occurs.
+ -- Led 0 -> Resource 0
+ -- Led 1 -> Resource 1
+ -- Led 2 -> Resource 2
+
+Tools:
+
+None.
+
+Known bugs/limitations:
+
+None.
+
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ * An EXAMPLE of an interface for performing operations on a resource.
+ * In this test application it is provided by the dedicated ResourceP component
+ * and passed through all of the proper components before being exposed by the
+ * shared resource at the topmost level.
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+interface ResourceOperations {
+ command error_t operation();
+ event void operationDone(error_t error);
+}
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ * This is an example implementation of a dedicated resource.
+ * It provides the SplitControl interface for power management
+ * of the resource and an EXAMPLE ResourceOperations interface
+ * for performing operations on it.
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+module ResourceP {
+ provides {
+ interface SplitControl;
+ interface ResourceOperations;
+ }
+}
+implementation {
+
+ bool lock;
+
+ task void startDone() {
+ lock = FALSE;
+ signal SplitControl.startDone(SUCCESS);
+ }
+
+ task void stopDone() {
+ signal SplitControl.stopDone(SUCCESS);
+ }
+
+ task void operationDone() {
+ lock = FALSE;
+ signal ResourceOperations.operationDone(SUCCESS);
+ }
+
+ command error_t SplitControl.start() {
+ post startDone();
+ return SUCCESS;
+ }
+
+ command error_t SplitControl.stop() {
+ lock = TRUE;
+ post stopDone();
+ return SUCCESS;
+ }
+
+ command error_t ResourceOperations.operation() {
+ if(lock == FALSE) {
+ lock = TRUE;
+ post operationDone();
+ return SUCCESS;
+ }
+ return FAIL;
+ }
+}
+
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ * SharedResourceC is used to provide a generic configuration around
+ * the SharedResourceP component so that new instantiations of
+ * it provide a single set of interfaces that are all properly associated
+ * with one another rather than requiring the user to deal with the complexity
+ * of doing this themselves.
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+#define UQ_SHARED_RESOURCE "Shared.Resource"
+generic configuration SharedResourceC() {
+ provides interface Resource;
+ provides interface ResourceRequested;
+ provides interface ResourceOperations;
+ uses interface ResourceConfigure;
+}
+implementation {
+ components SharedResourceP;
+
+ enum {
+ RESOURCE_ID = unique(UQ_SHARED_RESOURCE)
+ };
+
+ Resource = SharedResourceP.Resource[RESOURCE_ID];
+ ResourceRequested = SharedResourceP.ResourceRequested[RESOURCE_ID];
+ ResourceOperations = SharedResourceP.ResourceOperations[RESOURCE_ID];
+ ResourceConfigure = SharedResourceP.ResourceConfigure[RESOURCE_ID];
+}
+
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ *
+ * This application is used to test the use of Shared Resources.
+ * Three Resource users are created and all three request
+ * control of the resource before any one of them is granted it.
+ * Once the first user is granted control of the resource, it performs
+ * some operation on it. Once this operation has completed, a timer
+ * is set to allow this user to have control of it for a specific
+ * amount of time. Once this timer expires, the resource is released
+ * and then immediately requested again. Upon releasing the resource
+ * control will be granted to the next user that has requested it in
+ * round robin order. Initial requests are made by the three resource
+ * users in the following order.<br>
+ * <li> Resource 0
+ * <li> Resource 2
+ * <li> Resource 1
+ * <br>
+ * It is expected then that using a round robin policy, control of the
+ * resource will be granted in the order of 0,1,2 and the Leds
+ * corresponding to each resource will flash whenever this occurs.<br>
+ * <li> Led 0 -> Resource 0
+ * <li> Led 1 -> Resource 1
+ * <li> Led 2 -> Resource 2
+ * <br>
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+configuration SharedResourceDemoAppC{
+}
+implementation {
+ components MainC,LedsC, SharedResourceDemoC as App,
+ new TimerMilliC() as Timer0,
+ new TimerMilliC() as Timer1,
+ new TimerMilliC() as Timer2;
+ App -> MainC.Boot;
+ App.Leds -> LedsC;
+ App.Timer0 -> Timer0;
+ App.Timer1 -> Timer1;
+ App.Timer2 -> Timer2;
+
+ components
+ new SharedResourceC() as Resource0,
+ new SharedResourceC() as Resource1,
+ new SharedResourceC() as Resource2;
+ App.Resource0 -> Resource0;
+ App.Resource1 -> Resource1;
+ App.Resource2 -> Resource2;
+ App.ResourceOperations0 -> Resource0;
+ App.ResourceOperations1 -> Resource1;
+ App.ResourceOperations2 -> Resource2;
+}
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+#include "Timer.h"
+
+/**
+ *
+ * This application is used to test the use of Shared Resources.
+ * Three Resource users are created and all three request
+ * control of the resource before any one of them is granted it.
+ * Once the first user is granted control of the resource, it performs
+ * some operation on it. Once this operation has completed, a timer
+ * is set to allow this user to have control of it for a specific
+ * amount of time. Once this timer expires, the resource is released
+ * and then immediately requested again. Upon releasing the resource
+ * control will be granted to the next user that has requested it in
+ * round robin order. Initial requests are made by the three resource
+ * users in the following order.<br>
+ * <li> Resource 0
+ * <li> Resource 2
+ * <li> Resource 1
+ * <br>
+ * It is expected then that using a round robin policy, control of the
+ * resource will be granted in the order of 0,1,2 and the Leds
+ * corresponding to each resource will flash whenever this occurs.<br>
+ * <li> Led 0 -> Resource 0
+ * <li> Led 1 -> Resource 1
+ * <li> Led 2 -> Resource 2
+ * <br>
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+module SharedResourceDemoC {
+ uses {
+ interface Boot;
+ interface Leds;
+ interface Timer<TMilli> as Timer0;
+ interface Timer<TMilli> as Timer1;
+ interface Timer<TMilli> 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;
+ }
+}
+implementation {
+
+ #define HOLD_PERIOD 250
+
+ //All resources try to gain access
+ event void Boot.booted() {
+ call Resource0.request();
+ call Resource2.request();
+ call Resource1.request();
+ }
+
+ //If granted the resource, run some operation
+ event void Resource0.granted() {
+ call ResourceOperations0.operation();
+ }
+ event void Resource1.granted() {
+ call ResourceOperations1.operation();
+ }
+ event void Resource2.granted() {
+ call ResourceOperations2.operation();
+ }
+
+ //When the operation completes, flash the LED and hold the resource for a while
+ 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();
+ }
+
+ //After the hold period release the resource and request it again
+ 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();
+ }
+}
+
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ * The SharedResourceImplP component is used to wrap all of the operations
+ * from a dedicated resource so that access to them is protected when
+ * it is used as a shared resource. It uses the ArbiterInfo interface
+ * provided by an Arbiter to accomplish this.
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+module SharedResourceImplP {
+ provides {
+ interface ResourceOperations as SharedResourceOperations[uint8_t id];
+ }
+ uses {
+ interface ArbiterInfo;
+ interface ResourceOperations;
+ }
+}
+implementation {
+ uint8_t current_id = 0xFF;
+
+ event void ResourceOperations.operationDone(error_t error) {
+ signal SharedResourceOperations.operationDone[current_id](error);
+ }
+
+ command error_t SharedResourceOperations.operation[uint8_t id]() {
+ if(call ArbiterInfo.userId() == id && call ResourceOperations.operation() == SUCCESS) {
+ current_id = id;
+ return SUCCESS;
+ }
+ return FAIL;
+ }
+
+ default event void SharedResourceOperations.operationDone[uint8_t id](error_t error) {}
+}
+
--- /dev/null
+/*
+ * "Copyright (c) 2006 Washington University in St. Louis.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software and its
+ * documentation for any purpose, without fee, and without written agreement is
+ * hereby granted, provided that the above copyright notice, the following
+ * two paragraphs and the author appear in all copies of this software.
+ *
+ * IN NO EVENT SHALL WASHINGTON UNIVERSITY IN ST. LOUIS BE LIABLE TO ANY PARTY
+ * FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
+ * OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF WASHINGTON
+ * UNIVERSITY IN ST. LOUIS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * WASHINGTON UNIVERSITY IN ST. LOUIS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND WASHINGTON UNIVERSITY IN ST. LOUIS HAS NO
+ * OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+ * MODIFICATIONS."
+ */
+
+/**
+ * The SharedResourceP component is used to create a shared resource
+ * out of a dedicated one.
+ *
+ * @author Kevin Klues (klueska@cs.wustl.edu)
+ * @version $Revision$
+ * @date $Date$
+ */
+
+#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];
+}
+implementation {
+ components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;
+ components new SplitControlPowerManagerC() as PowerManager;
+ components ResourceP;
+ components SharedResourceImplP;
+
+ ResourceOperations = SharedResourceImplP;
+ Resource = Arbiter;
+ ResourceRequested = Arbiter;
+ ResourceConfigure = Arbiter;
+ SharedResourceImplP.ArbiterInfo -> Arbiter;
+ PowerManager.ResourceDefaultOwner -> Arbiter;
+
+ PowerManager.SplitControl -> ResourceP;
+ SharedResourceImplP.ResourceOperations -> ResourceP;
+}
+
<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.\r
</p>\r
\r
-<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.</p> \r
+<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> \r
\r
-<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>TestSharedResourceAppC</code></p>\r
+<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>\r
\r
<pre>\r
-configuration TestSharedResourceAppC{\r
+configuration SharedResourceDemoAppC{\r
}\r
implementation {\r
- components MainC,LedsC, TestSharedResourceC as App,\r
+ components MainC,LedsC, SharedResourceDemoC as App,\r
new TimerMilliC() as Timer0,\r
new TimerMilliC() as Timer1,\r
new TimerMilliC() as Timer2;\r
\r
<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> \r
\r
-<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 <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.\r
+<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.\r
</p>\r
\r
-<p>Let's take a look at the <code>TestSharedResourceC</code> to see how access is actually granted to a Resource.\r
+<p>Let's take a look at the <code>SharedResourceDemoC</code> to see how access is actually granted to a Resource.\r
</p>\r
\r
<pre>\r
-module TestSharedResourceC {\r
+module SharedResourceDemoC {\r
uses {\r
interface Boot; \r
interface Leds;\r
}\r
</pre>\r
\r
-<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/tests/TestSharedResource</tt> directory and replace the <code>RoundRobinArbiter</code> component with the <code>FcfsArbiter</code> component.</p>\r
+<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>\r
\r
<table>\r
<tr><td><b>RoundRobinArbiter</b></td><td width=10></td><td><b>FcfsArbiter</b></td></tr>\r
uses interface ResourceConfigure[uint8_t id];\r
}\r
implementation {\r
- components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;\r
+ components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\r
...\r
...\r
}\r
uses interface ResourceConfigure[uint8_t id];\r
}\r
implementation {\r
- components new FcfsArbiterC(TEST_SHARED_RESOURCE) as Arbiter;\r
+ components new FcfsArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\r
...\r
...\r
}\r
<p>Looking through the rest of this component, you can see how its wiring matches the connections shown in Figure 2.</p>\r
\r
<pre>\r
-#define TEST_SHARED_RESOURCE "Test.Shared.Resource"\r
+#define UQ_SHARED_RESOURCE "Shared.Resource"\r
configuration SharedResourceP {\r
provides interface Resource[uint8_t id];\r
provides interface ResourceRequested[uint8_t id];\r
uses interface ResourceConfigure[uint8_t id];\r
}\r
implementation {\r
- components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;\r
+ components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\r
components new SplitControlPowerManagerC() as PowerManager;\r
components ResourceP;\r
components SharedResourceImplP;\r
</p>\r
\r
<pre>\r
-components new RoundRobinArbiterC(TEST_SHARED_RESOURCE) as Arbiter;\r
+components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\r
components new SplitControlPowerManagerC() as PowerManager;\r
components ResourceP;\r
components SharedResourceImplP;\r
</p>\r
\r
<p>\r
-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.\r
+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.\r
</p>\r
\r
<!-- Related Docs -->\r
projects / tinyos-2.x.git / commitdiff