[Tinyos-2.0wg] Resource Update

[Kevin Klues]

I spent the day finally getting all the new Resource and Power Management
interfaces/implementations ready to be integrated into the tree.  Here are
the new files that I plan to check in.....

tos/interfaces/ResourceQueue.nc
tos/interfaces/ResourceRequested.nc
tos/system/ArbiterP.nc
tos/system/ControlledArbiterP.nc
tos/system/ControlledFcfsArbiterC.nc
tos/system/ControlledRoundRobinArbiterC.nc
tos/system/FcfsResourceQueueC.nc
tos/system/RoundRobinResourceQueueC.nc
tos/interfaces/Resource.nc
tos/interfaces/ResourceController.nc
tos/system/FcfsArbiterC.nc
tos/system/NoArbiterC.nc
tos/system/RoundRobinArbiterC.nc

The ResourceQueue is different than the other Queue interface.  The normal
Queue interface is designed for use as a FIFO queue and supports queing of
any variable type.  The ResourceQueue interface, on the other hand, is
designed to allow client ids of the resource to have a guaranteed slot in
the queue and be queued according to whatever queing policy is desired.  The
FcfsResourceQueueC implementation, for example, enqueues and dequeues the
client ids in FIFO order in the same way that the BasicScheduler component
schedules its tasks.  In the RoundRobinResourceQueueC implementation, client
id slots are still guaranteed, but they are serviced in round robin order.
I originally planned on implementing these components using the normal Queue
interface and working around the fact that it was designed with different
goals in mind, but tht fact that I needed my enqueue and dequeue commands to
be async anyway, prompted me to just strip it down and call it something
different.  Its signature is below.

interface ResourceQueue {
  async command uint8_t dequeue();
  async command error_t enqueue(uint8_t cleintId);
}

This interface is obviously not set in stone, and could (should) be changed
once we come up with more uses for it.  One obvious use would be to change
BasicScheduler to use the FcfsResourceQueuC compoent rather than
implementing this queuing policy itself.

The rest of the files simply constitute a reorganization of the compoennts
used to perform resource arbitration according to the proposal from a few
weeks back.  Basically we now have two types of Arbiters (normal Arbiters
and controlled Arbiters).  Normal arbiters can be wired to when you don't
plan on wiring a Power Manager (or similar component) to the arbiter.  In
the other cases you want to use a ControlledArbiter.  In the previous
implementations, all Arbiters were essentially ControlledArbiters, and this
added unnecessary overhead in situations where it wasn't needed.  All
arbiters now provide a ResourceRequested interface as well, eliminating the
need for the PriorityArbiter implementation that we previously had.  The
PriorityArbiter component wasn't a true implementation of a priority arbiter
anyway, as it only allowed for a single high priority user with all other
users being served in FIFO order.  The high priority user relied on the
requested() event supplied by the ResourceController interface to decide
when/if it should release the resource.  Combining the use of the
ResourceRequested interface now supplied by every arbiter and a separate
implementation of this strange queing policy using the ResourceQueue
interface, the same desired effect can be obtained without having to change
the internal implementation of the arbiter.  If we ever do decide that a
real implementation of a Priority arbiter is necessary, it is simply a
matter of wiring the proper queuing policy to the arbiter implementation.

I've gone through the tree and modified the necessary files to adhere to the
new interfaces.  This resulted in making the following set of
modifications....
1) Resource.release() was changed from returning a void to returning an
error_t.  All components supplying a default implementation of this command
or wrapping the release command from some sort of sub-resource needed to be
updated.
2) The Arbiter and Power Management components no longer provide an Init
interface.  All components wiring to this interface needed to be updated.
3) All components wiring an arbiter to a power manager needed to be updated
to instantiate an instance of a ControlledArbiter implementation rather than
the simple Arbiter component they were previously instantiating.

The files these changes have been made to are listed below...
tos/chips/at45db/At45dbC.nc
tos/chips/at45db/BlockStorageP.nc
tos/chips/at45db/LogStorageP.nc
tos/chips/atm128/adc/Atm128AdcC.nc
tos/chips/atm128/i2c/Atm128I2CMasterImplP.nc
tos/chips/atm128/i2c/Atm128I2CMasterP.nc
tos/chips/atm128/spi/Atm128SpiC.nc
tos/chips/atm128/spi/Atm128SpiP.nc
tos/chips/atm128/spi/sim/Atm128SpiC.nc
tos/chips/cc2420/CC2420ControlP.nc
tos/chips/cc2420/CC2420SpiImplP.nc
tos/chips/cc2420/CC2420TransmitP.nc
tos/chips/msp430/adc12/AdcC.nc
tos/chips/msp430/adc12/Msp430Adc12C.nc
tos/chips/msp430/adc12/Msp430RefVoltArbiterP.nc
tos/chips/msp430/usart/Msp430I2CP.nc
tos/chips/msp430/usart/Msp430SpiDmaP.nc
tos/chips/msp430/usart/Msp430SpiNoDmaP.nc
tos/chips/msp430/usart/Msp430UartP.nc
tos/chips/msp430/usart/Msp430UsartShare0P.nc
tos/chips/msp430/usart/Msp430UsartShare1P.nc
tos/chips/stm25p/Stm25pBlockP.nc
tos/chips/stm25p/Stm25pConfigP.nc
tos/chips/stm25p/Stm25pLogP.nc
tos/chips/stm25p/Stm25pSectorC.nc
tos/chips/stm25p/Stm25pSectorP.nc
tos/chips/stm25p/Stm25pSpiP.nc
tos/chips/tda5250/HplTda5250DataP.nc
tos/chips/tda5250/Tda5250RegCommP.nc
tos/chips/xe1205/XE1205SpiImplP.nc
tos/platforms/eyesIFX/sensors/RssiSensorVccP.nc
tos/platforms/intelmote2/chips/cc2420/IM2CC2420SpiP.nc
tos/platforms/intelmote2/chips/ds2745/DS2745InternalC.nc
tos/platforms/mica2/NestedResourceC.nc
tos/platforms/null/DemoSensorNowC.nc
tos/platforms/telosa/chips/sht11/HalSensirionSht11C.nc
tos/platforms/telosa/chips/sht11/HplSensirionSht11C.nc
tos/sensorboards/im2sb/HalSensirionSht11C.nc
tos/sensorboards/im2sb/HplSensirionSht11C.nc
tos/sensorboards/im2sb/LIS3L02DQInternalC.nc
tos/sensorboards/im2sb/MAX136xInternalC.nc
tos/sensorboards/im2sb/TMP175InternalC.nc
tos/sensorboards/im2sb/Tsl2561InternalC.nc

If no one has any objections, I will check all of these files in on Tuesday
morning (Germany time).  Be aware that I may have missed something though,
so if something suddenly seems not to compile, see if I missed the changes
outlined above in one of your files somewhere.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060813/da79aaaa/attachment.htm