# What is maximum value of millis()

In Arduino version 18, what is the highest value of millis() before it rolls over?

I searched previous posts and found this one:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1159930168

but it refers to previous versions which I understand roll over sooner than ver 18

Why is it important to know when millis rolls over? There are ways of dealing with the possibility of rollover without knowing when that might occur.

Millis() uses unsigned longs which is a 32 bit number. Translates to around 4 billion millseconds (4294967296 if you’re feeling pedantic) or 49 days and 17 hours…

Very early versions used 16bit which only ran for just over a minute.

Heres one thats been running a while since it was last reset (about 29 days so far) : http://majestic81.plus.com/

Incidentally its within 10 seconds after 29 days, which says something for the accuracy of the crystals they put in real Duemilanoves.

Why is it important to know when millis rolls over? There are ways of dealing with the possibility of rollover without knowing when that might occur.

Say I want to time for an event without using delay(), as in David Mellis example sketch (BlinkWithoutDelay):

if(currentMillis - previousMillis > interval …

If the interval that I wanted to time was 20 ms (600,000 ms) and the loop (that takes 50 ms was entered just before the millis() rollover then it would be another 90 days before the condition was fulfilled.

I could test for currentMillis > previousMillis but without knowing the max value of millis() i would not be able to get an accurate two minutes interval for the rollover iteration of the loop.

If I know the max value of millis() then I can test if it is close to rollover and account for it.

e.g.

say
max millis = 10000 ms
interval to be timed = 1000 ms
millis at time of entering loop 9990 ms

if millis + interval to be timed > max millis (rollover occurs in loop)
target for ending loop = interval to be timed - (max millis - present millis)

if millis > target for ending loop and (millis - target < 100,000)
end loop

… thereby getting a quite accurate timing over the rollover period.

If the interval that I wanted to time was 20 ms (600,000 ms) and the loop (that takes 50 ms was entered just before the millis() rollover

The current-previous subtraction doesn't experience roll-over problems, if a roll-over occurs it will result in a negative number, which would be rolled over to the actual difference again. If you have to wait a pre-determined amount of time, store the time it needs to wait, and subtract the time that has passed with each iteration of loop, this should provide a more robust timer than saving absolute millis() values.

There was a pretty good explanation posted that explained why subtracting a large value from the value returned by millis() after rollover resulted in the expected (correct) value, even though millis had rolled over. Now adding a value to millis() when it is near rollover might cause a rollover, and the results would not be what was expected. But subtraction works.

As long as you are not trying to wait ~50 days...

This looks promising... http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1260223964/all