[En-Nut-Discussion] Time handling functions
ole.reinhardt at embedded-it.de
Wed May 15 14:12:59 CEST 2013
> 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. ;-)
Yes, I remember too :) Could this be the reason for several other bugs
reported in the past, which use kind of timeout calculations? Perhaps
>> 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?
Little misunderstanding. I'd like to implement some kind of software
clock, which counts seconds and ms. I do not want to remove or change
the old tick counter but add an additional ms counter, which wraps
around after 1000ms and then increments the seconds counter.
What I really want is a reliable "gettimeofday()" implementation with at
least ms resolution.
Currently we don't have a way to correctly measure the time with a
resolution of less than 1s and can not correct it with a better
resolution (using ntp for example).
Why I can't use the NutGetMillis():
NutGetMillis() and also the timer ticks do not correspond to the seconds
value returned by time() / NetGetSeonds(). Further more it wraps around
at a value which is not aligned to a full second (1000). Therefor you
can have a NutGetMillis() % 1000 value which is not necessarily 0 at the
start of a second.
So when implementing gettimeofday() we would finally need a correct
seconds and ms counter where we could apply an epoch offset (for both:
seconds and ms) to get the current "real" time.
> 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.
Yes, I understand.
> And yes, there are applications with 100ms system tick, which was the
> standard in early Nut/OS days.
Ok, in this case we could increment the ms counter by 10 at each timer
tick. However the tick timer should run at an even multiple of a
> So far, I never used Nut/OS on battery driven system. But if, then being
> woken up every millisecond may significantly increase power consumption.
I could also live with a ms counter resolution much less than 1ms, but
at least is should be correct and alligned to the starting of a full second.
> 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.
This would not help to implement the time keeping correctly. See above
Btw: Adding a software clock to the tick counter would
- increase interrupt latency / add a few more instructions to the
system tick interrupt
- Speed up NutGetSeconds() / time() etc. significantly.
I would also vote to remove the RTC query from the time() implementation
and rely on the software clock, but add a new NutRtcSync)() routine to
sync the software clock with the hardware clock.
Next we could improve the sntp implementation to correctly sync the
system time up to a ms accuracy.
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion