[Tinyos-8051wg] Re: [Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Timer.fired

[Cory Sharp]

On 5/23/05, Philip Levis <pal at cs.berkeley.edu> wrote:
> On May 20, 2005, at 1:54 AM, Cory Sharp wrote:
> > Okay, here's a even more simple counter proposal from talking with
> > Joe, which boils down to "in this respect, go back to TinyOS1.x":
> 
> Does this require more state (e.g., another byte for count)? It would
> seem to me that it would, but you tend to come up with crazy
> implementations that violate my cost assumptions. :)

There's no count.  I'll give a brief overview.  The timer system
executes timers in a task, which takes one pass over the timers,
signalling any that have fired and calculating the next soonest event.
 Each time a periodic timer fires, it prepares itself for its next
incremental event.  That could be in the past if the system can't keep
up.  After processing all of the timers, if the next soonest event is
in the past or has lapsed into the past, the execute task is
immediately posted again.  Otherwise, an alarm is set.

That behavior means that a periodic timer that has fallen behind will
cause the execute task to immediately repost.  If the system just
cannot keep up over the long term, that's tough luck and doing
something about it is left to the application.

That's the intent of VirtualizeTimerC.  It's very close to that
behavior now, though I think I have to change a couple of lines to get
it exactly into that spec.  The nice thing about all of these recent
changes is that VirtualizeTimerC is more concise and smaller than it
has ever been.

Cory

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg