[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator
pal at cs.stanford.edu
Tue Feb 19 18:36:21 PST 2008
On Feb 15, 2008, at 10:48 AM, Andreas Koepke 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
>>>> 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
>>> 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.
OK, so you layer the components such that there is a lock order. You
shouldn't be pushing the lock order to upper layers. In the best
case, abstract through interfaces so you have a single piece of code
that has a single order. In the worst case, make sure the small
number of implementations all do it correctly.
More information about the Tinyos-help