The simplest way then is to cast the result of now-runTime to a signed long, for which the very high values will end up on the negative end of the scale. What we see from this comparison is that the two scenarios which should execute (first and last), are very close to the positive side of the variable space, and the two scenarios which should NOT execute (second and third), are just "below" the maximum. Now = 10 runTime = 2^32-12 // now-runTime = 22 - direct comparison >= 0 WILL work here Now = 2^32-10 runTime = 1 // now-runTime = 2^32-11 - direct comparison >= 0 will NOT work here Now = 2^32-10 runTime = 2^32-2 // now-runTime = 2^32-8 - direct comparison >= 0 will NOT work here now = 2^32-10 runTime = 2^32-12 // now-runTime = 2 - direct comparison >= 0 WILL work here
However we can adapt it to suit our needs. The general approach, "subtract old time from new time and compare with interval", does not translate directly to this situation.
Now = 2^32-10 runTime = 1 // now >= runTime = true - INCORRECT - this should NOT trigger the task to run, and may trigger the task to run very very many times more than intended The overflow issue is never really addressed here.Ĭonsider a task scheduled to run, near the end of the "unsigned long" reach. The gist of the task manager is a "now" variable being continuously updated with millis() and passed on to a "Tasks" function call that checks if the task is scheduled to run.
0 kommentar(er)
