Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-19 Thread Andreas Koepke

Philip Levis:


On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:


If you don't have separate arbiters for the ADC and the DAC how can
 you ever allow them to perform operations in parallel?  And this sort
 of cascading through multiple levels of arbitration happens all the
 time.  Think about how the flash drivers on telos work.  There is
 arbitration to the flash operations themselves, sitting on top of
 arbitration to the msp430 usart underneath.


As long as two resources were not double used this practically never
was an issue, but now it becomes more probable:

AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.

Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.


Sure, badly written locking code can cause deadlock. Is there a case 
when a client wants the ADC but *not* the RefVolt? The typical solution 
to this is to layer them. There are many examples where an abstraction 
needs multiple resources. The arbiters paper in SOSP goes into how you 
do this, with the Light/Temp sensor board example. On the micasb, both 
sensors requires the ADC and share a pin; so you acquire the pin before 
putting a request to the ADC (Figure 13).


Yes -- you can also use Vcc as reference for the ADC. This is how I do 
CCA on the eyesIFX, switching around with the RefVolt would take too 
much time, and precision is not needed.



Phil


___
Tinyos-devel mailing list
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-19 Thread Philip Levis

On Feb 15, 2008, at 10:48 AM, Andreas Koepke wrote:


Philip Levis:

On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:

If you don't have separate arbiters for the ADC and the DAC how can
 you ever allow them to perform operations in parallel?  And  
this sort
 of cascading through multiple levels of arbitration happens all  
the

 time.  Think about how the flash drivers on telos work.  There is
 arbitration to the flash operations themselves, sitting on top of
 arbitration to the msp430 usart underneath.


As long as two resources were not double used this practically  
never

was an issue, but now it becomes more probable:

AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.

Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.
Sure, badly written locking code can cause deadlock. Is there a  
case when a client wants the ADC but *not* the RefVolt? The  
typical solution to this is to layer them. There are many examples  
where an abstraction needs multiple resources. The arbiters paper  
in SOSP goes into how you do this, with the Light/Temp sensor  
board example. On the micasb, both sensors requires the ADC and  
share a pin; so you acquire the pin before putting a request to  
the ADC (Figure 13).


Yes -- you can also use Vcc as reference for the ADC. This is how I  
do CCA on the eyesIFX, switching around with the RefVolt would take  
too much time, and precision is not needed.


OK, so you layer the components such that there is a lock order. You  
shouldn't be pushing the lock order to upper layers. In the best  
case, abstract through interfaces so you have a single piece of code  
that has a single order. In the worst case, make sure the small  
number of implementations all do it correctly.


Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-17 Thread Jan Hauer
On Feb 15, 2008 7:59 PM, Kevin Klues [EMAIL PROTECTED] wrote:
 Thats fine, but I think the point is that if the ADC reading you are
 about to take needs to use the refernece voltage, access should NOT be
 granted to the ADC until access to the reference voltage has been
 granted.  If you use VCC, you don't need to wait for this.  The
 information about which voltage source to use should be encapsulated
 inside the configuration settings for the ADC reading you are about to
 take, and not be changable without first releasing and then reaquring
 the resource.

Yes - a client has to let you know about all the resources it needs in
advance (and for the ADC we have the AdcConfigure interface for this
purpose). There are many possible combinations (ADC only, ADC+RefVolt,
RefVolt only (on a pin), DAC-combinations...), how smart should the
wrapper be? It must of course know that RefVolt must be requested
before ADC/DAC, but should this wrapper use special policies (e.g. if
one client needs RefVolt+ADC but RefVolt is blocked, then another
client that only needs ADC might go first even if it has requested
later, etc...)? Maybe this can be generalized similar to the way we
have different arbiter-policies.

Jan



 Kevin


 On Fri, Feb 15, 2008 at 10:48 AM, Andreas Koepke
 [EMAIL PROTECTED] wrote:
  Philip Levis:
 
 
  
On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
   
If you don't have separate arbiters for the ADC and the DAC how can
 you ever allow them to perform operations in parallel?  And this sort
 of cascading through multiple levels of arbitration happens all the
 time.  Think about how the flash drivers on telos work.  There is
 arbitration to the flash operations themselves, sitting on top of
 arbitration to the msp430 usart underneath.
   
