Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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 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. 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. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
On Feb 15, 2008 7:59 PM, Kevin Klues [EMAIL PROTECTED] wrote: Thats fine, but I think the point is that if the ADC reading you are about to take needs to use the refernece voltage, access should NOT be granted to the ADC until access to the reference voltage has been granted. If you use VCC, you don't need to wait for this. The information about which voltage source to use should be encapsulated inside the configuration settings for the ADC reading you are about to take, and not be changable without first releasing and then reaquring the resource. Yes - a client has to let you know about all the resources it needs in advance (and for the ADC we have the AdcConfigure interface for this purpose). There are many possible combinations (ADC only, ADC+RefVolt, RefVolt only (on a pin), DAC-combinations...), how smart should the wrapper be? It must of course know that RefVolt must be requested before ADC/DAC, but should this wrapper use special policies (e.g. if one client needs RefVolt+ADC but RefVolt is blocked, then another client that only needs ADC might go first even if it has requested later, etc...)? Maybe this can be generalized similar to the way we have different arbiter-policies. Jan Kevin On Fri, Feb 15, 2008 at 10:48 AM, Andreas Koepke [EMAIL PROTECTED] 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 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-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel -- ~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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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. 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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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?
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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? If we have separate ADC, DAC and RefVolt components/arbitration then unless you put some logic on top they are decoupled and the app can use them in whatever order it wants. Ideally we want a client to use only one Resource interface even if two actual resources are involved. For this we can either use one common arbiter or put some wrapper on top of multiple arbiters that enforces some order guaranteeing that no deadlock can occur. Jan 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.
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Sure I guess I was just assuming the wrapper approach then Kevin On Fri, Feb 15, 2008 at 2:33 AM, Jan Hauer [EMAIL PROTECTED] wrote: 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? If we have separate ADC, DAC and RefVolt components/arbitration then unless you put some logic on top they are decoupled and the app can use them in whatever order it wants. Ideally we want a client to use only one Resource interface even if two actual resources are involved. For this we can either use one common arbiter or put some wrapper on top of multiple arbiters that enforces some order guaranteeing that no deadlock can occur. Jan 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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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). Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Thats fine, but I think the point is that if the ADC reading you are about to take needs to use the refernece voltage, access should NOT be granted to the ADC until access to the reference voltage has been granted. If you use VCC, you don't need to wait for this. The information about which voltage source to use should be encapsulated inside the configuration settings for the ADC reading you are about to take, and not be changable without first releasing and then reaquring the resource. Kevin On Fri, Feb 15, 2008 at 10:48 AM, Andreas Koepke [EMAIL PROTECTED] 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 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-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel -- ~Kevin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
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