[En-Nut-Discussion] NutGetMillis overflow documentation
jose.vallet at hut.fi
Mon Feb 8 12:28:49 CET 2010
I see the point on how the calculation of the milliseconds are done to
avoid overflow in the operations and to carefully stay within 32 bit
values. Thanks for the detailed explanation again.
Ulrich Prinz wrote:
> But... the part seconds*1000 will overflow every 49.71 days but that
> doesn't matter as it is derived from ticks and ticks is derived from a
> system clock that is running with 1024ticks per second and therefore
> overflowing in 48.55 days resetting the seconds calculation too.
Yes, I noticed this also, the overflow is every 48.55 days.
> To have a precise timestamp one must count the milliseconds himself and
> reset them to 0 as seconds are incremented. Then use the complete time
> hh:mm:ss:ms as a stamp or combine it into something.
In our case having the time in ms is convenient as we plot the data from
sensors straight in (running) charts, and they don't like time in a
format like hh:mm:ss:ms.
> But it is a bit difficult to calculate precise 1000ms from a timer that
> is giving 1024 ticks per second. A jitter will be imminent or you need
> to change the crystal to a value that can be divided by something that
> gives 1000ticks/second.
> An other simple way might be to add another byte/word/long to the
> calculation. If the counter is extended to 48 bits, the overflow will
> happen in 34 years. Most devices will not live that long and the
> additional calculation will not consume to much time and memory on an AVR.
> On an ARM a calculation with 32bits is faster than anything else. And
> with 64bits the overflow will happen in 571.233.829 years...
> This is, ah.. roughly 20% of the time they expect the sun will exist?
This was the solution that we were thinking about when we found out the
problem of the shorter overflow. Definetly 20% of the "sun life" sounds
like a strong guarantee :). But fortunately our experiments are lasting
way shorter than we expected, so no need for a change in the time
stamping procedure (yet).
More information about the En-Nut-Discussion