[Tinyos-2-commits]
CVS: tinyos-2.x/apps/tests/TestArbiter/TestPriorityArbiter
Makefile, NONE, 1.1.4.2 README.txt, NONE,
1.1.4.2 TestPriorityArbiterAppC.nc, NONE,
1.1.4.2 TestPriorityArbiterC.nc, NONE, 1.1.4.2
Kevin Klues
klueska at users.sourceforge.net
Mon May 15 11:35:26 PDT 2006
- Previous message: [Tinyos-2-commits]
CVS: tinyos-2.x/apps/tests/TestArbiter/TestFcfsArbiter
Makefile, NONE, 1.1.4.2 README.txt, NONE,
1.1.4.2 TestArbiterAppC.nc, NONE, 1.1.4.2 TestArbiterC.nc,
NONE, 1.1.4.2
- Next message: [Tinyos-2-commits]
CVS: tinyos-2.x/apps/tests/TestArbiter/TestRoundRobinArbiter
Makefile, NONE, 1.1.4.2 README.txt, NONE,
1.1.4.2 TestArbiterAppC.nc, NONE, 1.1.4.2 TestArbiterC.nc,
NONE, 1.1.4.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-2.x/apps/tests/TestArbiter/TestPriorityArbiter
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv18756/apps/tests/TestArbiter/TestPriorityArbiter
Added Files:
Tag: tos-2-resource-pm-eval-cand
Makefile README.txt TestPriorityArbiterAppC.nc
TestPriorityArbiterC.nc
Log Message:
Merging the development branch with the resource/power management evaluation branch. After this merge all files except those already commited should be identical.
--- NEW FILE: Makefile ---
COMPONENT=TestPriorityArbiterAppC
CFLAGS += -I%T/lib/oski
OPTFLAGS = -O0
include $(MAKERULES)
--- NEW FILE: README.txt ---
README for TestPriorityArbiter
Author/Contact: tinyos-help at millennium.berkeley.edu
@author Kevin Klues <klues at tkn.tu-berlin.de>
@author Philipp Huppertz <huppertz at tkn.tu-berlin.de>
Description:
Please refer to TEP 108 for more information about the components
this application is used to test.
This application is used to test the functionality of the
FcfsPriorityArbiter component developed using the Resource
interface.
In this test there are 4 users of one resource. The leds indicate which
user is the owner of the resource:
- normal priority client 1 - led 0
- normal priority client 2 - led 1
- power manager - led 2
- high priority client - led 0 and led 1 and led 2
The short flashing of the according leds inidicate that a user has requested the
resource. The users have the following behaviour:
- normal priority clients are idle for a period of time before requesting the resource.
If they are granted the resource they will use it for a specific amount of time before releasing it.
- power manager only request the resource if its idle. It releases the resource immediatly
if there is a request from another client.
- high priority client behaves like a normal client but it will release the resource
after a shorter period of time if there are requests from other clients.
The poliy of the arbiter should be FirstComeFirstServed with one exception:
If the high priority client requests the resource, the resource will be granted to the
high priority client after the release of the current owner regardless of the internal queue of the arbiter.
After the high priority client releases the resource the normal FCFS arbitration resumes.
Tools:
None.
Known bugs/limitations:
None.
--- NEW FILE: TestPriorityArbiterAppC.nc ---
/*
* Copyright (c) 2004, Technische Universitat Berlin
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* - Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* - Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* - Neither the name of the Technische Universitat Berlin nor the names
* of its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
* OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
* USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
* - Revision -------------------------------------------------------------
* $Revision: 1.1.4.2 $
* $Date: 2006/05/15 18:35:23 $
* ========================================================================
*/
/**
* TestPriorityArbiter Application
* This application is used to test the functionality of the FcfsPriorityArbiter
* component developed using the Resource and ResourceUser interfaces.
* <br>
* In this test there are 4 users of one ressource. The Leds indicate which
* user is the owner of the resource:<br>
* <li> normal priority client 1 - led 0
* <li> normal priority client 2 - led 1
* <li> power manager - led 2
* <li> high priority client - led 0 and led 1 and led 2
* <br><br>
* The short flashing of the according leds inidicate that a user has requested the
* resource. The users have the following behaviour:<br><br>
* <li> Normal priority clients are idle for a period of time before requesting the resource.
* If they are granted the resource they will use it for a specific amount of time before releasing it.
* <li> Power manager only request the resource if its idle. It releases the resource immediatly
* if there is a request from another client.
* <li> High priority client behaves like a normal client but it will release the resource
* after a shorter period of time if there are requests from other clients.
* <br><br>
* The poliy of the arbiter should be FirstComeFirstServed with one exception:
* If the high priority client requests the resource, the resource will be granted to the
* high priority client after the release of the current owner regardless of the internal queue of the arbiter. After
* the high priority client releases the resource the normal FCFS arbitration resumes.
*
* @author Kevin Klues (klues at tkn.tu-berlin.de)
* @author Philipp Huppertz (extended test FcfsPriorityArbiter)
*/
configuration TestPriorityArbiterAppC {
}
implementation {
components MainC,
TestPriorityArbiterC,
LedsC,
BusyWaitMicroC,
new FcfsPriorityArbiterC("Test.Arbiter.Resource") as Arbiter,
new TimerMilliC() as TimerHigh,
new TimerMilliC() as TimerClient1,
new TimerMilliC() as TimerClient2;
TestPriorityArbiterC -> MainC.Boot;
TestPriorityArbiterC.BusyWait -> BusyWaitMicroC;
TestPriorityArbiterC.TimerHighClient -> TimerHigh;
TestPriorityArbiterC.TimerClient1 -> TimerClient1;
TestPriorityArbiterC.TimerClient2 -> TimerClient2;
TestPriorityArbiterC.HighClient -> Arbiter.HighPriorityClient;
TestPriorityArbiterC.PowerManager -> Arbiter.LowPriorityClient;
TestPriorityArbiterC.Client2 -> Arbiter.Resource[unique("Test.Arbiter.Resource")];
TestPriorityArbiterC.Client1 -> Arbiter.Resource[unique("Test.Arbiter.Resource")];
TestPriorityArbiterC.Leds -> LedsC;
}
--- NEW FILE: TestPriorityArbiterC.nc ---
/*
* Copyright (c) 2004, Technische Universitat Berlin
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* - Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* - Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* - Neither the name of the Technische Universitat Berlin nor the names
* of its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
* OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
* USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
* - Revision -------------------------------------------------------------
* $Revision: 1.1.4.2 $
* $Date: 2006/05/15 18:35:24 $
* ========================================================================
*/
/**
* TestPriorityArbiter Application
* This application is used to test the functionality of the FcfsPriorityArbiter
* component developed using the Resource and ResourceUser interfaces.
* <br>
* In this test there are 4 users of one ressource. The Leds indicate which
* user is the owner of the resource:<br>
* <li> normal priority client 1 - led 0
* <li> normal priority client 2 - led 1
* <li> power manager - led 2
* <li> high priority client - led 0 and led 1 and led 2
* <br><br>
* The short flashing of the according leds inidicate that a user has requested the
* resource. The users have the following behaviour:<br><br>
* <li> Normal priority clients are idle for a period of time before requesting the resource.
* If they are granted the resource they will use it for a specific amount of time before releasing it.
* <li> Power manager only request the resource if its idle. It releases the resource immediatly
* if there is a request from another client.
* <li> High priority client behaves like a normal client but it will release the resource
* after a shorter period of time if there are requests from other clients.
* <br><br>
* The poliy of the arbiter should be FirstComeFirstServed with one exception:
* If the high priority client requests the resource, the resource will be granted to the
* high priority client after the release of the current owner regardless of the internal queue of the arbiter. After
* the high priority client releases the resource the normal FCFS arbitration resumes.
*
* @author Kevin Klues (klues at tkn.tu-berlin.de)
* @author Philipp Huppertz (extended test FcfsPriorityArbiter)
*/
#include "Timer.h"
module TestPriorityArbiterC {
uses {
interface Boot;
interface Leds;
interface Resource as Client1;
interface Resource as Client2;
interface ResourceController as PowerManager;
interface ResourceController as HighClient;
interface BusyWait<TMicro,uint16_t>;
interface Timer<TMilli> as TimerClient1;
interface Timer<TMilli> as TimerClient2;
interface Timer<TMilli> as TimerHighClient;
}
}
implementation {
#define HIGHCLIENT_FULL_PERIOD 8000
#define HIGHCLIENT_SAFE_PERIOD 1000
#define HIGHCLIENT_SLEEP_PERIOD 10000
#define CLIENT2_ACTIVE_PERIOD 1000
#define CLIENT2_WAIT_PERIOD 6000
#define CLIENT1_ACTIVE_PERIOD 2000
#define CLIENT1_WAIT_PERIOD 6000
// internal states of Resource4 (High Prio Resource)
uint8_t sleepCnt = 0;
bool resReq = FALSE;
// internal state Resources (active / not active)
bool client1Active = FALSE;
bool client2Active = FALSE;
task void startHighClientSafePeriod() {
call TimerHighClient.stop();
call TimerHighClient.startOneShot(HIGHCLIENT_SAFE_PERIOD);
}
// flash the apropriate leds when requesting the ressource
event void TimerClient1.fired() {
if (client1Active) {
call Client1.release();
call TimerClient1.startOneShot(CLIENT1_WAIT_PERIOD);
call Leds.led0Off();
client1Active = FALSE;
} else {
call Leds.led0Toggle();
call BusyWait.wait(100);
call Leds.led0Toggle();
call Client1.request();
}
}
// flash the apropriate leds when requesting the ressource
event void TimerClient2.fired() {
if (client2Active) {
call Client2.release();
call TimerClient2.startOneShot(CLIENT2_WAIT_PERIOD);
call Leds.led1Off();
client2Active = FALSE;
} else {
call Leds.led1Toggle();
call BusyWait.wait(100);
call Leds.led1Toggle();
call Client2.request();
}
}
// flash the apropriate leds when requesting the ressource
event void TimerHighClient.fired() {
call Leds.led0Toggle();
call Leds.led1Toggle();
call Leds.led2Toggle();
call BusyWait.wait(100);
call Leds.led0Toggle();
call Leds.led1Toggle();
call Leds.led2Toggle();
call HighClient.release();
// and request again 'cause we know that one client will be served in between...
call HighClient.request();
resReq = FALSE;
}
//All resources try to gain access at the start
event void Boot.booted() {
call Client1.request();
call Client2.request();
call HighClient.request();
}
//If granted the resource, turn on an LED 0
event void Client1.granted() {
call Leds.led0On();
call Leds.led1Off();
call Leds.led2Off();
call TimerClient1.startOneShot(CLIENT1_ACTIVE_PERIOD);
client1Active = TRUE;
}
//If granted the resource, turn on an LED 1
event void Client2.granted() {
call Leds.led0Off();
call Leds.led1On();
call Leds.led2Off();
call TimerClient2.startOneShot(CLIENT2_ACTIVE_PERIOD);
client2Active = TRUE;
}
//If granted the resource, turn on an LED 2
event void PowerManager.granted() {
call Leds.led0Off();
call Leds.led1Off();
call Leds.led2On();
}
//If granted the resource, turn on an LED 0 & 1 & 2
event void HighClient.granted() {
if (sleepCnt > 7) {
// immediatly release resource and sleep
call HighClient.release();
call TimerHighClient.startOneShot(HIGHCLIENT_SLEEP_PERIOD);
sleepCnt = 0;
} else {
call Leds.led0On();
call Leds.led1On();
call Leds.led2On();
atomic {
if (resReq) {
call TimerHighClient.startOneShot(HIGHCLIENT_SAFE_PERIOD);
} else {
call TimerHighClient.startOneShot(HIGHCLIENT_FULL_PERIOD);
}
}
}
++sleepCnt;
}
//If detect that someone else wants the resource,
// release it
event void PowerManager.requested() {
call PowerManager.release();
}
//If detect that someone else wants the resource,
// release it if its safe
event void HighClient.requested() {
if (!resReq) {
if ( call HighClient.isOwner() ) {
post startHighClientSafePeriod();
} else {}
resReq = TRUE;
}
}
// do something
event void PowerManager.idle() {
call PowerManager.request();
}
// do nothing
event void HighClient.idle() {
}
}
- Previous message: [Tinyos-2-commits]
CVS: tinyos-2.x/apps/tests/TestArbiter/TestFcfsArbiter
Makefile, NONE, 1.1.4.2 README.txt, NONE,
1.1.4.2 TestArbiterAppC.nc, NONE, 1.1.4.2 TestArbiterC.nc,
NONE, 1.1.4.2
- Next message: [Tinyos-2-commits]
CVS: tinyos-2.x/apps/tests/TestArbiter/TestRoundRobinArbiter
Makefile, NONE, 1.1.4.2 README.txt, NONE,
1.1.4.2 TestArbiterAppC.nc, NONE, 1.1.4.2 TestArbiterC.nc,
NONE, 1.1.4.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-2-commits
mailing list