Go Down

Topic: Resetting Millis() to zero, reset clock (Read 28081 times) previous topic - next topic

NavyVet1959

#30
Dec 06, 2018, 02:06 am Last Edit: Dec 06, 2018, 02:34 pm by NavyVet1959
A truly terrible idea for the AVR processor.


Manipulating 64-bit integers is inefficient with these processors, but for what I use it for, it's fast enough.  The events that are being scheduled are a few seconds apart at the closest and often hours or days apart -- some might even be months apart.  Having the capability to schedule events that are across multiple millis() rollover intervals was more important to me than a few extra processor cycles being spend on 64-bit arithmetic.  I will admit though that having a 584.9M year rollover is a bit more than I needed. :)

Just did a quick timing test, printing out the elapsed time between successive calls to GetTime() in my code and it works out to be 4ms, with the occasional 5ms time.  Trying the same thing with a loop of calling millis() and displaying the elapsed time using "unsigned long int" values results in mostly 3ms with the occasional 4ms value.  It's possible that the Serial.println() call is taking up a good portion of that.

So, I decided to try another test without the console output... I used a loop of 10,000 where millis() was called, stored as the current time, calculate the elapsed time, and then store the current time as the previous time.  This results in 15ms for the 10,000 iterations of the loop.

Changing this to use the 64-bit unsigned integer in my GetTime() routine results in 187ms for the 10,000 iterations of the loop.  So, it most definitely takes a lot longer to do 64-bit math.  For some systems, this might be an unacceptable time penalty.  For other systems though, this might be perfectly acceptable.

Code: [Select]

        typedef unsigned long long int  TIME64;

        TIME64         ct;                          /* current time */
        TIME64         pt = 0;                      /* previous time */
        TIME64         et;                          /* elapsed time */
        unsigned long  startTime;
        unsigned long  endTime;
        int            i;

        Serial.println("Testing millis() loop...");
        startTime = millis();
        for (i = 0; i < 10000; i++) {
            ct = GetTime();
            et = ct - pt;
            // Serial.println(et);
            pt = ct;
        }
        endTime = millis();
        Serial.print("startTime=");
        Serial.print(startTime);
        Serial.print(", endTime=");
        Serial.print(endTime);
        Serial.print(", elapsedTime=");
        Serial.println(endTime-startTime);

Robin2

The event handler might generate future events in the handling of the current event that it is processing.  It is possible that it might be necessary to schedule an event that will happen after multiple millis() rollovers.
That sounds like a role for a Real Time Clock

Alternatively why not use millis() to update a 1-second counter in an unsigned-long variable. That should see you out.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Coding Badly

...fast enough...
"Fast enough" is secondary to the failure to produce a viable image because of the oh-so-fun inability to find a spill register.


NavyVet1959

"Fast enough" is secondary to the failure to produce a viable image because of the oh-so-fun inability to find a spill register.


I haven't had the pleasure to have that error *yet*, but I've done a lot of 'C' programming in non-memory-protected architectures over the years and I've had my share of fun with strange errors that were hard to trace down.  Ones where you put a printf statement in the code to see the value of some variable at some point and when you add the code, the program either starts working correctly or the error gets moved elsewhere.  Of course, you *know* you are overwriting your code *somewhere*, but trying to find it can be a pain. :)

Is there something about the "long long" data types that might cause this sort of error to occur more often?


Coding Badly

Is there something about the "long long" data types that might cause this sort of error to occur more often?
Datatype size, the amount of data that can be stored in processor registers, and a likely compiler limitation that prevents a stack frame from being created when too much data is being squeezed into too small of a register space.


Go Up