ESP32 FreeRTOS: Multitasking for Real-Time IoT Projects

One of the most underutilized yet powerful features of the ESP32 is its built-in support for ESP32 FreeRTOS multitasking for real-time IoT projects. Unlike Arduino boards where you write a single loop() function that handles everything sequentially, the ESP32 runs FreeRTOS — a real-time operating system — that allows you to run multiple tasks simultaneously across its two Xtensa LX6 cores. This fundamentally changes how you can architect IoT applications, enabling you to handle WiFi communication, sensor reading, display updates, and user input all at the same time, reliably and without blocking.

What is FreeRTOS and Why ESP32 Uses It

FreeRTOS (Free Real-Time Operating System) is a lightweight, open-source RTOS designed for microcontrollers and small embedded processors. Espressif’s ESP-IDF framework (the official SDK for ESP32) is built on top of FreeRTOS, and this carries over to the Arduino core for ESP32 as well. When you write an Arduino sketch for ESP32 and call setup() and loop(), both of these are actually running inside a FreeRTOS task.

A real-time operating system differs from a general-purpose OS (like Linux) in that it guarantees task execution within defined time constraints. This is critical for IoT applications where missing a sensor reading deadline, a network timeout, or a control signal can cause system failure.

Key FreeRTOS concepts you need to understand:

• Tasks: Independent functions that run concurrently, each with their own stack
• Scheduler: The FreeRTOS component that decides which task runs and when
• Priority: Each task has a priority level; higher priority tasks preempt lower ones
• Tick: The basic time unit of FreeRTOS (1ms by default on ESP32)
• Blocking: Tasks can voluntarily yield CPU time by blocking on delays or waiting for events

The ESP32’s dual-core architecture means FreeRTOS can truly run two tasks simultaneously (one per core), not just time-slice between them. This is a significant advantage for IoT applications that need to handle both WiFi stack operations and application logic in parallel.

Creating and Managing FreeRTOS Tasks

Creating a FreeRTOS task on ESP32 is straightforward using the xTaskCreate() or xTaskCreatePinnedToCore() functions. Here is the basic syntax and a working example:

// Task function signature: must return void, takes void* parameter
void sensorTask(void *pvParameters) {
  // Initialization code here
  while (1) { // Tasks must loop forever (or delete themselves)
    // Read sensor
    float temperature = readDHT();
    Serial.printf("Temperature: %.1f°Cn", temperature);
    vTaskDelay(pdMS_TO_TICKS(2000)); // Delay 2 seconds (non-blocking)
  }
  // If task needs to end:
  // vTaskDelete(NULL); // Delete itself
}

void wifiTask(void *pvParameters) {
  while (1) {
    if (WiFi.status() != WL_CONNECTED) {
      reconnectWiFi();
    }
    vTaskDelay(pdMS_TO_TICKS(5000)); // Check every 5 seconds
  }
}

void setup() {
  Serial.begin(115200);
  
  // Create tasks
  xTaskCreate(
    sensorTask,      // Task function
    "SensorTask",    // Name (for debugging)
    2048,            // Stack size in bytes
    NULL,            // Parameter passed to task
    1,               // Priority (0=lowest, configMAX_PRIORITIES-1=highest)
    NULL             // Task handle (optional)
  );
  
  xTaskCreate(
    wifiTask,
    "WiFiTask",
    4096,  // WiFi needs more stack
    NULL,
    2,     // Higher priority than sensor task
    NULL
  );
}

void loop() {
  // Can be left empty if all logic is in tasks
  vTaskDelay(portMAX_DELAY); // Block forever
}

The vTaskDelay(pdMS_TO_TICKS(ms)) function is crucial — it puts the task in a blocked state for the specified time, allowing other tasks and the WiFi stack to run. Never use delay() in FreeRTOS tasks as it is a busy-wait that blocks the CPU.

Understanding Stack Size

Stack size is one of the trickiest parts of FreeRTOS on ESP32. Each task needs enough stack for its local variables, function call chain, and any libraries it uses. As a rule of thumb:

