[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator
hauer at tkn.tu-berlin.de
Sun Feb 17 05:51:49 PST 2008
On Feb 15, 2008 7:59 PM, Kevin Klues <klueska at gmail.com> 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.
> On Fri, Feb 15, 2008 at 10:48 AM, Andreas Koepke
> <koepke at tkn.tu-berlin.de> 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
> > > Tinyos-devel at millennium.berkeley.edu
> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> > >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> Tinyos-help mailing list
> Tinyos-help at millennium.berkeley.edu
More information about the Tinyos-help