[Tinyos Core WG] Re: TEP 102

[Cory Sharp]

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

- 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.

Best regards,
> Philippe.
>

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