Esp32 - getting to the core of the task

[anon76350110]

@GolamMostafa

I know from theory and also from practical that tasks with equal priorities are served on Round Robin fashion with equal time slices

ON THE CONDITION that they were not running in the first place.

@GolamMostafa

Is loop() if of lowest priority (0) as you say? If so, it would never run;

No, that's not true, By that logic , Tasks that have a priority of 0 never run,
That's not true.

@GolamMostafa

but, my experiment shows that this is executed along with Task10 (priority 1) and Task11 (priority 1). So, thee is good reason to accept the loop() belongs to priority level 1.

Sure but if i recall correctly when you setup tasks you do 2 things mostly always

1. You use xTaskCreatePinnedToCore
   2, YOU SET the Priority as 1 (Therefore you re defining it)

Do you mind if it's not too much trouble to post the sketch for that test ?
i'd like to test it myself and examine it

@GolamMostafa

I really don't know when the scheduler starts

The Scheduler starts upon power up after the main file is loaded, for simplicity sake you can assume that the scheduler loads at startup of board
also , it always has the highest priority

@GolamMostafa

The following diagram extracted from your post #231 indicates that the OS gets executed along with the tasks.

No.. What that is indicating , where it says O/S is O/S LEVEL Tasks

It means that O/S Level tasks that are necessary for housekeeping or knowing what
Task need to be allocated the next slice, get loaded
it doesn't mean it's the operating system that gets executed
it's OPERATING SYSTEM LEVEL TASKS that are getting executed at that level

[noweare]

@GolamMostafa

Let us take a case with the following tasks --
Empty loop() function (Idle Task) with default priority level 1
Task11 with priority level 2
Task10 with priority level 1
No waiting time slice is inserted among the task successions.

The loop function is a task with priority 1. The idle task has a priority of 0. These
are separate tasks.

1. When tasks are created, they are in ready states.

Not neccesarily, as you find out more about intertask communication a task may be waiting
for a notification or data from a queue so it wil be in the blocked state while waiting.

2. Once uploading is finished, which task does start? I think it is the loop() function.

I think the highest priority task in the ready state would run first

3. As Task11 of higher priority (2) is ready to run, loop() task will be preempted by Task11. Task11 runs.

Yes

4. Task 10 (being of lower priority (1)) will have no chance to run. So, Task11 continues to run.

Yes

5. Task10 will be running if Task11 voluntarily (or by an external interrupt) goes to blocked/suspended state.

Yes, except that that the interrupt will not change things unless the interrupt places
task11 into the blocked state somehow allowing task10 to run.

6. I am going to prepare experiment to verify the events of the following
Task States diagram (Fig-1).

Figure-1:

Ok

7. By-the-by, FreeRTOS is composed of some codes which is also loaded in memory for execution. Is it executed along with other tasks? What is it priority level?

I don't know what you mean by that. The schedular is running in memory of course and it does
its housekeeping duties as part of the idle task.

[anon76350110]

@noweare

The loop function is a task with priority 1. The idle task has a priority of 0. These
are separate tasks.

Actually you're correct
i think i confused the two because he mentioned it was an empty task

@noweare

Not neccesarily, as you find out more about intertask communication a task may be waiting
for a notification or data from a queue so it wil be in the blocked state while waiting.

No, but initially , All Tasls start in the Ready State
When a task Is explicitly created, it initially gets put in the READY State
and then it changes state from there based on certain factors and instructions as you said, right ?
I;m going through the docs now, i specifically remember it said that all tasks start in ready state

[noweare]

@anon76350110

@noweare

Not neccesarily, as you find out more about intertask communication a task may be waiting
for a notification or data from a queue so it wil be in the blocked state while waiting.

No, but initially , All Tasls start in the Ready State
When a task Is explicitly created, it initially gets put in the READY State
and then it changes state from there based on certain factors and instructions as you said, right ?
I;m going through the docs now, i specifically remember it said that all tasks start in ready state

