ESP32 Forum

Hello everyone,
I found myself looking for timing issues between freeRTOS tasks. While doing that I realized I have little understanding of how freeRTOS actually works under the hood of my ESP32; I have some particular doubts I'd like to ask a clarification of, since I can't seem to find a confirmation on the online reference.

1. Does freeRTOS uses a preemptive scheduler on ESP-idf? (e.g. awaking higher priority tasks steal control from lower ones)
2. I have my configuration set to run freeRTOS only on first core. Does this mean that the scheduler runs only on core 0 and that my main runs uninterrupted on core 1?
3. A high priority task that never calls vTaskDelay will eat all the resources and never let lower priorities run, right?

maldus wrote:Does freeRTOS uses a preemptive scheduler on ESP-idf?

Yes

maldus wrote:awaking higher priority tasks steal control from lower ones

It depends on the priorities of the current running tasks on each core, and on the core affinity of the awoken task. Here a few examples:

1. Given core 0 runs a priority 10 task, core 1 runs a priority 12 task, and a priority 11 task is awoken.
- If the priority 11 task is pinned to core 0 or has no core affinity, the priority 11 task will preempt on core 0.
- If the priority 11 task is pinned to core 1, core 1 will not preempt.

2. Given core 0 and core 1 are both running tasks below priority 11, and a priority 11 tasks is awoken.
- The code that causes the preemption (e.g. xQueueSend) will always prefer to preempt on the current core. Therefore if xQueueSend was run on core 0, the priority 11 task will preempt on core 0. Same concept applies to core 1.

3. Given core 0 runs a priority 10 task, core 1 runs a priority 12 task with no affinity, and a priority 11 task pinned to core 1 is awoken.
- The priority 11 task will not preempt. An ideal algorithm would attempt to run the two highest priority tasks by shifting the priority 12 task to core 0, and then run the priority 11 task on core 1. However, the current SMP scheduling algorithm in ESP-IDF will not attempt to reshuffle the tasks across both cores.

maldus wrote:2. I have my configuration set to run freeRTOS only on first core. Does this mean that the scheduler runs only on core 0 and that my main runs uninterrupted on core 1?

Not exactly. Currently in ESP-IDF, setting configuration single core does indeed make the scheduler only run on core 0. Core 1 on the other hand will not initialized on the hardware level and essentially remains powered off (clock gated IIRC). It's technically possible to run FreeRTOS on core 0, then run some single threaded non-OS code on core 1 (e.g. bit banging or high speed driver code). However there's currently no software support for that so you'll need to implement that yourself (take a look at CPU start code to see how initialization differs under dual core and uni core configuration).

maldus wrote:3. A high priority task that never calls vTaskDelay will eat all the resources and never let lower priorities run, right?

If the high priority task is pinned to a core, then it will starve the lower priority tasks on that core from cpu time. However if the high priority task as no core affinity, it can be possible that the task will bounce between the two cores, giving the lower priority task on each core a chance to run. However, writing a task function that never blocks is very poor application design. We guard against cpu starvation using the task watchdog timer.

maldus wrote: 3. A high priority task that never calls vTaskDelay will eat all the resources and never let lower priorities run, right?

Apart from what my colleague stated, also note that vTaskDelay is not the only blocking operation available. Waiting on a queue, mutex, task notification etc will also suspend the task; in ESP-IDF this also happens in most drivers while the driver is waiting for the hardware to complete whatever it's instructed to do.

Many thanks for the responses.

Not exactly. Currently in ESP-IDF, setting configuration single core does indeed make the scheduler only run on core 0. Core 1 on the other hand will not initialized on the hardware level and essentially remains powered off (clock gated IIRC). It's technically possible to run FreeRTOS on core 0, then run some single threaded non-OS code on core 1 (e.g. bit banging or high speed driver code). However there's currently no software support for that so you'll need to implement that yourself (take a look at CPU start code to see how initialization differs under dual core and uni core configuration).

Does this mean thatthe only reason I might want to use only one core is for power saving purposes?

That, or because you wanted to save some money by buying one of the single-core variants of the ESP32. There's no real need to use only one core otherwise.