• Simple tasks with no libraries: 1024-2048 bytes
• Tasks using Serial, string operations: 2048-4096 bytes
• Tasks using WiFi, HTTP, JSON: 4096-8192 bytes
• Tasks using TLS/HTTPS: 8192-16384 bytes

Use uxTaskGetStackHighWaterMark(NULL) to check how much stack your task actually uses at runtime and tune accordingly.

Ai Thinker NodeMCU-32S ESP32 Development Board – IPEX Version

The dual-core ESP32 development board ideal for FreeRTOS multitasking projects. With 520KB SRAM and 4MB flash, it can comfortably run multiple concurrent tasks for complex IoT applications.

View on Zbotic

Leveraging ESP32’s Dual Core Architecture

The ESP32 has two Xtensa LX6 cores: Core 0 (used by the WiFi/Bluetooth stack via the ESP-IDF “pro” CPU) and Core 1 (used by the Arduino loop() task by default). You can pin tasks to specific cores using xTaskCreatePinnedToCore():

// Pin WiFi-related tasks to Core 0 (alongside the WiFi stack)
xTaskCreatePinnedToCore(
  wifiTask,
  "WiFiTask",
  8192,
  NULL,
  2,
  NULL,
  0    // Core 0
);

// Pin sensor/display tasks to Core 1
xTaskCreatePinnedToCore(
  sensorTask,
  "SensorTask",
  2048,
  NULL,
  1,
  NULL,
  1    // Core 1
);

xTaskCreatePinnedToCore(
  displayTask,
  "DisplayTask",
  4096,
  NULL,
  1,
  NULL,
  1    // Core 1
);

This architecture achieves true parallelism: Core 0 handles WiFi communication while Core 1 handles sensor reading and display updates simultaneously. For a home automation controller or industrial monitor, this means your display never freezes due to a slow network request, and your sensor readings are never delayed by WiFi retries.

Important Note: The WiFi and Bluetooth drivers in ESP-IDF are not fully thread-safe if called from Core 1. Always make WiFi API calls from Core 0 or use proper synchronization. In practice, the Arduino WiFi library handles this internally, but be cautious with direct esp_wifi_* calls.

Inter-Task Communication: Queues and Semaphores

In a multitasked system, tasks need to share data and coordinate with each other safely. FreeRTOS provides several mechanisms for this. The two most important are Queues and Semaphores/Mutexes.

Queues

Queues are the primary method for passing data between tasks. A queue can hold a fixed number of items of a fixed size. The producer task sends items to the queue, and the consumer task receives them — safely and without race conditions.

QueueHandle_t sensorQueue;

