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