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

[David Gay]

On 10/18/05, Joe Polastre <joe at polastre.com> wrote:
> On 10/18/05, David Gay <dgay42 at gmail.com> wrote:
> > Transformed alarms use the counter, so there's no gain there.  And at
> > the lowest level, including both doesn't cost either because dead-code
> > elimination will remove the part which isn't used... That only leaves
> > transformed counters where the alarm isn't used (which I suggested
> > leaving around).
>
> Even if the Alarm isn't used, the interrupt is signalled into that
> component and thus adds space for the processing of the Alarm.  This
> occurs even if noone wires to the Alarm.  The problem is the
> propogation of interrupts (async) from the bottom up through the stack
> when it isn't necessary.  Thus, in this case, you do get the extra
> code space---dead code elimination doesn't help you there.  This is
> especially true when you transform to a 32-bit Alarm when the system
> doesn't use the alarm or the user is only accessing the 16-bit
> interface.

Except that your argument doesn't hold for my proposal except for
exactly one case: the platform builds a 32-bit alarm+counter out of a
hardware timer, and an application only uses the counter (*). All the
other cases would be handled by the component model (unused components
aren't included...) and dead-code elimination (accessing only the
counter of a hardware alarm+counter).

Btw, there's a reason I'm always saying hardware rather than 16-bit
counter - we clearly don't want to suggest that platforms always offer
16-bit alarms/counters (consider the mica family).

David

*: and frankly, given that this is already a platform-specific
application, if code space becomes an issue, it could build it's own
32-bit counter using just TransformCounterC.

_______________________________________________
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