[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-devel
mailing list