Hello guys,
So I was wondering which is a better practice and why:
1. Create a task and do an infinite loop inside the task
2. Do an infinite loop and call xTaskCreate(...) on each iteration.
I'm not interested in complicated scenarios, that only require only one or the other, just a simple read a sensor value and print to UART.
As a personal preference I prefer option 1, but recently I started to wonder if this is the best practice.
Infinite loop best practices
Re: Infinite loop best practices
I think there needs to be more context to give a proper answer ... but based on what youve written, I would say that you would want to loop within a task and in that task, read a sensor, process it ... and then go back to the start to loop.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: Infinite loop best practices
Thank you for your reply.
The reasoning behind the question is that I was wondering if somehow ESP32/FREERtos is optimized for multiple task running rather than one infinite long task. So if it's not more efficient to create a task, run it and end it than crating one task that runs forever.
The reasoning behind the question is that I was wondering if somehow ESP32/FREERtos is optimized for multiple task running rather than one infinite long task. So if it's not more efficient to create a task, run it and end it than crating one task that runs forever.
Re: Infinite loop best practices
There is a VERY good book on FreeRTOS available here:
http://www.freertos.org/Documentation/1 ... _Guide.pdf
If we look on page 46 (at the time of writing) we find the following:
It has been my experience that creating a task, doing some work and then ending the task "works" just fine. So what we have to do is do some thinking into the implications of starting tasks and why a new task per "work item" is either bad or good.
If we start a task per work item, let it handle that work item and then end, I am going to claim that is more "intuitive". It also allows us to process "n" work items in parallel where "n" can be variable. The down side is that there is wasted CPU overhead in starting a task, letting it do its house keeping and then ending. If we pre-create tasks and let them exist forever then I presume the event that causes it to wake up is much cheaper than creating a task by itself. However, there is a non trivial memory cost in having a task "exist" and not doing any work.
Another factor is timing ... since the creation of a task costs CPU cycles that equates to elapsed time where the CPU is not running you code. If we are processing some electronic signals that need attended to in real-time, we would want to minimize the latency ... and again, pre-creating tasks would be the solution. However there are also classes of problem where a few milliseconds to create a task is nothing ... for example when handling an incoming network request for low volume traffic.
To me I would files these considerations in the back of my mind and then look on a case by case basis.
http://www.freertos.org/Documentation/1 ... _Guide.pdf
If we look on page 46 (at the time of writing) we find the following:
When I read this, I was surprised. To me a task/thread is started up to handle asynchronous work, does it work in parallel and then ends when it has no more work to do. The alternative is that we start tasks with the thinking that they will "eventually" do work and then they are blocked waiting for a signal from another task.Each task is a small program in its own right. It has an entry point, will normally run forever within an infinite loop, and will not exit.
It has been my experience that creating a task, doing some work and then ending the task "works" just fine. So what we have to do is do some thinking into the implications of starting tasks and why a new task per "work item" is either bad or good.
If we start a task per work item, let it handle that work item and then end, I am going to claim that is more "intuitive". It also allows us to process "n" work items in parallel where "n" can be variable. The down side is that there is wasted CPU overhead in starting a task, letting it do its house keeping and then ending. If we pre-create tasks and let them exist forever then I presume the event that causes it to wake up is much cheaper than creating a task by itself. However, there is a non trivial memory cost in having a task "exist" and not doing any work.
Another factor is timing ... since the creation of a task costs CPU cycles that equates to elapsed time where the CPU is not running you code. If we are processing some electronic signals that need attended to in real-time, we would want to minimize the latency ... and again, pre-creating tasks would be the solution. However there are also classes of problem where a few milliseconds to create a task is nothing ... for example when handling an incoming network request for low volume traffic.
To me I would files these considerations in the back of my mind and then look on a case by case basis.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: Infinite loop best practices
Thank you very much for your answer. I will take this into consideration on my further projects.
On a side note, Keep up the good work
...
On a side note, Keep up the good work
...Who is online
Users browsing this forum: No registered users and 278 guests