void sensorTask(void *pvParameters) {
  float reading;
  while (1) {
    reading = readSensor();
    // Send to queue, wait up to 100ms if full
    xQueueSend(sensorQueue, &reading, pdMS_TO_TICKS(100));
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void displayTask(void *pvParameters) {
  float received;
  while (1) {
    // Wait for data, block until available
    if (xQueueReceive(sensorQueue, &received, portMAX_DELAY) == pdTRUE) {
      updateDisplay(received);
    }
  }
}

void setup() {
  sensorQueue = xQueueCreate(10, sizeof(float)); // Queue of 10 floats
  // Create tasks...
}

Mutexes for Shared Resources

When two tasks need to access the same resource (like an I2C bus, Serial port, or a shared data structure), use a mutex to prevent simultaneous access:

SemaphoreHandle_t i2cMutex;

void setup() {
  i2cMutex = xSemaphoreCreateMutex();
}

void taskA(void *pvParameters) {
  while (1) {
    if (xSemaphoreTake(i2cMutex, pdMS_TO_TICKS(100)) == pdTRUE) {
      // Safe to use I2C bus here
      readI2CSensor();
      xSemaphoreGive(i2cMutex); // Release the mutex
    }
    vTaskDelay(pdMS_TO_TICKS(500));
  }
}

BMP280 Barometric Pressure and Altitude Sensor I2C/SPI Module

An excellent I2C sensor for FreeRTOS multitasking projects. Use mutex-protected I2C access to read pressure and altitude data from one task while another task handles WiFi publishing.

View on Zbotic

Software Timers for Periodic Actions

FreeRTOS software timers allow you to execute a callback function after a specified delay or at regular intervals, without creating a dedicated task. This is memory-efficient for simple periodic actions:

#include "freertos/timers.h"

TimerHandle_t heartbeatTimer;

void heartbeatCallback(TimerHandle_t xTimer) {
  // Called every 30 seconds
  publishMQTTHeartbeat();
}

void setup() {
  // Create a repeating timer
  heartbeatTimer = xTimerCreate(
    "Heartbeat",
    pdMS_TO_TICKS(30000), // 30 second interval
    pdTRUE,              // Auto-reload (repeat)
    0,
    heartbeatCallback
  );
  xTimerStart(heartbeatTimer, 0);
}

Timer callbacks run in the context of the FreeRTOS timer daemon task. Keep them short — do not block inside a timer callback.

Practical Project: Multi-Sensor IoT Monitor

Let us put everything together in a practical project: a multi-sensor IoT monitor that reads temperature/humidity, checks WiFi status, publishes to MQTT, and blinks an LED — all simultaneously.

Task breakdown:

• SensorTask (Core 1, Priority 2): Reads DHT20 every 2 seconds, pushes to queue
• MQTTTask (Core 0, Priority 3): Receives from queue, publishes to MQTT broker
• WiFiWatchdog (Core 0, Priority 4): Monitors WiFi, reconnects if dropped
• StatusLED (Core 1, Priority 1): Blinks LED to indicate system health

This architecture means even if the MQTT broker is slow to respond, the sensor keeps reading at exactly 2-second intervals. And if WiFi drops, the WiFiWatchdog reconnects while the sensor task continues filling the queue (which will publish the buffered readings once WiFi is back).

DHT11 Temperature and Humidity Sensor Module with LED

A great starter sensor for your FreeRTOS multitasking project. The built-in LED provides visual feedback while the DHT11 provides digital temperature and humidity readings via a single-wire protocol.

View on Zbotic

Common Pitfalls and Debugging Tips

FreeRTOS on ESP32 is powerful but has some common pitfalls:

• Stack overflow: The most common issue. Enable stack overflow checking with configCHECK_FOR_STACK_OVERFLOW. Symptoms: random reboots, watchdog triggers.
• Watchdog timeout: The ESP32 has hardware and software watchdogs. If a task monopolizes a core without yielding, the watchdog fires and reboots. Always use vTaskDelay().
• Priority inversion: If a low-priority task holds a mutex needed by a high-priority task, the high-priority task is blocked. Use mutex inheritance or redesign your task priorities.
• Serial.print() from multiple tasks: Serial is not thread-safe. Wrap all Serial calls in a mutex, or create a dedicated logging task with a queue.
• Arduino libraries not thread-safe: Many Arduino libraries were written for single-threaded use. Check before sharing them between tasks — use mutexes or restrict each peripheral to one task.

Frequently Asked Questions

How many tasks can I run on ESP32 with FreeRTOS?

The ESP32 can technically run up to 32 tasks (limited by FreeRTOS configuration), but practically you are constrained by RAM. Each task consumes at minimum 1KB of stack plus its TCB (task control block, ~100 bytes). With 520KB SRAM (though much is used by WiFi/BT stacks), a realistic limit for most projects is 10-15 tasks.

What is the difference between vTaskDelay and vTaskDelayUntil?

vTaskDelay() delays from when the call is made, so if your task takes variable time to execute, the period drifts. vTaskDelayUntil() delays to an absolute tick count, making it truly periodic regardless of execution time. For sensor reading with precise timing, always use vTaskDelayUntil().

Can I use FreeRTOS with the Arduino loop() function?

Yes. The Arduino loop() function itself runs as a FreeRTOS task. You can create additional tasks in setup() and they will run concurrently with loop(). Many projects run all logic in tasks and leave loop() empty or use it for a low-priority background task.

Is FreeRTOS available on ESP8266?

The ESP8266 also has an RTOS SDK, but it is less capable — single core, less RAM, and the RTOS SDK is separate from the non-RTOS SDK. For serious multitasking IoT projects, the ESP32 is strongly recommended over the ESP8266.