[En-Nut-Discussion] NutGetMillis overflow documentation

[José Vallet]

Hello Ulrich.

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

Thanks again.
Jose'