As long as two resources were not double used this practically never
was an issue, but now it becomes more probable:
   
AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.
   
Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.
   
Sure, badly written locking code can cause deadlock. Is there a case
when a client wants the ADC but *not* the RefVolt? The typical solution
to this is to layer them. There are many examples where an abstraction
needs multiple resources. The arbiters paper in SOSP goes into how you
do this, with the Light/Temp sensor board example. On the micasb, both
sensors requires the ADC and share a pin; so you acquire the pin before
putting a request to the ADC (Figure 13).
 
   Yes -- you can also use Vcc as reference for the ADC. This is how I do
   CCA on the eyesIFX, switching around with the RefVolt would take too
   much time, and precision is not needed.
 
Phil
 
  
   
___
Tinyos-devel mailing list
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
   
 
   ___
   Tinyos-devel mailing list
   [EMAIL PROTECTED]
   https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
 



 --
 ~Kevin
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Jan Hauer
I don't really like the idea of having two arbiters (one for ADC and
one for DAC) and in addition another one for RefVolt, because that
would force (some) clients to make two successful requests before they
can actually start their operations. We have never really discussed
this, but resource starvation is certainly an issue and one can easily
imagine the pitfalls here.

Jan


On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL PROTECTED] wrote:
 What we really need I think is a way of allowing the reference voltage
  component have multiple owners simultaneously.  Most components that
  provide the Resource interface are used to grant exclusive access to a
  device that is used to perform some operation.  The reference voltage
  component is a bit different though in that once it is turned on and
  set to some value, it can be used by both the ADC and the DAC at the
  same time.

  Right now what happens when you make an ADC request is that this
  request implicitly requests access to the reference voltage component
  underneath, giving the ADC exclusive access over it and therefore
  blocking the DAC from getting access to it until the ADC is finished
  with it.  Conversely, if a DAC operation were started, a similar chain
  of events would occur:  Request of the DAC - Request of the
  ReferenceVoltage.

  I think the right way to solve this and still allow DAC operations and
  ADC operations to be performed in parallel is to build a custom
  Arbiter for the ReferenceVoltage component.  This arbiter needs to be
  able to couple requests for access to the Reference Voltage with the
  value it wants to be set to (i.e. provide two parameterized resource
  interfaces; one for 1.5 and one for 2.5).  As long as requests are
  only coming in through one of the two parameterized interfaces, the
  arbiter can signal granted to all incoming requests.  Once a request
  is made on the other set of interfaces though, the arbiter needs to
  stop granting requests on the previous one and switch over to the new
  one once all components that have been granted requests on the other
  side have called release (just use a reference counter or something
  similar and switch over once it reaches 0).

  On top of this then you then have a separate (normal) arbiter for the
  ADC and another one for the DAC.

  Kevin



  On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] wrote:
   I like Sandip's idea to create an arbiter that reserves use of refvolt to 
 the first
process that asks, but also responds to queries about the refvolt value.
  
Do arbiters as they are now allow for keeping a queue of asking routines 
 satisfied
with a resource with no breaks?
  
Would a shared arbiter for DAC and ADC be able to handle both these cases:
1.  ADC is claiming a resource for a longer time than DAC asks for it, 
 responds with volt value,
DAC runs and stops before  ADC stops, and ADC keeps using it 
 uninterrupted?
2.  ADC asks for a resource, then DAC asks for it, and starts sharing it,
 ADC stops and releases resource in a way that DAC keeps using it 
 uninterrupted?
  
  
  
 - Original Message 
 From: Jan Hauer [EMAIL PROTECTED]
  
  
  
   Alternatively we could agree that ADC and DAC
 share the same arbiter, which makes arbitration a lot easier, but is
 less efficient because you'd never be able to run ADC and DAC in
 parallel.
 Jan

  
I have a third alternative, so it's not stopping me completely from going 
 ahead.
  
To get my soil moisture sensors supplied
with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program to 
 adjust it to
2.50 V, but it seems useful to have more options.
  
  
John Griessen
  
--
Ecosensory   Austin TX
tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
  



  --
  ~Kevin


 ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Kevin Klues
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel?  And this sort
of cascading through multiple levels of arbitration happens all the
time.  Think about how the flash drivers on telos work.  There is
arbitration to the flash operations themselves, sitting on top of
arbitration to the msp430 usart underneath.

