[En-Nut-Discussion] Problems when NutGetMills() is close to overflow?

[Erik Lindstein]

First of all the documentation for the NutGetMills() should be updated.

I guess there are two errors in there:
--------- From 4.4.0 -------
This function returns the value of a counter, which is incremented
every system timer tick. During system start, the counter is cleared
to zero and will overflow with the 32 bit tick counter (4294967296).
With the default 1024 ticks/s this will happen after ##### 7.9 years.
##### The resolution is also given by the system ticks.


Note:
There is intentionally no provision to modify the seconds counter.
Callers can rely on a continuous update and use this value for system
tick independend timeout calculations. Depending on
Returns:
Value of the seconds counter.
#### This is not seconds right? ####
-----------------------------------

I have some timeouts i use together with NutGetMillis().
Lets say i use it like this.

uint32_t timeout = NutGetMillis() + 10000;

for(;;)
{
       if(timeout <= NutGetMillis())
       {
               printf("Timeout - 10 Sec");
               timeout = NutGetMillis() + 10000;
       }
       NutSleep(100);
}

If timeout overflows this timeout will occur directly in the next if
statement instead of the 10sec delay i expect.

First i thought that NutGetMillis() would overflow after 7.9 years but
as that is not true i need to rewrite some of my code.
Anyone have some nice and clean code to handle this?

Also are the internal timeouts in Nut OS overflow safe?
For example the socket timeouts don´t get messed up if they occur at
the "wrong" time when NutGetMillis() is close to overflow?

Regards
--
/Erik Lindstein

-- 
/Erik Lindstein