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

Kevin Klues klueska at gmail.com
Fri Feb 15 04:12:22 PST 2008


Sure.... I guess I was just assuming the wrapper approach then

Kevin

On Fri, Feb 15, 2008 at 2:33 AM, Jan Hauer <jan.hauer at gmail.com> 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 <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
>  >
>



-- 
~Kevin


More information about the Tinyos-help mailing list