Stop Using delay(): Master FreeRTOS for Professional Arduino Multitasking

Core Concept 2: Priorities (The VIP Lane)

Not all tasks are equal.

• Safety Task: Priority 10 (Highest).
• WiFi Task: Priority 5.
• LED Blink Task: Priority 1 (Lowest).

If a Priority 10 task wakes up, the Scheduler interrupts the Priority 1 task instantly (Preemption). The LED waits. The Emergency Stop runs. This guarantees Determinism. We know exactly how long higher priority tasks will wait (almost zero).

Hands-On: The “Dual Core” ESP8266

(Note: ESP8266 is single core, but FreeRTOS simulates threads beautifully).

We will create two tasks that would be impossible with delay():

• Task 1: Print “Hello” every $500\text{ms}$.
• Task 2: Print “World” every $300\text{ms}$.

Because $500\text{ms}$ and $300\text{ms}$ are asynchronous periods, they will drift and overlap. With delay(), the total time would be $800\text{ms}$ per loop. With FreeRTOS, they run independently.

The Code:

#include <Arduino.h>

// Define Task Handles
TaskHandle_t Task1;
TaskHandle_t Task2;

void Task1Code(void * pvParameters) {
  for(;;) {
    Serial.println("Task 1: Hello");
    vTaskDelay(500 / portTICK_PERIOD_MS);
  }
}

void Task2Code(void * pvParameters) {
  for(;;) {
    Serial.println("Task 2: World");
    vTaskDelay(300 / portTICK_PERIOD_MS);
  }
}

void setup() {
  Serial.begin(115200);

  // Create Task 1
  xTaskCreatePinnedToCore(
    Task1Code,   // Function
    "Task1",     // Name
    10000,       // Stack Size (Bytes)
    NULL,        // Parameters
    1,           // Priority
    &Task1,      // Handle
    0            // Core ID
  );

  // Create Task 2
  xTaskCreatePinnedToCore(
    Task2Code,
    "Task2",
    10000,
    NULL,
    1,
    &Task2,
    0
  );
}

void loop() {
  // Empty! The Scheduler runs everything.
}

Deep Dive: Understanding xTaskCreate Parameters

The xTaskCreatePinnedToCore function is a monster. Let’s dissect it:

• TaskFunction: The function to run (e.g., Task1Code).
• Name: Human-readable label for debugging.
• Stack Size: Memory in bytes (ESP) or words (AVR).

Warning: On standard Arduino/AVR FreeRTOS, this is Words (2 bytes). This confusion causes 50% of all difficult bugs.

• Parameters: Data to pass to the task (usually NULL).
• Priority: 0 (Lowest) to 25 (Highest).
• Handle: Pointer to store the Task ID.
• Core ID: 0 for ESP8266.
  • 0: Protocol Core (WiFi/Bluetooth).
  • 1: Application Core (Your Code).
• ESP8266 Note: It only has Core 0, so this argument is ignored or must be 0.

Core Concept 3: Queues (Passing Data Safely)

The Trap: You have a Sensor Task reading temperature. You have a WiFi Task sending it. Why not just use a global variable float temp;? RACE CONDITION! What if the Sensor Task is writing 25.4 (4 bytes) and gets interrupted halfway? The WiFi task reads 25.0 (corrupted info).

The Solution: Queues. A Queue is a thread-safe pipe. One task pushes data in one end. The other pops it out. If the queue is empty, the WiFi task sleeps until data arrives.

QueueHandle_t queue;

void SensorTask(void * parameter) {
  int data = 0;
  for(;;) {
    data = analogRead(A0);
    xQueueSend(queue, &data, portMAX_DELAY);
    vTaskDelay(100);
  }
}

void WiFiTask(void * parameter) {
  int receivedData;
  for(;;) {
    if (xQueueReceive(queue, &receivedData, portMAX_DELAY)) {
      Serial.println(receivedData); // Safe!
    }
  }
}

Core Concept 4: The Mutex (The Bathroom Key)

Sometimes two tasks need to use the SAME resource (e.g., the Serial Port). If Task 1 prints “Hello” and Task 2 interrupts it to print “World”, you get messages like: HelWorldlo.

The Solution: Mutex (Mutual Exclusion). Think of it like a bathroom key.

• Take: Task requests the key (Lock).
• Use: Task accesses the shared resource.
• Wait: Other tasks wait in line if key is missing.
• Give: Task returns the key (Unlock).

