[En-Nut-Discussion] Time handling functions
Ole Reinhardt
ole.reinhardt at embedded-it.de
Tue May 14 23:25:52 CEST 2013
Hi all,
I'm currently playing around with some timeout calculations and
therefore looked at the implementation of time().
It looks like the current time is calculated by the NutGetSeconds()
counter value + epo_offs on systems without an rtc, right?
NutGetSeconds() itself uses NutGetTickCount() as base, which is a
milliseconds counter on most platforms.
In other words, NutGetTickCount() overflows approximately every 49,x
days, right?
But this also means, that the calculation of time() results in an error
after 49,x days. Right?
Have I missed anything?
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.
In other words:
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?)
Any comments?
Bye,
Ole
--
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de
More information about the En-Nut-Discussion
mailing list