Kevin

On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer [EMAIL PROTECTED] wrote:
 I don't really like the idea of having two arbiters (one for ADC and
  one for DAC) and in addition another one for RefVolt, because that
  would force (some) clients to make two successful requests before they
  can actually start their operations. We have never really discussed
  this, but resource starvation is certainly an issue and one can easily
  imagine the pitfalls here.

  Jan




  On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL PROTECTED] wrote:
   What we really need I think is a way of allowing the reference voltage
component have multiple owners simultaneously.  Most components that
provide the Resource interface are used to grant exclusive access to a
device that is used to perform some operation.  The reference voltage
component is a bit different though in that once it is turned on and
set to some value, it can be used by both the ADC and the DAC at the
same time.
  
Right now what happens when you make an ADC request is that this
request implicitly requests access to the reference voltage component
underneath, giving the ADC exclusive access over it and therefore
blocking the DAC from getting access to it until the ADC is finished
with it.  Conversely, if a DAC operation were started, a similar chain
of events would occur:  Request of the DAC - Request of the
ReferenceVoltage.
  
I think the right way to solve this and still allow DAC operations and
ADC operations to be performed in parallel is to build a custom
Arbiter for the ReferenceVoltage component.  This arbiter needs to be
able to couple requests for access to the Reference Voltage with the
value it wants to be set to (i.e. provide two parameterized resource
interfaces; one for 1.5 and one for 2.5).  As long as requests are
only coming in through one of the two parameterized interfaces, the
arbiter can signal granted to all incoming requests.  Once a request
is made on the other set of interfaces though, the arbiter needs to
stop granting requests on the previous one and switch over to the new
one once all components that have been granted requests on the other
side have called release (just use a reference counter or something
similar and switch over once it reaches 0).
  
On top of this then you then have a separate (normal) arbiter for the
ADC and another one for the DAC.
  
Kevin
  
  
  
On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] wrote:
 I like Sandip's idea to create an arbiter that reserves use of refvolt 
 to the first
  process that asks, but also responds to queries about the refvolt 
 value.

  Do arbiters as they are now allow for keeping a queue of asking 
 routines satisfied
  with a resource with no breaks?

  Would a shared arbiter for DAC and ADC be able to handle both these 
 cases:
  1.  ADC is claiming a resource for a longer time than DAC asks for it, 
 responds with volt value,
  DAC runs and stops before  ADC stops, and ADC keeps using it 
 uninterrupted?
  2.  ADC asks for a resource, then DAC asks for it, and starts sharing 
 it,
   ADC stops and releases resource in a way that DAC keeps using 
 it uninterrupted?



   - Original Message 
   From: Jan Hauer [EMAIL PROTECTED]



 Alternatively we could agree that ADC and DAC
   share the same arbiter, which makes arbitration a lot easier, but is
   less efficient because you'd never be able to run ADC and DAC in
   parallel.
   Jan
  

  I have a third alternative, so it's not stopping me completely from 
 going ahead.

  To get my soil moisture sensors supplied
  with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program 
 to adjust it to
  2.50 V, but it seems useful to have more options.


  John Griessen

  --
  Ecosensory   Austin TX
  tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
  
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

  
  
  
--
~Kevin
  
  
   ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
  




-- 
~Kevin

Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Jan Hauer
 If you don't have separate arbiters for the ADC and the DAC how can
  you ever allow them to perform operations in parallel?  And this sort
  of cascading through multiple levels of arbitration happens all the
  time.  Think about how the flash drivers on telos work.  There is
  arbitration to the flash operations themselves, sitting on top of
  arbitration to the msp430 usart underneath.

As long as two resources were not double used this practically never
was an issue, but now it becomes more probable:

AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.

Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.

Jan



  Kevin



  On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer [EMAIL PROTECTED] wrote:
   I don't really like the idea of having two arbiters (one for ADC and
one for DAC) and in addition another one for RefVolt, because that
would force (some) clients to make two successful requests before they
can actually start their operations. We have never really discussed
this, but resource starvation is certainly an issue and one can easily
imagine the pitfalls here.
  
