next topic »

[on:]

I often use millis() to do certain things every few seconds.  Like the following example:
(LCDtime is unsigned long)

Code:

    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...

[Reply #1 on:]

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

[Reply #2 on:]

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:

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);         
  }

}

[Reply #3 on:]

Good to know!

[Reply #4 on:]

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.

[Reply #5 on:]

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

[Reply #6 on:]

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

[Reply #7 on:]

... 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...

[Reply #8 on:]

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:

if ( (millis()-LCDtime) > 3000)

[Reply #9 on:]

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.

[Reply #10 on:]

The point is that the optimizer _knows_ that a - b > c is different from a > c + b for 2's complement arithmetic.