English is currently available.
Arduino DISCUSSION
A device intended to run for months needs its periodic tasks to survive the millis counter wrapping. Why can comparing the current time with a future timestamp fail near that boundary?
What form of elapsed-time test is appropriate, and how can it be tested without waiting roughly 50 days?
Store timestamps and intervals in the unsigned type appropriate to the counter. For the usual unsigned-long millis API, compare elapsed time using (unsigned long)(now - previous) >= interval. Unsigned subtraction handles the wrap modulo the counter range. This assumes elapsed intervals are shorter than a full wrap and the task is checked often enough.
Make the timing logic accept a supplied timestamp during a test. Feed it values just before and just after the unsigned maximum, then check that the task becomes due exactly when intended. Include a delayed iteration as well. There is no need to modify the core's real timer to test the arithmetic.
Choose whether the next schedule uses the current time or advances the previous deadline by the period. The former avoids catch-up bursts but can drift; the latter can preserve cadence but needs an explicit missed-period policy. Keep long-duration calendar time separate from this short-interval scheduler, and avoid reconfiguring the core's timing source accidentally.