Jan
  
  
  
  
On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL PROTECTED] wrote:
 What we really need I think is a way of allowing the reference voltage
  component have multiple owners simultaneously.  Most components that
  provide the Resource interface are used to grant exclusive access to a
  device that is used to perform some operation.  The reference voltage
  component is a bit different though in that once it is turned on and
  set to some value, it can be used by both the ADC and the DAC at the
  same time.

  Right now what happens when you make an ADC request is that this
  request implicitly requests access to the reference voltage component
  underneath, giving the ADC exclusive access over it and therefore
  blocking the DAC from getting access to it until the ADC is finished
  with it.  Conversely, if a DAC operation were started, a similar chain
  of events would occur:  Request of the DAC - Request of the
  ReferenceVoltage.

  I think the right way to solve this and still allow DAC operations and
  ADC operations to be performed in parallel is to build a custom
  Arbiter for the ReferenceVoltage component.  This arbiter needs to be
  able to couple requests for access to the Reference Voltage with the
  value it wants to be set to (i.e. provide two parameterized resource
  interfaces; one for 1.5 and one for 2.5).  As long as requests are
  only coming in through one of the two parameterized interfaces, the
  arbiter can signal granted to all incoming requests.  Once a request
  is made on the other set of interfaces though, the arbiter needs to
  stop granting requests on the previous one and switch over to the new
  one once all components that have been granted requests on the other
  side have called release (just use a reference counter or something
  similar and switch over once it reaches 0).

  On top of this then you then have a separate (normal) arbiter for the
  ADC and another one for the DAC.

  Kevin



  On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] 
 wrote:
   I like Sandip's idea to create an arbiter that reserves use of 
 refvolt to the first
process that asks, but also responds to queries about the refvolt 
 value.
  
Do arbiters as they are now allow for keeping a queue of asking 
 routines satisfied
with a resource with no breaks?
  
Would a shared arbiter for DAC and ADC be able to handle both these 
 cases:
1.  ADC is claiming a resource for a longer time than DAC asks for 
 it, responds with volt value,
DAC runs and stops before  ADC stops, and ADC keeps using 
 it uninterrupted?
2.  ADC asks for a resource, then DAC asks for it, and starts 
 sharing it,
 ADC stops and releases resource in a way that DAC keeps 
 using it uninterrupted?
  
  
  
 - Original Message 
 From: Jan Hauer [EMAIL PROTECTED]
  
  
  
   Alternatively we could agree that ADC and DAC
 share the same arbiter, which makes arbitration a lot easier, but 
 is
 less efficient because you'd never be able to run ADC and DAC in
 parallel.
 Jan

  
I have a third alternative, so it's not stopping me completely from 
 going ahead.
  
To get my soil moisture sensors supplied

Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Kevin Klues
Why would you ever allow AdcClient2 to successfully be granted the ADC
before it was granted the RefVolt?  You would need to make sure that
it had access to the refvolt before signaling a granted for the ADC
woudn't you?

Kevin

On Fri, Feb 15, 2008 at 1:45 AM, Jan Hauer [EMAIL PROTECTED] wrote:
  If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel?  And this sort
of cascading through multiple levels of arbitration happens all the
time.  Think about how the flash drivers on telos work.  There is
arbitration to the flash operations themselves, sitting on top of
arbitration to the msp430 usart underneath.

  As long as two resources were not double used this practically never
  was an issue, but now it becomes more probable:

  AdcClient1 successfully requests RefVolt.
  Then AdcClient2 successfully requests ADC.
  Then AdcClient1 blocks on request to ADC.
  Then AdcClient2 blocks on request to RefVolt.
  Deadlock.

  Pushing the solution to upper layers is dangerous - I'm saying we
  should avoid this situation as much as we can in the first place.
  Maybe we can think of other solutions, e.g. wrappers that perform
  multiple request operations for you (in a non-greedy way) on top of
  multiple arbiters.

  Jan




  
Kevin
  
  
  
On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer [EMAIL PROTECTED] wrote:
 I don't really like the idea of having two arbiters (one for ADC and
  one for DAC) and in addition another one for RefVolt, because that
  would force (some) clients to make two successful requests before they
  can actually start their operations. We have never really discussed
  this, but resource starvation is certainly an issue and one can easily
  imagine the pitfalls here.

  Jan




  On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL PROTECTED] 
 wrote:
   What we really need I think is a way of allowing the reference 
 voltage
component have multiple owners simultaneously.  Most components 
 that
