[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator
koepke at tkn.tu-berlin.de
Fri Feb 15 10:48:47 PST 2008
> 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.
>> 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.
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
More information about the Tinyos-help