[Tinyos Core WG] Re: TEP 102

[David Gay]

I'm waking this thread up so we can finalise tep 102. It looks like
the only thing left was to add the LocalTime-related HIL changes.
Philippe, do you agree that was the last outstanding issue? Cory, do
you want to make that change (as outlined below), or shall I?

On 10/23/06, Cory Sharp <cory at moteiv.com> wrote:
> On 10/23/06, Philippe Bonnet <bonnet at diku.dk> wrote:
> > Dear Cory, David,
> >
> > Cory addressed most of the issues I raised.
> >
> > It looks to me like the remaining issues are almost solved:
> > - Nobody disagreed with Phil's point about keeping binary milliseconds and
> > introducing 1kHz if necessary. If all agree, this should be noted in the
> > TEP.
>
> I think you missed the followup discussion in the thread "Unit of time in
> TOS2":
>
> 1) Leave TMilli and TMicro as decimal names
> 2) Platform implementations may very well be off by ones of percent
>  3) Accuracy is not guaranteed by the TEP, anyway, because
> 3.a) Variations in hardware components between platforms
> 3.b) The internal clocks may significantly drift with temperature/voltage,
> dwarfing the 2-5% binary/decimal variance
>
> The implication for TEP 102 is then we need to actually soften up the
> language about "binary" units (though perhaps leave some discussion in there
> about it), not strengthen in by renaming the precision tags.
>
> There is some agreement on this, so any objections should be made soon.
>
> > - the discussion about LocalTime. It reads like you reached an agreement
> (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/). Did I understand correctly?
>
> I do not believe we quite finished the discussion on this.  One more point I
> was going to make is that requiring a platform to provide CounterMilli32C
> just to derive LocalTimeMilliC could be onerous if an overflow flag isn't
> available on the platform.  Because, deriving an 32-bit overflow flag in a
> native 64-bit counter or when an overflow flag does not exist is hard.  I
> don't know of such a platform off the top of my head, however nothing in the
> "HIL requirements" currently exposes an overflow.
>
> Given that, it may be most appropriate just to add LocalTimeMilliC to the
> HIL requirements.  That seems better anyway since it is more to the point.
> Then, along the lines of this discussion, it is makes sense to require a
> LocalTime${P}C component for any Counter${P}32C in the "HAL guidelines".
>
> Recap, my new recommendation is
>
> 1) As a HIL requirement, have the platform provide LocalTimeMilliC
> 2) As a HAL guidelines, have the platform provide LocalTime${P}C for any
> Counter${P}32C

This hasn't been done yet, has it?

> > - the discussion about handling the switch from Alarm${P}C and
> Counter${P}C
> > to to Alarm${P}${W}C and Counter${P}${W}C. Based on David's mail, it looks
> > like there is no real concern. Is that correct?
>
> That is correct.  the MSP430 platform has been migrated to the correct
> naming scheme Alarm${P}${W}C and Counter${P}${W}C.
>
> > Can you let me know about the progresses on those issues. Do you see other
> > outstanding issues before the TEP can be finalized?
>
> Comments or confirmation on the above two issues is appreciated.

David