Why would you ever allow AdcClient2 to successfully be granted the ADC before it was granted the RefVolt? You would need to make sure that it had access to the refvolt before signaling a granted for the ADC woudn't you?
Kevin On Fri, Feb 15, 2008 at 1:45 AM, Jan Hauer <[EMAIL PROTECTED]> 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. > > Jan > > > > > > > > Kevin > > > > > > > > On Fri, Feb 15, 2008 at 12:48 AM, Jan Hauer <[EMAIL PROTECTED]> wrote: > > > I don't really like the idea of having two arbiters (one for ADC and > > > one for DAC) and in addition another one for RefVolt, because that > > > would force (some) clients to make two successful requests before they > > > can actually start their operations. We have never really discussed > > > this, but resource starvation is certainly an issue and one can easily > > > imagine the pitfalls here. > > > > > > Jan > > > > > > > > > > > > > > > On Thu, Feb 14, 2008 at 11:09 PM, Kevin Klues <[EMAIL PROTECTED]> > wrote: > > > > What we really need I think is a way of allowing the reference > voltage > > > > component have "multiple" owners simultaneously. Most components > that > > > > provide the Resource interface are used to grant exclusive access > to a > > > > device that is used to perform some operation. The reference > voltage > > > > component is a bit different though in that once it is turned on and > > > > set to some value, it can be used by both the ADC and the DAC at the > > > > same time. > > > > > > > > Right now what happens when you make an ADC request is that this > > > > request implicitly requests access to the reference voltage > component > > > > underneath, giving the ADC exclusive access over it and therefore > > > > blocking the DAC from getting access to it until the ADC is finished > > > > with it. Conversely, if a DAC operation were started, a similar > chain > > > > of events would occur: Request of the DAC -> Request of the > > > > ReferenceVoltage. > > > > > > > > I think the right way to solve this and still allow DAC operations > and > > > > ADC operations to be performed in parallel is to build a custom > > > > Arbiter for the ReferenceVoltage component. This arbiter needs to > be > > > > able to couple requests for access to the Reference Voltage with the > > > > value it wants to be set to (i.e. provide two parameterized resource > > > > interfaces; one for 1.5 and one for 2.5). As long as requests are > > > > only coming in through one of the two parameterized interfaces, the > > > > arbiter can signal granted to all incoming requests. Once a request > > > > is made on the other set of interfaces though, the arbiter needs to > > > > stop granting requests on the previous one and switch over to the > new > > > > one once all components that have been granted requests on the other > > > > side have called release (just use a reference counter or something > > > > similar and switch over once it reaches 0). > > > > > > > > On top of this then you then have a separate (normal) arbiter for > the > > > > ADC and another one for the DAC. > > > > > > > > Kevin > > > > > > > > > > > > > > > > On Thu, Feb 14, 2008 at 1:26 PM, John Griessen <[EMAIL PROTECTED]> > wrote: > > > > > I like Sandip's idea to create an arbiter that reserves use of > refvolt to the first > > > > > process that asks, but also responds to queries about the > refvolt value. > > > > > > > > > > Do arbiters as they are now allow for keeping a queue of asking > routines satisfied > > > > > with a resource with no breaks? > > > > > > > > > > Would a shared arbiter for DAC and ADC be able to handle both > these cases: > > > > > 1. ADC is claiming a resource for a longer time than DAC asks > for it, responds with volt value, > > > > > DAC runs and stops before ADC stops, and ADC keeps > using it uninterrupted? > > > > > 2. ADC asks for a resource, then DAC asks for it, and starts > sharing it, > > > > > ADC stops and releases resource in a way that DAC keeps > using it uninterrupted? > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > From: Jan Hauer <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > Alternatively we could agree that ADC and DAC > > > > > > share the same arbiter, which makes arbitration a lot easier, > but is > > > > > > less efficient because you'd never be able to run ADC and DAC > in > > > > > > parallel. > > > > > > Jan > > > > > > > > > > > > > > > > I have a third alternative, so it's not stopping me completely > from going ahead. > > > > > > > > > > To get my soil moisture sensors supplied > > > > > with 2.500 +/- .005 Volts, I could create a PWM DAC and use a > program to adjust it to > > > > > 2.50 V, but it seems useful to have more options. > > > > > > > > > > > > > > > John Griessen > > > > > > > > > > -- > > > > > Ecosensory Austin TX > > > > > tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb > ecosens1 > > > > > _______________________________________________ > > > > > Tinyos-help mailing list > > > > > Tinyos-help@millennium.berkeley.edu > > > > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > > > > > > > > > > > > -- > > > > ~Kevin > > > > > > > > > > > > _______________________________________________ > > > > Tinyos-help mailing list > > > > Tinyos-help@millennium.berkeley.edu > > > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > > > > > > -- > > ~Kevin > > > > > > > -- ~Kevin _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
