[En-Nut-Discussion] Time handling functions

[Harald Kipp]

Hi Ole,

On 14.05.2013 23:25, Ole Reinhardt wrote:

> In other words, NutGetTickCount() overflows approximately every 49,x
> days, right?

Oh, already another year is over? Just wondering, because this has been
discussed and reportedly fixed in regular time intervals. I hardly
remember a similar thread with BTNut, many years ago, where it had been
reported as fixed, wasn't it. ;-)


> But this also means, that the calculation of time() results in an error
> after 49,x days. Right?

Following your post: Yes, looks like. Probably most applications dealing
with calendar dates make use of RTC hardware, where this problem never
appears. Anyway, yes, this bug must be fixed.


> What I really need is a second counter, startet at system startup and
> increment at each 1000 system ticks (if we have 1ms system tick
> interrupt) and also a milliseconds counter, which is incremented by 1
> each millisecond (timer tick) and wrapped to 0 after 1000 increments.

Not sure, if I understood. IMHO, clearing the millisecond counter on
each full second would break timeout handling in the wait queues,
wouldn't it? That needs to be changed as well, doesn't it?


> Would'nt it be a good idea to keep track of a seconds counter and a
> milliseconds counter in the timer interrupt in addition to the tick counter?
> 
> pro:
> 
> We could simplify NetGetSeconds and other time handling functions as we
> would not have to do expensive multiplications and divisions
> 
> We could get an own milliseconds counter which wrappes around after 1000
> ms. This would help to implement c-lib functions like gettimeofday()
> 
> contra:
> 
> A few more instructions in the timer interrupt.
> Works well only on systems with a system tick timer with 1 ms
> resolution. (But do we really have other system tick timer implementations?)

These "few more" instructions will increase the global interrupt
latency. If an application uses a specific Nut/OS driver with long
interrupt handling, it's its own decision. Lengthening the timer
interrupt would apply to all applications, without any chance to fix this.

And yes, there are applications with 100ms system tick, which was the
standard in early Nut/OS days.

So far, I never used Nut/OS on battery driven system. But if, then being
woken up every millisecond may significantly increase power consumption.

My conclusion: Do not add to the timer handling without offering a
chance to switch back the old behavior via configuration.

My idea: May be there is a possibility to fix this in NetGetSeconds() only.

Regards,

Harald