[En-Nut-Discussion] NutGetMillis overflow documentation

[Ulrich Prinz]

Hi José,

anyone should be able to add a bugreport in sourceforge.
But it may be, that you need to create an account there and assign to 
the project.

However, you're right with your calculation. The question is, what do 
you like to do with NutGetMillis()?
Normally you do timespan calculations that look like this:

if( now-past < span) { wait a bit }

These type of call will result in a jitter with every overflow.

A second unusual usecase might be to determine the action to do now from 
the exact time:

now = NutGetMilis();
if (now == time1) { action1() }
else if (now == time2) { action }

The example is simplified as you need to add some derivation to the 
times. It will be very unlikely to hit a ms precisely. However both 
examples are not a good way to use system timers in no system.

If you need an exact point of time to execute a function call, create 
your own timer. Nut/OS allows to do this as well in the higher timer 
functions as it allows it in the system timer too. For example one, you 
can decide, if the function should sleep and give CPU to other pending 
tasks (NutSleep(n)) or if it must stay in the actual thread and delay ( 
NutDelay(n)).

For the second example it is a matter of how precise your calls need to 
be. Add a call to the seconds counter update or add some small code to 
the system timer. Your decision. Create your own counter, counting 
exactly and only as high as needed, reset it in a controlled way or use 
a state machine.

If a small ammount of jitter is acceptable, write a state machine thread 
and use NutSleep or NutDelay as needed.

It is never, never, never a good idea to use a running counter with a 
possible overflow for timing related calls. If this sounds a bit like a 
teacher and if you know all that, forgive me, but the next guy stumbling 
across that, this might help.

For now I add a tracker report for the wrong documentation.

Best regards, Ulrich

José Vallet schrieb:
> Hello all.
> 
> NutGetMillis returns an uint32_t, and (2^32)/1000/3600/24 is about 49.71 
> (days). So the overflow of the amount of milliseconds since start time 
> is maximum about 49.71 days, and not 7.9 _years_ as is suggested in the 
> documentation.
> 
> I bring this to notice as I found this info not only in the comments of 
> the function, but also now in the NutOS Software Manual (page 37)
> http://www.ethernut.de/pdf/enswm28e.pdf
> 
> The issue with the comments of the function has been discussed several times
> (Nov 2005) 
> http://groups.google.com/group/osdeve_mirror_rtos_en-nut-discussion/browse_frm/thread/a54f5e0257aa4a25/fccf4fa9ed9534d6?hl=en&lnk=gst&q=+NutGetMillis+overflow+#fccf4fa9ed9534d6
> (Nov 2007)
> http://groups.google.com/group/osdeve_mirror_rtos_en-nut-discussion/browse_frm/thread/e874525531b847f5/afc67a3e8fb55b7a?hl=en&lnk=gst&q=+NutGetMillis+overflow+#afc67a3e8fb55b7a
> (Feb 2008)
> http://groups.google.com/group/osdeve_mirror_rtos_en-nut-discussion/browse_frm/thread/3a6af336fd0a481b/47209d582e46ad5e?hl=en&lnk=gst&q=+NutGetMillis+overflow+#47209d582e46ad5e
> 
> In one of these threads Harald suggested to add a bug report. I cannot 
> add it myself.
> 
> Regards
> José
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion