[Tinyos Core WG] Re: TEP 102

[Cory Sharp]

On 10/18/06, Cory Sharp <cory at moteiv.com> wrote:
>
> 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
>


Also, making the switch from Alarm${P}C and Counter${P}C, which is what
nearly all platforms do now, to Alarm${P}${W}C and Counter${P}${W}C looks
like it will cause noticable but easily fixable breakage in variable chips
and libs which are actually using Alarm32khzC and Counter32khzC now, for
instance.  What's the best way to manage this change/update?

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