Mastering the Arduino Wait: How to Use millis() Over delay()

The Hidden Cost of the Standard Arduino Wait

When you first unbox an Arduino Uno R4 WiFi (currently retailing around $27.50) or a classic Nano, the official "Blink" sketch introduces you to the delay() function. For a single LED, this standard Arduino wait method works perfectly. However, as soon as your project evolves to include I2C OLED displays, DHT22 temperature sensors, or WiFi communication, delay() becomes a critical bottleneck.

Under the hood, the AVR delay() function is a "busy-wait" loop. The microcontroller's CPU is literally trapped in a while() loop, counting clock cycles. During this Arduino wait period, the MCU cannot read sensors, update displays, or respond to button presses. It is entirely paralyzed.

The Non-Blocking Arduino Wait: Mastering millis()

To achieve a non-blocking Arduino wait, you must decouple time-tracking from code execution. The official Arduino millis() function returns the number of milliseconds passed since the board powered on. By recording a "timestamp" and continuously checking the difference, we create a software timer that allows the rest of the loop() to run freely.

Step 1: Define Your Timing Variables

Always use the unsigned long data type for time variables. A standard 32-bit signed integer will overflow and cause catastrophic logic failures in just 24.8 days.

unsigned long previousMillis = 0;
const long interval = 1000; // 1 second wait

Step 2: Implement the State-Change Logic

Inside your loop(), capture the current time and compare it. Here is the mathematically safe way to handle the Arduino wait:

void loop() {
  unsigned long currentMillis = millis();

  // The correct, overflow-safe Arduino wait logic
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    // Execute your non-blocking task here
    toggleLED();
  }
  
  // The CPU is free to do other work here immediately
  readSensors();
  updateDisplay();
}

The 49.7-Day Overflow Bug: A Critical Edge Case

The most common failure mode in advanced maker projects is the millis() rollover. An unsigned long holds a maximum value of 4,294,967,295. At exactly 49.71 days of continuous uptime, the counter hits this ceiling and rolls over to 0.

WARNING: Never use addition to check your Arduino wait intervals. Writing if (currentMillis >= previousMillis + interval) will fail catastrophically during a rollover event, causing your system to hang or behave erratically for up to 49 days. Always use subtraction: currentMillis - previousMillis >= interval. The properties of unsigned binary arithmetic guarantee this subtraction yields the correct positive delta, even across the rollover boundary.

Comparison Matrix: Arduino Wait Methods

Depending on your hardware—whether you are using an 8-bit ATmega328P or a 32-bit ESP32-S3—your options for pausing execution vary. Below is a technical comparison of the most common timing methods in 2026.

Method	Blocking?	Resolution	Overflow Safe?	Best Use Case
`delay()`	Yes	1 ms	N/A	Simple setup routines, debouncing
`millis()`	No	1 ms	Yes (with subtraction)	General non-blocking loops, UI updates
`micros()`	No	4 µs (16MHz)	Yes (rolls over at 70 mins)	High-speed sensor polling, PID loops
Hardware Timer (TimerOne)	No (Interrupt)	1 µs	Yes	Precise PWM, encoder reading
FreeRTOS `vTaskDelay`	Task-level	1 ms (Tick rate)	Yes	ESP32 multi-core task management

Upgrading to ESP32: The FreeRTOS Arduino Wait

If you have migrated to modern, low-cost MCUs like the ESP32-C3 SuperMini (widely available for around $3.50 in 2026), you are no longer just running a bare-metal loop. The ESP32 Arduino core runs on top of FreeRTOS, a real-time operating system.

In an RTOS environment, using delay() or even a millis() polling loop is considered bad practice because it starves the background WiFi and Bluetooth stacks of CPU cycles. Instead, you should use the FreeRTOS vTaskDelay function.

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

void sensorTask(void *pvParameters) {
  for (;;) {
    readBME280();
    // Non-blocking Arduino wait that yields CPU to WiFi stack
    vTaskDelay(pdMS_TO_TICKS(2000)); 
  }
}

According to the Espressif ESP-IDF API Guide, vTaskDelay places the specific task into a "Blocked" state, allowing the RTOS scheduler to allocate those CPU cycles to lower-priority tasks, such as maintaining an active MQTT connection.

Hardware Reality: Why Your Timers Might Drift

Software timing is only as accurate as the hardware clock driving it. When implementing a precise Arduino wait, you must consider the physical oscillator on your board:

Quartz Crystals (e.g., Arduino Uno R4 Minima, $22.00): Highly accurate, typically within ±20 PPM (parts per million). You will lose or gain less than 2 seconds per day.
Ceramic Resonators (e.g., Cheap ATmega328P Nano Clones, $4.00): Prone to temperature drift and manufacturing tolerances up to 0.5%. A 24-hour Arduino wait using millis() on a ceramic resonator can drift by over 430 seconds (7 minutes).

For applications requiring strict chronological accuracy over weeks or months (like automated greenhouse watering systems), relying solely on the internal millis() wait is insufficient. You must integrate a DS3231 Real Time Clock (RTC) module via I2C to periodically correct your software timers.

High-Speed Arduino Wait: When Milliseconds Aren't Enough

When interfacing with components like the HC-SR04 ultrasonic distance sensor or implementing a high-frequency PID control loop for a brushless DC motor, a 1-millisecond resolution is far too slow. In these scenarios, the micros() function becomes your primary tool for a microsecond-level Arduino wait.

However, micros() comes with a severe limitation: it overflows every 71.5 minutes. The maximum value is 4,294,967,295 microseconds. The subtraction rule (currentMicros - previousMicros >= interval) still perfectly protects you from the 71-minute rollover, provided your interval is strictly less than 71.5 minutes. If you attempt to create a 2-hour non-blocking wait using micros(), the logic will break. For intervals exceeding 70 minutes, you must cascade a millis() counter or use a hardware timer interrupt.

Frequently Asked Questions

Can I use a while loop for an Arduino wait?

Using while(millis() - start < 1000) {} creates a blocking wait, identical in CPU impact to delay(). The only advantage of a while loop is if you include a break condition inside it, such as waiting for a serial buffer to fill or a GPIO pin to change state, effectively creating a "wait-with-timeout" safety mechanism.

Does sleep mode affect the Arduino wait?

Yes. If you put an ATmega328P into SLEEP_MODE_PWR_DOWN, the system clock is halted. millis() will completely stop incrementing. To maintain an Arduino wait during deep sleep, you must use the Watchdog Timer (WDT) or an external RTC interrupt to wake the MCU, as the software counters are frozen.

How does the Raspberry Pi Pico (RP2040) handle waits?

The RP2040 (used in the $4.00 Raspberry Pi Pico) runs at 133MHz. While the standard Arduino core maps millis() to one of the SysTick timers, the native Pico SDK offers add_alarm_in_ms(). This hardware-alarm approach is vastly superior to polling millis() in a loop, as it triggers a callback function exactly when the wait concludes, freeing the dual-core CPU entirely.

Summary of Best Practices

Never use delay() inside the main loop() once your project includes more than one concurrent process.
Always declare timing variables as unsigned long.
Always use subtraction (current - previous >= interval) to mathematically guarantee rollover safety.
On ESP32 and RP2040 boards, leverage RTOS task delays or hardware alarm pools instead of polling millis().