Go Down

Topic: millis() overflow -- what happens??? (Read 1 time) previous topic - next topic

SouthernAtHeart

I often use millis() to do certain things every few seconds.  Like the following example:
(LCDtime is unsigned long)
Code: [Select]
    if (millis() - LCDtime > 3000) { //Has it been 3 seconds yet?
        LCDtime = millis(); //update the timer
        UpdateLCD(); // Change the LCD messege
    }


Doesn't Millis() eventually overflow and return to zero?  Will this code still function, or will it no longer update the LCD every 3 seconds?
I do lots of different things with this style...

retrolefty

As long as you perform a subtraction operation on the time interval test calculation (as you do in your example), the 'rollover' situation at 55 days (or so) is handled fine. There was a 'famous' posting here in the past explaining how the subtraction overflow bit handles the roll over condition just fine as long as you use subtraction for your time interval test calculation.

Lefty


Simpson_Jr

I'd guess it would just continue counting as it should. In the example below I used a fake millis() counter, same variable type, starting at 20 secs before overrun (2^32).

Code: [Select]

unsigned long virtualmillis;
unsigned long LCDtime = 0;
void setup()
{
  Serial.begin(9600);
}
void loop (){
  // fake counter, to not have
  // to wait 50 days
  virtualmillis = millis() + 4294947296; 
  if (virtualmillis - LCDtime > 3000) {
    //Has it been 3 seconds yet?
    LCDtime = virtualmillis; //update the timer
    //UpdateLCD(); // Change the LCD messege
    Serial.print ("LCDtime : ");
    Serial.print(LCDtime);
    Serial.print (", virtualmillis : ");
    Serial.println(virtualmillis);         
  }

}


SouthernAtHeart


crimony


There was a 'famous' posting here in the past explaining how the subtraction overflow bit handles the roll over condition just fine as long as you use subtraction for your time interval test calculation.


If this is the post you're referring to, then I'll take that as high praise indeed.


retrolefty



There was a 'famous' posting here in the past explaining how the subtraction overflow bit handles the roll over condition just fine as long as you use subtraction for your time interval test calculation.


If this is the post you're referring to, then I'll take that as high praise indeed.



Yes, you and Coding Badly nailed the dirty details for that one. However due to passing time, Arduino reference docs that still talk about the 'roll over' interval, etc the subject still comes up from time to time. Probably an indication that the subject and proven solution should be made either a stick or included in the 'official' Arduino reference for the millis() function.

Lefty

Coding Badly

Probably an indication that the subject and proven solution should be made either a stick


Great idea!

Let's finish the first sticky.  Pick a set and post comments...
http://arduino.cc/forum/index.php/topic,67509.0.html

crimony

... Arduino reference docs that still talk about the 'roll over' interval, etc the subject still comes up from time to time. Probably an indication that the subject and proven solution should be made either a stick or included in the 'official' Arduino reference for the millis() function.


Totally OT, but I have the same uneasy feeling about the use of delay(). The number of posts where an OP is looking for a solution to "doing two things at once" is very high. I wonder whether the use of delay() should be discouraged. I would go so far as to suggest delay() should be considered an advanced technique on par with goto.

Perhaps the subject of a separate thread...

David Pankhurst

Two things you might want to consider as well:

* This only works if the delay interval is less than rollover - for example, if you use microseconds, and expect to time things >70 seconds, then you might miss a complete rollover from time to time.

* Are there cases where optimizing of the compiler affect the if statement? Not sure, but I'd put parenthesis around it just in case:

Code: [Select]
if ( (millis()-LCDtime) > 3000)



Nick Gammon

Optimizing won't affect operation order. Operator precedence can't be optimized into some other precedence.

http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

The precedence for addition/subtraction is higher than less-than/greater-than, so you are OK.

MarkT

The point is that the optimizer _knows_ that a - b > c is different from a > c + b for 2's complement arithmetic.
[ I won't respond to messages, use the forum please ]

Go Up