[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Timers in 2.x

[Cory Sharp]

Having many little components on top does not preclude an optimized
mega-component, if it makes sense of the hardware platform.  The
converse is not true.  This is what Joe is saying.

Likewise, the timer library components are there to help build up a
system, but their use is only MAY or SHOULD, not MUST.  Writing timing
system stuff can be tricky and full of corner-cases.  Having a system
library of small components makes it easier to independently verify
functionality.  But, the use of those components is again not
necessary if it makes sense for the system to independently implement
something larger and more optimal.

So, the Timer TEP allows for a bigger component to be written for Mica
while not mandating it for Telos.

I dont have thoughts about specifying precision, someone else can
weigh in on that :).

Cory

On 10/18/05, David Gay <dgay42 at gmail.com> wrote:
> Working on the NSDI paper, I came up with a few of issues related to
> 2.x's timers:
>
> - there's a lot of semi-independent, not very large components (hal
> alarm, hal counter, 32 kHz 32-bit alarm, 32kHz 32-bit counter, 1 kHz
> 32-bit alarm, 1 kHz 32-bit counter, virtualized 32kHz timer,
> virtualized 1kHz timer)
>
> - there are opportunities for optimizing the hal->32-bit alarm/counter
> transformation if they are done together
>  Basically: if the alarm deadline is further away than one full cycle
> of the hal timer, you can avoid setting a low-level alarm and rely
> instead on the overflow event to know when it's time to actually set
> an alarm. This reduces interrupt overhead from 3
> interrupts/hal-timer-cycle (two of which set an alarm) to 1 (which
> typically just needs to increment or decrement a couple of variables).
>
> - even with the above optimization, using the 8-bit timer to provide a
> 32kHz timer on the mica family keeps the processor busy an additional
> ~0.1% of the time, significantly affecting maximum mote lifetime
>
> So there's two questions/proposals:
> - I'd like to suggest merging the components which offer the Alarm and
> Counter interfaces (this basically means cutting the number of
> components above by two). We would keep the option of using a hardware
> timer as a Counter only, though.
> - Do we want to mandate the presence of a 32kHz timer in TinyOS 2.x?
>   If so:
>   - how precise should it be?
>   - should we expect low-power operation to be possible while it's in use?
>
>   (if you answer "not too precise" and "no", you can use one of the
> ATmega128's 16-bit timers to get approximate 32kHz timing -
> approximate means something between 28 and 31kHz depending on whether
> you use the external crystal or the internal oscillator)
>
>   Another option is to make the 32kHz timer's precision configurable
> by applications. In practice, on mica's, this means having 8 or 1ms
> precision)
>
> David
>
> _______________________________________________
> 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
>

_______________________________________________
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