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
[EMAIL PROTECTED]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
