[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
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Andreas Helmcke]

Erik Lindstein wrote:
> 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.
>

If I am not totally mistaken the tickcounter will overflow after 49 days.

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

Unsigned subtractions will do the trick.
For example:

uint32_t lastTick = NutGetMillis();

for(;;)
{
if(NutGetMillis() - lastTick > 10000)

{
printf("Timeout - 10 Sec");

lastTick = NutGetMillis();
}
NutSleep(100);
}

Greetings,
Andreas

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Erik Lindstein]

Thank you very much Andreas.

A problem for me with that solution is that i will need to use two
variabels for each timeout.
I have a couple of timeouts that i set in different threads and it
would be nice if i could use only one uint32_t to handle each
timeout(but perhaps that's not possible)
With your solution i would need to use one uint32_t(lastTick) and one
uint16/32_t(10000) extra variable for the delay time, that i needs to
be variable.

Well perhaps i can live with that :-)

Regards
--
/Erik
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion