Hi,
I've executed BlinkToRadio application with two telosb motes for about 3
hours after adding one line of code in VirtualizeTimerC.nc.
These two motes are still operating correctly without event timer.fired()
getting lost.
It seems that the bug's been fixed.
Thank you.
Inyong Park
> Whoah, it looks like I have a blatantly ugly bug in VirtualizeTimerC
> in lib/timer/ where the remaining time is not correctly calculated for
> an overdue periodic timer.
>
> Note, the radio does not play a significant role. If you take
> Jonathan's sample application, take out all the radio stuff, and
> busywait for 1ms in the fast timer, the problem still occurs. I'm
> surprised that other platforms report to not have this problem,
> because they should.
>
> As a quick hack to see if it solves the problem on your side of
> things, try adding this one line of code at around line 100 in
> VirtualizeTimerC.nc:
>
> else
> {
> // The remaining time is non-positive (the timer had fired).
> // So add dt to convert it to remaining for the next event.
> timer->t0 += timer->dt;
> remaining += timer->dt;
> if (remaining & 0x80000000L) remaining = 0; // <-- ADD THIS
> LINE
> }
>
> If a couple of you can test that, then I'll try to mix up a cleaner
> solution and review the rest of the VirtualizeTimerC code.
>
> Thanks,
> Cory
>
> On 7/24/06, Cory Sharp <[EMAIL PROTECTED]> wrote:
>> Boomerang has no significant changes from the 2.x timer stack. We are
>> actively looking into this issue, now. - Cory
>>
>> On 7/23/06, Philip Levis <[EMAIL PROTECTED]> wrote:
>> > On Jul 23, 2006, at 11:37 AM, Jonathan Hui wrote:
>> >
>> > > After a little testing, it looks like the radio stack is still
>> alive.
>> > > I modified BlinkToRadio to maintain two timers (1ms and 1s period),
>> > > both of which attemps to send a message on each fire event. After a
>> > > few moments, the 1ms timer will fail to fire, but the 1s timer will
>> > > continue firing and sending messages. Even more interesting is that
>> > > the 1ms timer starts firing at the same period as the 1s timer.
>> > >
>> > > It's probably the case that the radio stack is somehow affecting the
>> > > operation of the msp430 timer stack and causing it to fail in
>> > > repeatedly firing the 1ms timer. Haven't dug too much into the timer
>> > > code to understand why this is.
>> > >
>> > > I've attached the modified app I used to test.
>> > >
>> > > Cory, do you have an ideas?
>> >
>> > Yeah, I should have given more background. I think it's definitely
>> > the case that it's the MSP430 timer stack, which runs into some
>> > issues when timers are at too fast a rate (e.g., 1ms). E.g., in the
>> > 2.0 tutorials, there's a part where you try using very long tasks of
>> > different length to show the run-to-completion semantics. On atm128
>> > platforms, a task that's too long causes you to lose timer events but
>> > things continue as expected; on msp430 ones, the timer stack can act
>> > erratically.
>> >
>> > Joe, Cory, does Boomerang 2.0.2 use the 2.x timer stack unchanged, or
>> > have you incorporated fixes?
>> >
>> > Phil
>> >
>>
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
