The Core Concept: Why Ditch delay()?

When building responsive embedded systems, blocking code is the enemy. The standard delay() function halts the microcontroller's CPU, preventing it from reading sensors, updating displays, or handling serial communication. By mastering the millis() Arduino function, you transition from single-threaded blocking scripts to event-driven, non-blocking architectures. This quick reference and FAQ guide addresses the most common pitfalls, architectural quirks, and advanced implementation strategies for using millis() in 2026 and beyond.

Quick Reference Matrix: delay() vs. millis()

Feature delay(milliseconds) millis() Timer Pattern
CPU State Blocked (Idling) Active (Polling/Event-driven)
Concurrency Impossible without RTOS/Interrupts Natively supports multiple parallel tasks
Power Consumption High (CPU clock running) High (unless paired with sleep modes)
Timing Accuracy Exact, but blocks subsequent code Subject to loop() execution time jitter
Best Use Case Simple debouncing, quick hardware tests Production firmware, UIs, sensor polling

Top millis() Arduino FAQ

1. What exactly does millis() return, and when does it overflow?

The millis() function returns an unsigned long integer representing the number of milliseconds since the microcontroller began running the current program. Because an unsigned long on 8-bit AVR (and 32-bit ARM/RISC-V architectures) is a 32-bit value, its maximum capacity is 4,294,967,295.

At 1,000 ticks per second, this equates to exactly 49.7102696 days. After this period, the counter overflows and rolls over to zero. If your code uses improper comparison logic (like if (currentMillis == targetTime)), your sketch will fail catastrophically after 49.7 days. Always use subtraction-based interval checking to handle this wrap-around seamlessly.

2. Can I manually reset millis() to zero?

No, and you should not try. millis() is a function that reads a hidden background variable incremented by a hardware timer interrupt (Timer0 on the ATmega328P). Attempting to force a reset by hacking internal registers will break core Arduino functions that rely on that same timer, including delay(), micros(), and PWM generation via analogWrite(). Instead of resetting the clock, use an offset variable to track your specific event's start time.

3. Why does my timer trigger late or skip intervals?

The millis() function is only evaluated when the loop() reaches your if statement. If your loop contains heavy computations, slow I2C/SPI transactions, or blocking serial prints, the polling rate drops. If the loop takes 50ms to execute, a 10ms timer will miss its window and trigger late. For sub-millisecond precision or strict real-time requirements, you must use hardware interrupts or an RTOS (like FreeRTOS on ESP32).

The Bulletproof Non-Blocking Timer Pattern

According to the Arduino Official Language Reference, the subtraction method is the only mathematically sound way to handle the 49.7-day rollover. When currentMillis rolls over to 0 and previousMillis is near the maximum 32-bit limit, the unsigned math naturally wraps around to yield the correct positive difference.

// Define intervals and state variables globally
const unsigned long INTERVAL_MS = 1000;
unsigned long previousMillis = 0;
bool ledState = false;

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  // 1. Capture the current time
  unsigned long currentMillis = millis();

  // 2. Check if the interval has passed using unsigned subtraction
  if (currentMillis - previousMillis >= INTERVAL_MS) {
    // 3. Save the last time the action occurred
    previousMillis = currentMillis; 
    
    // 4. Execute the non-blocking task
    ledState = !ledState;
    digitalWrite(LED_BUILTIN, ledState);
  }

  // The CPU is now free to execute other code here instantly
  readSensors();
  updateDisplay();
}

Advanced Architecture: Managing Multiple Timers

As your sketch grows, declaring dozens of previousMillis variables becomes unmanageable. As highlighted in Adafruit's Guide to Multi-tasking the Arduino, encapsulating timers inside C++ structs or classes is the industry standard for scalable firmware.

struct Timer {
  unsigned long previousMillis;
  unsigned long interval;
  
  bool check() {
    unsigned long currentMillis = millis();
    if (currentMillis - previousMillis >= interval) {
      previousMillis = currentMillis;
      return true;
    }
    return false;
  }
};

Timer sensorTimer = {0, 500};   // Fires every 500ms
Timer telemetryTimer = {0, 5000}; // Fires every 5000ms

void loop() {
  if (sensorTimer.check()) {
    readTemperature();
  }
  if (telemetryTimer.check()) {
    sendToCloud();
  }
}

Edge Cases: Deep Sleep & RTC Fallbacks (ESP32 / RP2040)

A common point of confusion in modern maker projects involves low-power modes. When an ESP32 or Raspberry Pi Pico (RP2040) enters Deep Sleep, the CPU powers down completely. Upon waking, the system resets, and millis() starts back at 0.

Expert Tip: If your application requires tracking absolute time across sleep cycles (e.g., a solar-powered weather station waking every 15 minutes), millis() is useless. You must store the timestamp in RTC Slow Memory (RTC_DATA_ATTR on ESP32) or query an external I2C Real-Time Clock module like the DS3231.

Troubleshooting Common millis() Bugs

Symptom Root Cause Solution
Timer fires immediately and continuously Using int instead of unsigned long for time variables. Change all time-tracking variables to unsigned long.
Timer stops working after ~49 days Using addition logic: if (current >= previous + interval) Switch to subtraction logic: if (current - previous >= interval)
Interval drifts over time Using previousMillis = currentMillis inside a heavy loop. Use previousMillis += interval to maintain exact phase alignment.
Code misses short intervals entirely Loop execution time exceeds the timer interval. Optimize loop speed, use hardware interrupts, or migrate to an RTOS.

Summary

Transitioning from delay() to millis() is the defining milestone between a beginner and an intermediate embedded developer. By utilizing unsigned subtraction, encapsulating timers in structs, and understanding the hardware limitations of your specific microcontroller architecture, you can build robust, production-ready firmware that runs indefinitely without timing drift or overflow failures.