Ad-Hoc millis() Checks versus Scheduler Libraries for Coexisting Periodic Tasks in Arduino Loops

Short answer

For a handful of periodic tasks (sensor polling, debounce, serial output), ad-hoc millis() checks using the subtraction idiom are the conventional, well-established pattern. A scheduler library becomes worthwhile when task count grows past roughly five or six, when tasks need enable/disable or iteration limits, or when you want a single place to reason about timing. Neither is "correct" by default—the official Arduino reference documents the non-blocking pattern but deliberately leaves multi-task structure to the sketch author.

Why the subtraction idiom scales

The rollover-safe form

if (millis() - previousMillis >= interval) {
  previousMillis += interval; // or = millis() if drift is acceptable
  // do task
}

works for intervals from 1 ms to days because millis() returns an unsigned long (32-bit on AVR). Unsigned subtraction wraps modulo 2^32, so the comparison stays true across the ~49.7-day overflow. Two conditions make this reliable: previousMillis must be unsigned long (storing it in int or signed long causes sign-extension bugs at wrap), and you must never write the naive if (millis() > previousMillis + interval), which fails for one full cycle after overflow.

Grouping and prioritization

Polling overhead per check is tiny—one millis() call and one subtraction—so the real cost is calling millis() repeatedly. Cache it once per iteration:

void loop() {
  unsigned long now = millis();
  if (now - tDebounce >= 5)    { tDebounce = now; pollButtons(); }
  if (now - tSensor   >= 100)  { tSensor   = now; readSensor(); }
  if (now - tSerial   >= 1000) { tSerial   = now; report(); }
}

Practical conventions experienced sketches adopt:

• Order checks by urgency, fastest first. Button debounce and time-critical sampling go at the top so a slow task (e.g., a blocking serial print) delays them least.
• Group by GCD when intervals share a common divisor. If tasks run at 100 ms, 500 ms, and 1 s, a single 100 ms tick with counters derives the slower ones, reducing comparisons and making phase relationships explicit. This assumes fixed ratios—if intervals change at runtime, recompute or fall back to per-task checks.
• Keep every task body non-blocking. One delay() or a long Serial.print at low baud undermines the whole structure regardless of which pattern you chose.

When a scheduler library earns its overhead

Libraries such as TaskScheduler centralize task registration, callbacks, and enable/disable logic. The trade-offs: added flash/RAM footprint, a per-iteration dispatch cost, and slightly less deterministic timing than a hand-ordered sequence of checks. On an ATmega328P with three tasks, the library buys you little; with ten tasks that start, stop, and change period dynamically, it removes a class of bookkeeping bugs. A reasonable rule: start ad-hoc, refactor to a scheduler when the loop() preamble of if (now - tX ...) blocks becomes hard to audit.

Verification

Confirm the pattern on your board before committing:

1. Extend the BlinkWithoutDelay example with a second interval block and confirm both LEDs/outputs toggle independently.
2. To test rollover without waiting 49 days, temporarily seed previousMillis near 0xFFFFFFFF (or use a test harness that stubs millis()) and confirm the task fires once, on schedule, across the wrap.
3. Measure loop throughput by incrementing a counter in loop() and printing it once per second; compare ad-hoc versus scheduler versions to see the actual dispatch cost on your hardware.

Assumes AVR-based boards (Uno/Nano/Mega) with 32-bit millis(). On 32-bit ARM boards (Due, MKR, ESP32 core) the same idiom applies, but tick resolution and millis() implementation differ—verify on the target core.