Execution inside the task loop (inside the for loop ) does not happen because the task is waiting on something to happen. I do not really consider that task being "run" or "running".

[anon76350110]

@noweare

Execution inside the task loop (inside the for loop ) does not happen because the task is waiting on something to happen. I do not really consider that task being "run" or "running".

Yeah ok, i agree with that, i was referring to the Function not the FOR loop.
but in that case, Yes i agree
thanks for clarifying

[GolamMostafa]

Thank you for evaluating my understandings. Now, I have got some clues/basis to begin systematic studies of the FreeRTOS Operating System designed for Embedded Systems.

[DrDiettrich]

@GolamMostafa

begin systematic studies

Thank you

[GolamMostafa]

I hope that it will be more interesting once your ESP32 is commissioned.

[GolamMostafa]

@anon76350110

i think i confused the two because he mentioned it was an empty task

By empty tasks, I have wanted to mean the loop() function without any executable codes inside. It is like:
void loop(){}

[DrDiettrich]

@GolamMostafa

It is like:
void loop(){}

Don't forget:
void task(void* pvParams) { while(true) loop(); }
or
void main() { setup(); while(true) loop(); }
so that the task is not empty nor exits.

[gfvalvo]

@noweare

I don't know what you mean by that. The schedular is running in memory of course and it does
its housekeeping duties as part of the idle task.

Most of the real work done by FreeRTOS happens when the application code makes API calls and during the Tick Period ISR. Those are the times it has an opportunity to do context switches, etc.

You can also request a context switch upon return from a user ISR. So if the ISR causes a higher-priority task to become ready (by posting to a queue, sending a notification, etc), then when the ISR exits, control will pass to that new task and not the original one that was interrupt.

[DrDiettrich]

@gfvalvo

You can also request a context switch upon return from a user ISR.

Please do not confuse people with such details about process control in code. Most contributions still are about task creation and try to find the woodoo behind the scene. We could rename this topic into "Control ESP32 tasks without using any task control API". <BG>

Thanks anyway for your contribution, I really like it. Unfortunately I'm still waiting for the cables to my ESP but already have two new topics on hold:

1. Ways to crash ESP32
2. Using ESP32 task control APIs

Do you think I could place the latter topic into "Programming Questions"?

[noweare]

@gfvalvo

@noweare

I don't know what you mean by that. The schedular is running in memory of course and it does
its housekeeping duties as part of the idle task.

Most of the real work done by FreeRTOS happens when the application code makes API calls and during the Tick Period ISR. Those are the times it has an opportunity to do context switches, etc.

You can also request a context switch upon return from a user ISR. So if the ISR causes a higher-priority task to become ready (by posting to a queue, sending a notification, etc), then when the ISR exits, control will pass to that new task and not the original one that was interrupt.

Right,
from the manual "If a context switch should be performed, then the interrupt safe API function will set *pxHigherPriorityTaskWoken to pdTRUE. "

I had to look at that a few times before I figured out what it was trying to tell me.
Yes, the idle task is where context switching is decided.

Note: In the idf the default tick is 10 milliseconds but can be changed.
In the arduino it is 1 millisecond and I don't think it can be changed. That seems like
a pretty fast tick period to me.

[gfvalvo]

@noweare

Yes, the idle task is where context switching is decided.

NO. Like I said it will happen when user code calls an API that triggers an event causing a context switch. Or, upon return from an ISR that triggers an event causing a context switch. Or during the Tick ISR.

The Idle Task doesn't run reliably / periodically enough to handle that.

[gfvalvo]

@DrDiettrich

"Control ESP32 tasks without using any task control API"

You can do absolutely nothing useful in FreeRTOS without understanding "task control APIs". Seven out of the twelve chapters in "Mastering the FreeRTOS™ Real Time Kernel" are dedicated to those APIs. If you're not going to understand them, then you can't do inter-task communication and synchronization. In that case, there's no reason to bother with FreeRTOS at all.

