I reproduced Sandip's problem and tracked it down to a bug in the ADC HAL (the overflow interrupt was not handled properly). This is now fixed in CVS as well as the bug reported some time ago about the ReadStream not working with a "usPeriod" parameter > 0xFFFF.
Jan On Sat, Mar 29, 2008 at 5:21 PM, Jan Hauer <[EMAIL PROTECTED]> wrote: > > > > You should make sure that you don't call Resource.request() while > > > you're still owner. You could do it by keeping state in some module > > > variable, but you could also do it through "if (!call > > > Resource.isOwner()) call Resource.request();" in your Timer.fired(). > > > Note that this means, that your samples might not be taken at regular > > > intervals (you lose a sample when isOwner() returns FALSE) > > > > > > That's not right. It should be valid to request while owner: this > > enqueues a request, which will be serviced (after possibly others) > > once release() is called. TEP 108 is very clear on this. > > Of course you can request while you're already owner and the first > time you do it, it will succeed (will queue the request). I was trying > to find a quick solution for the given problem, not giving a general > rule, maybe that was not clear. > There is a known potential race condition if you call release after > you've requested but before you've gotten the granted() event (see > @note in Resource.nc). Looking at the code snippet this should not > happen, but then the snippet is not the real code > (MultiChannel.dataReady is async) - Sandip, can you please post the > exact code you're running? > > Jan > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
