Mastering the millis Arduino Function: Non-Blocking Timing and Rollover Fixes

The Short Answer: When and Why to Use the millis Arduino Function

Use the millis() function when you need to track time, schedule events, or multitask without halting your microcontroller's main execution loop. Unlike delay(), which puts the CPU to sleep and blinds it to button presses or sensor changes, millis() returns an unsigned long integer representing the number of milliseconds since the board booted. You store this value, let the loop continue running, and check on the next pass if enough time has elapsed.

If your project requires blinking an LED while simultaneously polling a sensor, reading a serial command, or watching a button press, millis() is mandatory. The official Arduino millis() reference defines it as a 32-bit unsigned integer, meaning it maxes out at 4,294,967,295 milliseconds—exactly 49.71 days—before rolling over to zero. Handling this rollover correctly is the difference between a reliable deployment and a bricked system on day 50.

Project Build: Non-Blocking Multi-Task Monitor

To demonstrate proper implementation, we will build a dual-task monitor. Task 1 blinks an LED every 500ms. Task 2 reads a DHT22 temperature/humidity sensor every 2 seconds. Both run concurrently without blocking each other.

Parts List

• Microcontroller: Arduino Uno R3 (ATmega328P variant) — chosen specifically because its 32-bit millis() counter is subject to the 49.7-day hardware rollover, making it the best board for learning overflow math.
• Sensor: DHT22 (AM2302) temperature and humidity sensor (do not use the DHT11; its 1-second hardware lockout ruins fast polling tests).
• Indicator: Standard 5mm Blue LED.
• Resistors: 1x 220Ω (for LED current limiting), 1x 10kΩ (for DHT22 data line pull-up).
• Hardware: Half-size solderless breadboard, 22 AWG solid core jumper wires.

Pin Mapping Table

The Complete Non-Blocking Code

This code targets the Arduino Uno R3 (ATmega328P). It uses the Adafruit DHT library. Notice the strict use of unsigned long for time variables and the specific subtraction logic used to survive the 49.7-day rollover.

#include <DHT.h>

// --- Pin Definitions ---
#define DHTPIN 2
#define DHTTYPE DHT22
const uint8_t LED_PIN = 8;

// --- Intervals (in milliseconds) ---
const unsigned long LED_INTERVAL = 500;
const unsigned long SENSOR_INTERVAL = 2000;

// --- State Variables ---
unsigned long previousLedMillis = 0;
unsigned long previousSensorMillis = 0;
bool ledState = LOW;

// Initialize DHT sensor
DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(115200);
  pinMode(LED_PIN, OUTPUT);
  dht.begin();
  Serial.println("System Booted. Non-blocking tasks active.");
}

void loop() {
  // Capture the current time ONCE per loop iteration
  unsigned long currentMillis = millis();

  // --- Task 1: Blink LED ---
  // CRITICAL: Use subtraction to handle the 49.7-day rollover safely
  if (currentMillis - previousLedMillis >= LED_INTERVAL) {
    previousLedMillis = currentMillis;
    ledState = !ledState;
    digitalWrite(LED_PIN, ledState);
  }

  // --- Task 2: Read Sensor ---
  if (currentMillis - previousSensorMillis >= SENSOR_INTERVAL) {
    previousSensorMillis = currentMillis;
    
    float humidity = dht.readHumidity();
    float tempC = dht.readTemperature();

    // Error handling for sensor read failures
    if (isnan(humidity) || isnan(tempC)) {
      Serial.println("Error: Failed to read from DHT sensor!");
    } else {
      Serial.print("Temp: ");
      Serial.print(tempC);
      Serial.print(" C | Humidity: ");
      Serial.print(humidity);
      Serial.println(" %");
    }
  }

  // The loop continues instantly, allowing for button reads or serial parsing here
}

Debugging: The 49.7-Day Rollover and Common Failures

When working with time-based logic, beginners frequently encounter compiler warnings or runtime timeouts. Here is how to diagnose them.

Exact Error Strings and Ranked Causes

Error 1: Compiler Warning
warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

• Cause A (Most Likely): You declared your time variables as int or long instead of unsigned long. An int on the Uno R3 maxes out at 32,767ms (32 seconds) before overflowing into negative numbers, breaking your math instantly.
• Cause B: You defined your interval as a standard integer literal without casting, though the compiler usually handles this if the variable is correct.

Error 2: Runtime Serial Output
Error: Failed to read from DHT sensor!

• Cause A (Most Likely): Hidden blocking code. If you added a delay(100) somewhere else in your loop, or if you are printing massive strings to Serial at 9600 baud, the CPU gets bogged down. The DHT22 relies on precise microsecond bit-banging; if the CPU is blocked, the sensor read times out.
• Cause B: Missing or incorrect 10kΩ pull-up resistor on the DHT22 data line, causing floating logic levels.

The First Three Things to Check When Timing Fails

1. Verify Data Types: Ensure every variable holding a millis() value or an interval is declared as unsigned long (or uint32_t).
2. Check the Subtraction Logic: Never use if (currentMillis > previousMillis + interval). When currentMillis rolls over to 0, but previousMillis is still near 4.29 billion, the addition overflows and the condition fails permanently. Always use if (currentMillis - previousMillis >= interval). Two's complement arithmetic guarantees this subtraction yields the correct positive difference even across the rollover boundary.
3. Hunt for Hidden Delays: Search your entire sketch (and included libraries) for delay(). Replace them with state machines or additional millis() checks.

Decision Tree: delay() vs. millis() vs. Hardware Timers

Not every project needs non-blocking code. Use this decision matrix to pick the right timing mechanism for your specific architecture.

Extending and Simplifying the Build

How to Extend

If your project grows beyond three or four timed tasks, managing individual previousMillis variables becomes messy. Extend this build by implementing an array of structs or using a library like TaskScheduler. A struct-based approach looks like this:

struct Task {
  unsigned long interval;
  unsigned long previousTime;
  void (*execute)();
};

You can then iterate through an array of Task objects in your main loop, keeping your code modular and scalable to dozens of concurrent operations.

How to Simplify

If you realize your project only ever does one thing at a time—for example, a simple traffic light sequence that doesn't need to read buttons or Wi-Fi during the color changes—strip out the millis() logic entirely. Revert to delay(). Over-engineering a simple sequential script with non-blocking state machines adds unnecessary complexity and makes the code harder for others to read. Match the timing architecture to the actual concurrency requirements of your hardware.