[gfvalvo]

I’m still seeing incorrect statements and general confusion in this thread about task priorities and context switching. Here’s concrete example that may clear things up a little (or not?). Try running the code below.

Then see if you can use the algorithm that I provided in a previous post to explain why the printouts happen in the order they do. Then change the relative priorities of the three tasks and see if the printouts happen in the order you thought they would.

#include "Arduino.h"

void producerFunction(void *pvParameters);
void consumerFunction(void *pvParameters);

TaskHandle_t consumer0TaskHandle;
TaskHandle_t consumer1TaskHandle;

void setup() {
	Serial.begin(115200);
	vTaskDelay(2000);
	Serial.println("Starting");

	uint32_t ConsumerTaskNumber = 0;
	xTaskCreatePinnedToCore(consumerFunction, "Consumer Task 0", 2000, &ConsumerTaskNumber, 2, &consumer0TaskHandle, CONFIG_ARDUINO_RUNNING_CORE);
	vTaskDelay(500);

	ConsumerTaskNumber = 1;
	xTaskCreatePinnedToCore(consumerFunction, "Consumer Task 1", 2000, &ConsumerTaskNumber, 6, &consumer1TaskHandle, CONFIG_ARDUINO_RUNNING_CORE);
	vTaskDelay(500);

	xTaskCreatePinnedToCore(producerFunction, "Producer Task", 2000, NULL, 4, NULL, CONFIG_ARDUINO_RUNNING_CORE);
}

void producerFunction(void *pvParameters) {
	Serial.println("Starting Producer Task");
	vTaskDelay(2000);
	Serial.printf("\nProducer Task: Sending Notifications\n");
	xTaskNotifyGive(consumer0TaskHandle);
	xTaskNotifyGive(consumer1TaskHandle);
	Serial.printf("Producer Task: Notifications Sent\n");

	for (;;) {
		vTaskDelay(1000);
	}
}

void consumerFunction(void *pvParameters) {
	uint32_t taskNumber = *reinterpret_cast<uint32_t*>(pvParameters);
	Serial.printf("Starting Consumer Task # %d\n", taskNumber);

	for (;;) {
		ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
		Serial.printf("Consumer Task %d Received Notification\n", taskNumber);
	}
}

void loop() {
}

[anon76350110]

@GolamMostafa

@anon76350110

i think i confused the two because he mentioned it was an empty task

By empty tasks, I have wanted to mean the loop() function without any executable codes inside. It is like:
void loop(){}

Of course, what else could it mean .
but i think when i answered the question i'm pretty sure i confused it with the IDLE task priority. IDLE has a Priority of 0

[GolamMostafa]

@anon76350110

IDLE has a Priority of 0

Any practical example of an ideal task?

[anon76350110]

@DrDiettrich

We could rename this topic into "Control ESP32 tasks without using any task control API"

We could...... LOL
However when we started this topic we had a little discussion as to the name and this is what we came up with .
Had we known the direction it would go in, maybe it'd be a different name but hey...
This actually was the point of what i wanted to do, To deep dive into multi core and multi tasking so......it's fine by me .
Let's just discuss it
also , i'm still working through the document and getting the test project ready

@DrDiettrich

Thanks anyway for your contribution, I really like it. Unfortunately I'm still waiting for the cables to my ESP but already have two new topics on hold:

And given my recent issues with the ESP32's that i have i've ordered a few more and am waiting on them to arrive

@DrDiettrich

Ways to crash ESP32

Sounds Fun

@DrDiettrich

1. Using ESP32 task control APIs

Do you think I could place the latter topic into "Programming Questions"?

Yeah i think that should be cool

[anon76350110]

1. Did you mean IDLE or IDEAL ?
2. in any case not as yet because i'm concentrating on going through the RTOS Manual
   and getting a few practical things sorted so we can start doing interesting practical stuff

I will at some later point address this though, it's not a priority now,
my answer for now is just based on what the documentation says