provide the Resource interface are used to grant exclusive access 
 to a
device that is used to perform some operation.  The reference 
 voltage
component is a bit different though in that once it is turned on and
set to some value, it can be used by both the ADC and the DAC at the
same time.
  
Right now what happens when you make an ADC request is that this
request implicitly requests access to the reference voltage 
 component
underneath, giving the ADC exclusive access over it and therefore
blocking the DAC from getting access to it until the ADC is finished
with it.  Conversely, if a DAC operation were started, a similar 
 chain
of events would occur:  Request of the DAC - Request of the
ReferenceVoltage.
  
I think the right way to solve this and still allow DAC operations 
 and
ADC operations to be performed in parallel is to build a custom
Arbiter for the ReferenceVoltage component.  This arbiter needs to 
 be
able to couple requests for access to the Reference Voltage with the
value it wants to be set to (i.e. provide two parameterized resource
interfaces; one for 1.5 and one for 2.5).  As long as requests are
only coming in through one of the two parameterized interfaces, the
arbiter can signal granted to all incoming requests.  Once a request
is made on the other set of interfaces though, the arbiter needs to
stop granting requests on the previous one and switch over to the 
 new
one once all components that have been granted requests on the other
side have called release (just use a reference counter or something
similar and switch over once it reaches 0).
  
On top of this then you then have a separate (normal) arbiter for 
 the
ADC and another one for the DAC.
  
Kevin
  
  
  
On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] 
 wrote:
 I like Sandip's idea to create an arbiter that reserves use of 
 refvolt to the first
  process that asks, but also responds to queries about the 
 refvolt value.

  Do arbiters as they are now allow for keeping a queue of asking 
 routines satisfied
  with a resource with no breaks?

  Would a shared arbiter for DAC and ADC be able to handle both 
 these cases:
  1.  ADC is claiming a resource for a longer time than DAC asks 
 for it, responds with volt value,
  DAC runs and stops before  ADC stops, and ADC keeps 
 using it uninterrupted?
  2.  ADC asks for a resource, then DAC asks for it, and starts 
 sharing it,
   ADC stops and releases resource in a way that DAC keeps 
 using it uninterrupted?



   

Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Jan Hauer
 Why would you ever allow AdcClient2 to successfully be granted the ADC
  before it was granted the RefVolt?  You would need to make sure that
  it had access to the refvolt before signaling a granted for the ADC
  woudn't you?

If we have separate ADC, DAC and RefVolt components/arbitration then
unless you put some logic on top they are decoupled and the app can
use them in whatever order it wants. Ideally we want a client to use
only one Resource interface even if two actual resources are involved.
For this we can either use one common arbiter or put some wrapper on
top of multiple arbiters that enforces some order guaranteeing that no
deadlock can occur.

Jan



  Kevin



  On Fri, Feb 15, 2008 at 1:45 AM, Jan Hauer [EMAIL PROTECTED] wrote:
If you don't have separate arbiters for the ADC and the DAC how can
  you ever allow them to perform operations in parallel?  And this sort
  of cascading through multiple levels of arbitration happens all the
  time.  Think about how the flash drivers on telos work.  There is
  arbitration to the flash operations themselves, sitting on top of
  arbitration to the msp430 usart underneath.
  
As long as two resources were not double used this practically never
was an issue, but now it becomes more probable:
  
AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.
  
Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.
  
Jan
  
  
  
  

  Kevin



  On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer [EMAIL PROTECTED] wrote:
   I don't really like the idea of having two arbiters (one for ADC and
one for DAC) and in addition another one for RefVolt, because that
would force (some) clients to make two successful requests before 
 they
can actually start their operations. We have never really discussed
this, but resource starvation is certainly an issue and one can 
 easily
imagine the pitfalls here.
  
