[En-Nut-Discussion] Time handling functions

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Tue May 14 23:47:10 CEST 2013


>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:

    Ole> Hi all, I'm currently playing around with some timeout calculations
    Ole> and therefore looked at the implementation of time().

    Ole> It looks like the current time is calculated by the NutGetSeconds()
    Ole> counter value + epo_offs on systems without an rtc, right?

    Ole> NutGetSeconds() itself uses NutGetTickCount() as base, which is a
    Ole> milliseconds counter on most platforms.

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

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

    Ole> Have I missed anything?


What about about a 64-bit millisecond counter? 

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

    Ole> In other words:

    Ole> Would'nt it be a good idea to keep track of a seconds counter and a
    Ole> milliseconds counter in the timer interrupt in addition to the tick
    Ole> counter?

    Ole> pro:

    Ole> We could simplify NetGetSeconds and other time handling functions
    Ole> as we would not have to do expensive multiplications and divisions

    Ole> We could get an own milliseconds counter which wrappes around after
    Ole> 1000 ms. This would help to implement c-lib functions like
    Ole> gettimeofday()

    Ole> contra:

Hard to handle atomic access. Atomic access to 64-bit is easier.

    Ole> A few more instructions in the timer interrupt.  Works well only on
    Ole> systems with a system tick timer with 1 ms resolution. (But do we
    Ole> really have other system tick timer implementations?)

    Ole> Any comments?


-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


More information about the En-Nut-Discussion mailing list