[Tinyos Core WG] Re: TEP 102

[Cory Sharp]

On 10/18/06, David Gay <dgay42 at gmail.com> wrote:
>
> On 10/18/06, Cory Sharp <cory at moteiv.com> wrote:
> > Quick question: in section 3 we list the standard Alarm and Counters
> > components than should exist for the precision and widths provided by
> the
> > platform.  Do we want to provide for a LocalTime component, as well?
> > LocalTime is actually useful when you don't care to handle with the
> overflow
> > event, which is common in applications.  But, there are a couple of
> unique
> > things about LocalTime
> >
> > * The width of a LocalTime interface is always 32-bits, so the LocalTime
> > components would only by precision
> >
> > * The transformation from Counter to LocalTime is trivial, and can be
> > derived from the Counter${P}32C components.  So, instead of prescribing
> > LocalTime components for the platform, do we want to just create in
> > tos/lib/timers/ the three LocalTime${P}C components for the standard
> > precisions in the TEP?
>
> Hmm, after thinking a bit, I still have no opinion ;-)
>
> For:
>   - avoids writing the same uses of CounterToLocalTime in a bunch of
> places
>   - provides consistent name for LocalTime
>
> Against:
>   - currently, LocalTime is available via HilTimerMilliC only
> (strangely not in TimerMilliC) (ok, this is not exactly an against -
> but having LocalTime in two places seems slightly confusing)
>   - Counter${P}32C may not always exist, so the appearance that
> LocalTime${P} exists may be confusing
>
> Hmm, after writing that, I'm vaguely in favour. I also wonder if we
> should put LocalTimeMilliC in the HIL? Or provides interface
> LocalTime<TMilli> in TimerMilliC?
>
> David
>


It's not as useful to put LocalTime<TMilli> in TimerMilliC since TimerMilliC
is generic.  That means you'd end up allocating a new Timer<TMilli> just to
get at a LocalTime<TMilli>.  At least for the msp430, I don't see
HilTimerMilliC providing a LocalTime interface.

I don't mind the case of Counter${P}32C not existing, causing a compile
error for LocalTime${P}C.  I like TEP 102 requiring just enough to otherwise
not be totally useless (HilTimerMilliC enabling TimerMilliC), and otherwise
just providing a good framework.  In fact, I actually like it, because it
eventually leads information TEPs describing classes of platforms that
assert more strict implementation requirements, which wrt this TEP would
just be a list of components that must exist, leaving this TEP more
versatile.

We can assert a platform MUST provide CounterMilli32C to guarantee that
LocalTimeMilliC is valid.  We can leave CounterT32khz32C and CounterMicro32C
as optional.  In which case, some nice differentiation might be to put
LocalTimeMilliC in tos/system/ and leave LocalTime32khzC and LocalTimeMicroC
in tos/lib/timer/.

Cory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20061018/3f85263e/attachment.html