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

Jan Hauer jan.hauer at gmail.com
Fri Feb 15 02:33:04 PST 2008


> 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 <jan.hauer at gmail.com> 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 <hauer at tkn.tu-berlin.de> 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 <klueska at gmail.com> 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 <john at ecosensory.com> 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 <hauer at tkn.tu-berlin.de>
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  > 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 at millennium.berkeley.edu
>  >  >  >  >  >  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>  >  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >  --
>  >  >  >  >  ~Kevin
>  >  >  >  >
>  >  >  >  >
>  >  >  >  > _______________________________________________
>  >  >  >  >  Tinyos-help mailing list
>  >  >  >  >  Tinyos-help at millennium.berkeley.edu
>  >  >  >  >  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>  >  >  >  >
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >  >  --
>  >  >  ~Kevin
>  >  >
>  >  >
>  >  >
>  >
>
>
>
>  --
>  ~Kevin
>


More information about the Tinyos-help mailing list