Prioritizing Tasks for Responsive Motor Control and Reliable Sensor Sampling

1. The Heart of the RTOS: The Preemptive Scheduler

At the core of any Real-Time Operating System (RTOS) like FreeRTOS is the scheduler. The scheduler's job is to decide which task gets to use the CPU at any given moment. FreeRTOS uses a preemptive, priority-based scheduler.

• Priority-Based: You assign a numerical priority to each task. A higher number means a higher priority.
• Preemptive: If a high-priority task becomes ready to run (for example, it receives a message in a queue), it will immediately interrupt, or preempt, any lower-priority task that is currently running.

Think of it like an emergency room triage system. A patient with a critical injury (a high-priority task) will be seen by a doctor immediately, even if the doctor was in the middle of examining a patient with a minor cold (a low-priority task).

To understand this mechanism, it's crucial to know the different states a task can be in.

To solidify these concepts, let's review them with a textual summary.

The most important takeaway is this: a lower-priority task will only get CPU time when no higher-priority tasks are in the Ready state. This is why high-priority tasks must be designed to enter the Blocked state (e.g., by calling vTaskDelay() or waiting on a queue) to allow other tasks to run.

2. Choosing the Right Priorities for Our System

Now, let's apply this to our project. We have two main tasks: one for motor control and one for sensor sampling. How should we prioritize them?

• motor_control_task: This task needs to be highly responsive. When a command arrives in its queue, we want it to execute almost instantly to ensure precise control. A delay could mean the motor overshoots its target or fails to stop in an emergency. This task is a clear candidate for a higher priority.
• temp_sensor_task: This task is less time-critical. It performs a periodic action (reading a sensor). If its execution is delayed by a few milliseconds because the motor task needed the CPU, the impact is likely negligible. It just means the sensor reading happens slightly later. This task is a good candidate for a lower priority.

Let's say we assign Priority 2 to the motor_control_task and Priority 1 to the temp_sensor_task. The system will behave as follows:

1. The temp_sensor_task runs, samples the temperature, and calls vTaskDelay() to wait for its next sampling interval. This moves it to the Blocked state.
2. While the sensor task is blocked, other lower-priority tasks (or the idle task) might run.
3. A command is sent to the motor control queue. This moves the motor_control_task from Blocked to Ready.
4. Because the motor task (Priority 2) has a higher priority than the currently running task (e.g., the sensor task at Priority 1 or the idle task at Priority 0), the scheduler immediately preempts the running task and puts the motor_control_task into the Running state.
5. The motor task executes the command and then blocks, waiting for the next command.
6. Now that the highest-priority ready task is gone, the scheduler can resume the lower-priority task that was interrupted.

This ensures snappy motor performance without preventing the sensor from being sampled.

3. A Practical Thought Experiment

To really understand the implications of priority, let's consider a simple example with two tasks: one that blinks an LED and another that reads user input from the serial monitor to change the blink rate.

4. Implementing Priorities in Code

Assigning a priority in ESP-IDF is done via the uxPriority parameter of the xTaskCreate() function. Priorities can range from 0 (lowest) up to configMAX_PRIORITIES - 1. For our system, let's use 1 for the sensor and 2 for the motor.

// In our main application setup
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

// Define task handles
TaskHandle_t motor_task_handle = NULL;
TaskHandle_t sensor_task_handle = NULL;

// ... (Task function definitions for motor_control_task and temp_sensor_task) ...

void app_main() {
    // ... (Initialize peripherals, queues, mutexes, etc.) ...

    // Create the sensor task with a lower priority
    xTaskCreate(
        temp_sensor_task,       // Function to implement the task
        "Sensor Task",          // Name of the task
        4096,                   // Stack size in words
        NULL,                   // Task input parameter
        1,                      // Priority of the task (lower)
        &sensor_task_handle     // Handle to the task
    );

    // Create the motor task with a higher priority
    xTaskCreate(
        motor_control_task,     // Function to implement the task
        "Motor Control Task",   // Name of the task
        4096,                   // Stack size in words
        NULL,                   // Task input parameter
        2,                      // Priority of the task (higher)
        &motor_task_handle      // Handle to the task
    );
}

By making this simple change—adjusting a single number for each task—we have fundamentally improved the real-time behavior of our application, ensuring our motor control is always prioritized.

Conclusion

In this lesson, we explored one of the most powerful features of a Real-Time Operating System: task prioritization. You learned how the preemptive scheduler works and how to leverage it to meet the performance requirements of a real-world embedded system.

Key Takeaways:

• Preemptive, Priority-Based Scheduling: FreeRTOS always runs the highest-priority task that is ready. This task can interrupt (preempt) lower-priority tasks.
• Task States are Key: Tasks must enter a Blocked state (via vTaskDelay, waiting on queues, etc.) to allow lower-priority tasks to run.
• Prioritize for Responsiveness: Assign higher priorities to time-critical tasks like motor control and lower priorities to background or less-critical tasks like periodic sensor sampling.
• Avoid Starvation: Be careful not to create a high-priority task that never blocks, as it will starve all lower-priority tasks of CPU time.

We have now designed a sophisticated multi-tasking application. We have tasks for different peripherals, queues for communication, mutexes for safety, and priorities for performance. But how can we be sure it's all working as intended? How do we debug issues or analyze performance?

In our next lesson, we will learn how to use ESP-IDF tools to analyze task execution, CPU load, and memory usage. This will give us the visibility we need to verify our design and optimize our system's performance.