Your code doesn't correctly handle the millis() overflow because the overflow doesn't occur on an even data boundary. You should check to see when current_millis_value is less than previous_millis_value, at which point you should be able to increment m by 1 (since your loop should be fast enough to catch the overflow before more than a millisecond has elapsed). Or, if you want to be completely accurate, you can increment m by:
MAX_MILLIS_VALUE - previous_millis_value + current_millis_value
Ok! I've completely understand your explanation! In fact, ~9h does not correnspond to 2^32-1 milliseconds...
And what is the MAX_MILLIS_VALUE? How can I get it? I search the forum: someone says that:
"it would appear that the millis() overflow occurs at 34,359,739ms or 9h, 32m, 39s, and 739ms"
There is a way to calculate it? This seems a result of a test, not of a precise calculation...
Also, you should disable interrupts while calling millis(), otherwise you run the risk of getting corrupted data should the timer0 overflow occur while millis() is performing its computation:
cli(); // disable interrupts
current_millis_value = millis();
sei(); // enable interrupts
I will.
And yes, if the uncertainty of your crystal is 0.05%, you can expect a worst case error of around 2 seconds per hour, but this error will be a constant that you can calibrate away.
Ok, perfect.
Thank you Ben!