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
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. 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 On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vlado On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ 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
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Jan, In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? Here's one scenario which might be common to a lot of sensing apps: An app uses RefVolt via Msp430AutoRVGClient to do its sensing and requires some reference (say 2.5V). Occasionally, the app also needs to use the DAC, with the same reference voltage, for instance, to change the gain setting on the sensor by varying the DAC voltage. If both used the same reference, could they still not work in parallel? Also, the DAC has a 3x multiplier setting so effectively it can produce the same range of outputs regardless of what reference voltage is being used by others (ADC). We could (re)implement the getState() function in RefVolt so that the DAC client can figure out which, if any, reference voltage is being used by the ADC and scale its inputs accordingly. But perhaps I'm missing something even more fundamental here as to why they can't run in parallel. Sandip - Original Message From: Jan Hauer [EMAIL PROTECTED] To: Vlado Handziski [EMAIL PROTECTED] Cc: TinyOS Development [EMAIL PROTECTED]; tinyos-help@Millennium.Berkeley.EDU list tinyos-help@millennium.berkeley.edu Sent: Thursday, February 14, 2008 10:42:02 AM Subject: Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2 Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. 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 On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vlado On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ 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 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? By parallel I meant at the same time: in the second approach if two components would request to use the the ADC and DAC at the same time (i.e. overlapping in time) the second of them would have to wait until the first is finished (it would simply get the Resource.granted event later). But both, ADC and DAC could of course be used in the same app. If both clients wanted to use the RefVolt arbiter (possible at different settings), then there's no way around. But - and that is the drawback - if the ADC client wasn't even using the RefVolt the DAC client would still have to wait for the ADC client operation to finish. Jan On Thu, Feb 14, 2008 at 5:14 PM, Sandip Bapat [EMAIL PROTECTED] wrote: Jan, In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? Here's one scenario which might be common to a lot of sensing apps: An app uses RefVolt via Msp430AutoRVGClient to do its sensing and requires some reference (say 2.5V). Occasionally, the app also needs to use the DAC, with the same reference voltage, for instance, to change the gain setting on the sensor by varying the DAC voltage. If both used the same reference, could they still not work in parallel? Also, the DAC has a 3x multiplier setting so effectively it can produce the same range of outputs regardless of what reference voltage is being used by others (ADC). We could (re)implement the getState() function in RefVolt so that the DAC client can figure out which, if any, reference voltage is being used by the ADC and scale its inputs accordingly. But perhaps I'm missing something even more fundamental here as to why they can't run in parallel. Sandip - Original Message From: Jan Hauer [EMAIL PROTECTED] To: Vlado Handziski [EMAIL PROTECTED] Cc: TinyOS Development [EMAIL PROTECTED]; tinyos-help@Millennium.Berkeley.EDU list tinyos-help@millennium.berkeley.edu Sent: Thursday, February 14, 2008 10:42:02 AM Subject: Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2 Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. 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 On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vl o On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ 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 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
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
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. 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
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vlado On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ 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