SemaphoreHandle_t xMutex;

void PrintTask(void * param) {
  // Try to take the key
  if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
    Serial.println("I have the talking conch!");
    xSemaphoreGive(xMutex); // Return the key
  }
}

Advanced: The Race Condition Visualized

Imagine Task A reads a variable counter = 10. Context Switch occurs. Task B reads counter = 10. Adds 1. Saves 11. Context Switch back to A. Task A adds 1 to its old copy (10). Saves 11. Result: The counter should be 12, but it is 11. Mutexes prevent this by forcing Task B to wait until Task A is completely done.

RTOS vs Interrupts (ISR)

You might ask: “Why not just use attachInterrupt()?”

• ISR: Immediate execution; blocks everything; no Serial or delay.
• RTOS Task: Scheduled execution; can print, wait, and compute.
• The Bridge: Use an ISR to detect events, then signal a Task.

// The Bridge Pattern
void IRAM_ATTR isr() {
  xSemaphoreGiveFromISR(xSemaphore, NULL); // Wake up the task
}

Core Concept 5: Software Timers

Sometimes you don’t need a full Task just to blink an LED. You need a Timer. FreeRTOS has a “Daemon Task” that manages timers.

• One-Shot: Runs once (e.g., backlight timeout).
• Auto-Reload: Runs periodically (e.g., status heartbeats).

Why use Timers vs Tasks? Timers use less RAM. They don’t have their own huge stack. They piggyback on the system stack. Warning: Don’t do heavy work in a timer callback, or you block all other timers.

The Dangers of RTOS (What Can Go Wrong)

With great power comes great debugging nightmares.

1. Stack Overflow

In setup(), we allow 10kb of RAM (10000) for each task. If you declare a massive array int big[5000]; inside that task, you exceed the limit. The ESP8266 will crash with a “Guru Meditation Error”.

• Fix: Use global variables or increase stack size.

• Detection: Use uxTaskGetStackHighWaterMark(NULL) inside the task loop. It returns the minimum free bytes ever left in the stack. If it gets near 0, you are in danger.

void Task1Code(void * pvParameters) {
  for(;;) {
    UBaseType_t uxHighWaterMark = uxTaskGetStackHighWaterMark(NULL);
    Serial.print("Stack Space Left: ");
    Serial.println(uxHighWaterMark);
    vTaskDelay(1000);
  }
}

2. Starvation

If you have a Priority 2 task that never sleeps (no vTaskDelay), the Priority 1 tasks will never run. They starve to death.

• Rule: Every high-priority task MUST have a delay or a blocking wait (like QueueReceive).

3. Deadlock

Task A has Key 1 and wants Key 2. Task B has Key 2 and wants Key 1. Both wait forever.

• Fix: Always take mutexes in the same order.

4. Priority Inversion

• Low Priority Task holds a Mutex.
• High Priority Task needs the Mutex.
• Medium Priority Task interrupts the Low Task.
• Fix: Priority Inheritance.

Debugging: Viewing the Invisible

Since tasks switch invisibly, Serial.print creates a mess.

• GPIO Toggling: Flip a pin HIGH when entering a task, LOW when leaving.
• vTaskList(): Prints a table of all tasks, their state, and stack usage.

char ptrTaskList[250];
vTaskList(ptrTaskList);
Serial.println(ptrTaskList);

Why Use FreeRTOS?

• Modularity: Separate WiFi and Sensor logic.
• Responsiveness: Guaranteed button reaction times.
• Compatibility: Required for advanced IoT background tasks.

Glossary: Speak Like a Systems Architect

• Scheduler: The “God-mode” logic that swaps tasks.
• Context Switch: Saving/loading task states (the overhead).
• Tick: The RTOS heartbeat (usually $1\text{ms}$).
• Semaphore: A signaling flag.
• Mutex: A key used for resource locking.
• Preemption: Pausing a task for a higher-priority one.

Final Project: The “Multitasking Hub”

Combine everything.

• Task 1: Temperature sampling (Priority 2).
• Task 2: OLED updating (Priority 1).
• Task 3: Emergency button watch (Priority 3).

If the DHT11 sensor hangs (it is slow), the Button still works instantly. That is the power of RTOS. Copyright © 2026 TechnoChips. Open Source Hardware (OSHW).