Jan
  
  
  
  
On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL PROTECTED] 
 wrote:
 What we really need I think is a way of allowing the reference 
 voltage
  component have multiple owners simultaneously.  Most 
 components that
  provide the Resource interface are used to grant exclusive 
 access to a
  device that is used to perform some operation.  The reference 
 voltage
  component is a bit different though in that once it is turned on 
 and
  set to some value, it can be used by both the ADC and the DAC at 
 the
  same time.

  Right now what happens when you make an ADC request is that this
  request implicitly requests access to the reference voltage 
 component
  underneath, giving the ADC exclusive access over it and therefore
  blocking the DAC from getting access to it until the ADC is 
 finished
  with it.  Conversely, if a DAC operation were started, a similar 
 chain
  of events would occur:  Request of the DAC - Request of the
  ReferenceVoltage.

  I think the right way to solve this and still allow DAC 
 operations and
  ADC operations to be performed in parallel is to build a custom
  Arbiter for the ReferenceVoltage component.  This arbiter needs 
 to be
  able to couple requests for access to the Reference Voltage with 
 the
  value it wants to be set to (i.e. provide two parameterized 
 resource
  interfaces; one for 1.5 and one for 2.5).  As long as requests 
 are
  only coming in through one of the two parameterized interfaces, 
 the
  arbiter can signal granted to all incoming requests.  Once a 
 request
  is made on the other set of interfaces though, the arbiter needs 
 to
  stop granting requests on the previous one and switch over to 
 the new
  one once all components that have been granted requests on the 
 other
  side have called release (just use a reference counter or 
 something
  similar and switch over once it reaches 0).

  On top of this then you then have a separate (normal) arbiter 
 for the
  ADC and another one for the DAC.

  Kevin



  On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL 
 PROTECTED] wrote:
   I like Sandip's idea to create an arbiter that reserves use of 
 refvolt to the first
process that asks, but also responds to queries about the 
 refvolt value.

Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Kevin Klues
Sure I guess I was just assuming the wrapper approach then

Kevin

On Fri, Feb 15, 2008 at 2:33 AM, Jan Hauer [EMAIL PROTECTED] wrote:
  Why would you ever allow AdcClient2 to successfully be granted the ADC
before it was granted the RefVolt?  You would need to make sure that
it had access to the refvolt before signaling a granted for the ADC
woudn't you?

  If we have separate ADC, DAC and RefVolt components/arbitration then
  unless you put some logic on top they are decoupled and the app can
  use them in whatever order it wants. Ideally we want a client to use
  only one Resource interface even if two actual resources are involved.
  For this we can either use one common arbiter or put some wrapper on
  top of multiple arbiters that enforces some order guaranteeing that no
  deadlock can occur.



  Jan


  
Kevin
  
  
  
On Fri, Feb 15, 2008 at 1:45 AM, Jan Hauer [EMAIL PROTECTED] wrote:
  If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel?  And this 
 sort
of cascading through multiple levels of arbitration happens all the
time.  Think about how the flash drivers on telos work.  There is
arbitration to the flash operations themselves, sitting on top of
arbitration to the msp430 usart underneath.

  As long as two resources were not double used this practically never
  was an issue, but now it becomes more probable:

  AdcClient1 successfully requests RefVolt.
  Then AdcClient2 successfully requests ADC.
  Then AdcClient1 blocks on request to ADC.
  Then AdcClient2 blocks on request to RefVolt.
  Deadlock.

  Pushing the solution to upper layers is dangerous - I'm saying we
  should avoid this situation as much as we can in the first place.
  Maybe we can think of other solutions, e.g. wrappers that perform
  multiple request operations for you (in a non-greedy way) on top of
  multiple arbiters.

  Jan




  
Kevin
  
  
  
On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer [EMAIL PROTECTED] 
 wrote:
 I don't really like the idea of having two arbiters (one for ADC 
 and
  one for DAC) and in addition another one for RefVolt, because 
 that
  would force (some) clients to make two successful requests 
 before they
  can actually start their operations. We have never really 
 discussed
  this, but resource starvation is certainly an issue and one can 
 easily
  imagine the pitfalls here.

  Jan




  On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues [EMAIL 
 PROTECTED] wrote:
   What we really need I think is a way of allowing the reference 
 voltage
component have multiple owners simultaneously.  Most 
 components that
provide the Resource interface are used to grant exclusive 
 access to a
device that is used to perform some operation.  The reference 
 voltage
component is a bit different though in that once it is turned 
 on and
set to some value, it can be used by both the ADC and the DAC 
 at the
same time.
  
Right now what happens when you make an ADC request is that 
 this
request implicitly requests access to the reference voltage 
 component
underneath, giving the ADC exclusive access over it and 
 therefore
blocking the DAC from getting access to it until the ADC is 
 finished
