[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator
pal at cs.stanford.edu
Fri Feb 15 09:14:22 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
>> 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).
More information about the Tinyos-help