How to Use millis() in Arduino for Non-Blocking Timers

The Hidden Cost of delay(): Why Your Arduino Freezes

When beginners start programming an ATmega328P or ESP32, the delay() function is the first timing tool they learn. While useful for simple proofs-of-concept, delay() is a blocking function. When you call delay(1000), the microcontroller halts all operations—ignoring button presses, dropping serial data, and freezing sensor reads—for exactly one second.

In professional firmware development and complex maker projects, this blocking behavior is unacceptable. To achieve true multitasking, you must master millis() in Arduino. This tutorial provides a deep, technical walkthrough of implementing non-blocking timers, handling the infamous 49-day rollover, and scaling your code to manage dozens of independent tasks simultaneously.

Understanding millis() and the 49.7-Day Rollover

The millis() function returns the number of milliseconds that have elapsed since the microcontroller began running its current sketch. Under the hood, this value is stored in an unsigned long variable (a 32-bit unsigned integer).

An unsigned long can hold a maximum value of 4,294,967,295. Once the counter reaches this limit, it experiences an overflow and rolls over to 0. At 1,000 milliseconds per second, this rollover occurs exactly every 49.71 days. If your IoT weather station or greenhouse controller is designed to run for months, naive timing logic will catastrophically fail on day 50.

The Golden Rule of Rollover-Safe Math:
Never use addition to check for future time (e.g., if (currentMillis > previousMillis + interval)). Always use subtraction to measure elapsed time (e.g., if (currentMillis - previousMillis >= interval)). Subtraction natively handles the 32-bit integer underflow, making your code 100% rollover-proof.

Step-by-Step: Building Your First Non-Blocking Timer

Let's replace a blocking delay() with a robust millis() implementation. We will build a non-blocking LED blinker that allows the MCU to perform other tasks concurrently.

1. Define Your State Variables

You must explicitly declare your timing variables as unsigned long. Using standard int variables will cause an overflow every 32.7 seconds, leading to erratic behavior.

2. The Implementation Code


// Explicitly use unsigned long to prevent 32-second int overflow
unsigned long previousMillis = 0;
const long interval = 1000; // 1000ms = 1 second
int ledState = LOW;

void setup() {
  pinMode(13, OUTPUT);
  Serial.begin(115200);
}

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

  // 2. Check if the interval has passed using rollover-safe subtraction
  if (currentMillis - previousMillis >= interval) {
    // 3. Save the last time you blinked the LED
    previousMillis = currentMillis;

    // 4. Toggle the LED state
    ledState = (ledState == LOW) ? HIGH : LOW;
    digitalWrite(13, ledState);
    
    // The MCU is free to do other work here!
    Serial.println('LED Toggled. Free to read sensors.');
  }

  // Non-blocking code executes continuously while waiting
  readCapacitiveSoilSensor();
  checkEmergencyStopButton();
}

Scaling Up: Managing Multiple Independent Timers

Managing one timer requires three global variables. Managing ten timers requires thirty, cluttering your namespace and making maintenance a nightmare. In 2026, modern Arduino C++ best practices dictate using structs or object-oriented classes to encapsulate timer state.

Below is a professional approach using a struct to manage multiple asynchronous tasks without blocking the main loop.


struct TaskTimer {
  unsigned long previousTime;
  unsigned long interval;
  bool (*callback)(); // Function pointer for the task
};

bool blinkLED() {
  digitalWrite(13, !digitalRead(13));
  return true;
}

bool readI2CSensor() {
  // Wire.requestFrom() logic here
  Serial.println('Sensor Read Complete');
  return true;
}

TaskTimer tasks[] = {
  {0, 500, blinkLED},       // Runs every 500ms
  {0, 2000, readI2CSensor}  // Runs every 2000ms
};
const int taskCount = sizeof(tasks) / sizeof(tasks[0]);

void loop() {
  unsigned long now = millis();
  for (int i = 0; i < taskCount; i++) {
    if (now - tasks[i].previousTime >= tasks[i].interval) {
      tasks[i].previousTime = now;
      tasks[i].callback();
    }
  }
}

This array-based scheduler pattern is lightweight, requires no external libraries like SimpleTimer, and compiles efficiently on resource-constrained 8-bit AVR chips.

Comparison Matrix: delay() vs millis() vs micros()

Function	Resolution	Blocking?	Rollover Time	Best Use Case
`delay()`	1 ms	Yes (Halts CPU)	N/A	Simple setup routines, hardware debounce
`millis()`	1 ms	No (Non-blocking)	~49.7 Days	UI updates, sensor polling, state machines
`micros()`	4 µs (16MHz AVR)	No (Non-blocking)	~70 Minutes	Motor PID loops, ultrasonic distance, fast PWM

Note on micros() resolution: On a standard 16MHz ATmega328P, micros() updates in steps of 4µs. On a 240MHz ESP32, the resolution is a true 1µs.

Critical Troubleshooting: 3 Fatal millis() Mistakes

1. The 'int' Variable Trap

A standard int on an AVR Arduino is 16 bits (max 32,767). If you store millis() in an int, your timer will overflow and break every 32.7 seconds. Fix: Always declare time-tracking variables as unsigned long.

2. Blocking Code Inside the IF Statement

Using millis() correctly to trigger an event, but then placing a delay(500) or a blocking while() loop inside that if block. This defeats the purpose of non-blocking architecture and introduces system-wide latency. Fix: Use nested state machines or secondary millis() timers for multi-stage tasks.

3. Resetting previousMillis to 0

When the interval passes, beginners often write previousMillis = 0;. This causes timing drift. If your loop takes 5ms to execute, resetting to 0 loses those 5ms. Fix: Always assign previousMillis = currentMillis; to maintain perfect phase alignment.