with it.  Conversely, if a DAC operation were started, a 
 similar chain
of events would occur:  Request of the DAC - Request of the
ReferenceVoltage.
  
I think the right way to solve this and still allow DAC 
 operations and
ADC operations to be performed in parallel is to build a 
 custom
Arbiter for the ReferenceVoltage component.  This arbiter 
 needs to be
able to couple requests for access to the Reference Voltage 
 with the
value it wants to be set to (i.e. provide two parameterized 
 resource
interfaces; one for 1.5 and one for 2.5).  As long as 
 requests are
only coming in through one of the two parameterized 
 interfaces, the
arbiter can signal granted to all incoming requests.  Once a 
 request
is made on the other set of interfaces though, the arbiter 
 needs to
stop granting requests on the previous one and switch over to 
 the new
one once all components that have been granted requests on 
 the other
side have called release (just use a reference counter or 
 something
similar and switch over once it reaches 0).
  
On top of this then you then have a separate (normal) arbiter 
 for the
ADC and 

Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Philip Levis


On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:


If you don't have separate arbiters for the ADC and the DAC how can
 you ever allow them to perform operations in parallel?  And this  
sort

 of cascading through multiple levels of arbitration happens all the
 time.  Think about how the flash drivers on telos work.  There is
 arbitration to the flash operations themselves, sitting on top of
 arbitration to the msp430 usart underneath.


As long as two resources were not double used this practically never
was an issue, but now it becomes more probable:

AdcClient1 successfully requests RefVolt.
Then AdcClient2 successfully requests ADC.
Then AdcClient1 blocks on request to ADC.
Then AdcClient2 blocks on request to RefVolt.
Deadlock.

Pushing the solution to upper layers is dangerous - I'm saying we
should avoid this situation as much as we can in the first place.
Maybe we can think of other solutions, e.g. wrappers that perform
multiple request operations for you (in a non-greedy way) on top of
multiple arbiters.


Sure, badly written locking code can cause deadlock. Is there a case  
when a client wants the ADC but *not* the RefVolt? The typical  
solution to this is to layer them. There are many examples where an  
abstraction needs multiple resources. The arbiters paper in SOSP goes  
into how you do this, with the Light/Temp sensor board example. On  
the micasb, both sensors requires the ADC and share a pin; so you  
acquire the pin before putting a request to the ADC (Figure 13).


Phil


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-15 Thread Kevin Klues
Thats fine, but I think the point is that if the ADC reading you are
about to take needs to use the refernece voltage, access should NOT be
granted to the ADC until access to the reference voltage has been
granted.  If you use VCC, you don't need to wait for this.  The
information about which voltage source to use should be encapsulated
inside the configuration settings for the ADC reading you are about to
take, and not be changable without first releasing and then reaquring
the resource.

Kevin

On Fri, Feb 15, 2008 at 10:48 AM, Andreas Koepke
[EMAIL PROTECTED] wrote:
 Philip Levis:


 
   On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
  
   If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel?  And this sort
of cascading through multiple levels of arbitration happens all the
time.  Think about how the flash drivers on telos work.  There is
arbitration to the flash operations themselves, sitting on top of
arbitration to the msp430 usart underneath.
  
   As long as two resources were not double used this practically never
   was an issue, but now it becomes more probable:
  
   AdcClient1 successfully requests RefVolt.
   Then AdcClient2 successfully requests ADC.
   Then AdcClient1 blocks on request to ADC.
   Then AdcClient2 blocks on request to RefVolt.
   Deadlock.
  
   Pushing the solution to upper layers is dangerous - I'm saying we
   should avoid this situation as much as we can in the first place.
   Maybe we can think of other solutions, e.g. wrappers that perform
   multiple request operations for you (in a non-greedy way) on top of
   multiple arbiters.
  
   Sure, badly written locking code can cause deadlock. Is there a case
   when a client wants the ADC but *not* the RefVolt? The typical solution
   to this is to layer them. There are many examples where an abstraction
   needs multiple resources. The arbiters paper in SOSP goes into how you
   do this, with the Light/Temp sensor board example. On the micasb, both
   sensors requires the ADC and share a pin; so you acquire the pin before
   putting a request to the ADC (Figure 13).

  Yes -- you can also use Vcc as reference for the ADC. This is how I do
  CCA on the eyesIFX, switching around with the RefVolt would take too
  much time, and precision is not needed.

   Phil

 
  
   ___
   Tinyos-devel mailing list
   [EMAIL PROTECTED]
   https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
  

  ___
  Tinyos-devel mailing list
  [EMAIL PROTECTED]
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel




-- 
~Kevin
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-14 Thread John Griessen

I like Sandip's idea to create an arbiter that reserves use of refvolt to the 
first
process that asks, but also responds to queries about the refvolt value.

Do arbiters as they are now allow for keeping a queue of asking routines 
satisfied
with a resource with no breaks?

Would a shared arbiter for DAC and ADC be able to handle both these cases:
1.  ADC is claiming a resource for a longer time than DAC asks for it, responds 
with volt value,
DAC runs and stops before  ADC stops, and ADC keeps using it 
uninterrupted?
2.  ADC asks for a resource, then DAC asks for it, and starts sharing it,
 ADC stops and releases resource in a way that DAC keeps using it 
uninterrupted?



- Original Message 
From: Jan Hauer [EMAIL PROTECTED]



Alternatively we could agree that ADC and DAC

share the same arbiter, which makes arbitration a lot easier, but is
less efficient because you'd never be able to run ADC and DAC in
parallel.
Jan



I have a third alternative, so it's not stopping me completely from going ahead.

To get my soil moisture sensors supplied
with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program to adjust 
it to
2.50 V, but it seems useful to have more options.

John Griessen

--
Ecosensory   Austin TX
tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

2008-02-14 Thread Kevin Klues
What we really need I think is a way of allowing the reference voltage
component have multiple owners simultaneously.  Most components that
provide the Resource interface are used to grant exclusive access to a
device that is used to perform some operation.  The reference voltage
component is a bit different though in that once it is turned on and
set to some value, it can be used by both the ADC and the DAC at the
same time.

Right now what happens when you make an ADC request is that this
request implicitly requests access to the reference voltage component
underneath, giving the ADC exclusive access over it and therefore
blocking the DAC from getting access to it until the ADC is finished
with it.  Conversely, if a DAC operation were started, a similar chain
of events would occur:  Request of the DAC - Request of the
ReferenceVoltage.

I think the right way to solve this and still allow DAC operations and
ADC operations to be performed in parallel is to build a custom
Arbiter for the ReferenceVoltage component.  This arbiter needs to be
able to couple requests for access to the Reference Voltage with the
value it wants to be set to (i.e. provide two parameterized resource
interfaces; one for 1.5 and one for 2.5).  As long as requests are
only coming in through one of the two parameterized interfaces, the
arbiter can signal granted to all incoming requests.  Once a request
is made on the other set of interfaces though, the arbiter needs to
stop granting requests on the previous one and switch over to the new
one once all components that have been granted requests on the other
side have called release (just use a reference counter or something
similar and switch over once it reaches 0).

On top of this then you then have a separate (normal) arbiter for the
ADC and another one for the DAC.

Kevin

On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] wrote:
 I like Sandip's idea to create an arbiter that reserves use of refvolt to the 
 first
  process that asks, but also responds to queries about the refvolt value.

  Do arbiters as they are now allow for keeping a queue of asking routines 
 satisfied
  with a resource with no breaks?

  Would a shared arbiter for DAC and ADC be able to handle both these cases:
  1.  ADC is claiming a resource for a longer time than DAC asks for it, 
 responds with volt value,
  DAC runs and stops before  ADC stops, and ADC keeps using it 
 uninterrupted?
  2.  ADC asks for a resource, then DAC asks for it, and starts sharing it,
   ADC stops and releases resource in a way that DAC keeps using it 
 uninterrupted?



   - Original Message 
   From: Jan Hauer [EMAIL PROTECTED]



 Alternatively we could agree that ADC and DAC
   share the same arbiter, which makes arbitration a lot easier, but is
   less efficient because you'd never be able to run ADC and DAC in
   parallel.
   Jan
  

  I have a third alternative, so it's not stopping me completely from going 
 ahead.

  To get my soil moisture sensors supplied
  with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program to 
 adjust it to
  2.50 V, but it seems useful to have more options.


  John Griessen

  --
  Ecosensory   Austin TX
  tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




-- 
~Kevin
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help