ESP32 Forum

kolban wrote:@urbanze,
A question if I may. Do you really need "dual core" or do you need "multi task"?

What is the nature of your solution where you think you need to harness the power of dual core processors as opposed to a potential logical design where your design calls for multi-tasking?

You can run multiple parallel loops with multi-tasking that don't involve multi-core. I'd like to hear your use case that calls for true dual core support?

oh god, i reply wrong.. this reply is to RITESH.

thanks!.. i make a lot of test when esp32 come to my hand's

I'm a newbie with the ESP32 and I have a few question about multicore programming with arduino!

By reading this post I understand that I can use the two cores only by using the FreeRTOS. Is this correct?
Can somehow program the chip to something like void

setup1()
void loop1()

void setup2()
void loop2()

without using the RTOS?

Mr pcbreflux did a great video on using multi-tasking in Arduino land ... see:

https://www.youtube.com/watch?v=i8ffEbyU-7w&t=6s

and give it a thumbs up.

Thanks kolban! It was very helpful

Is it possible to call a function to run on core 1 when it is called inside the loop on core 0? To make it clearer, I have Bluetooth communication on core 0 and read the touch input from a touch display on core 1. When there is a Bluetooth notification the characteristic value is read in loop on core 0 and the display should be updated. I want to update it on core 1, but I have the feeling that is not good inside loop. Are there other methods to define on which core a function runs? Or to call this function again once its created?

Theoretically, you could create a task and destroy it every time you want to update the display, but indeed, this is not very efficient. It's better to have a permanent task on core 1 that normally waits for a semaphore or task notification and gets to work as soon as it receives this.

ESP_Sprite wrote:Theoretically, you could create a task and destroy it every time you want to update the display, but indeed, this is not very efficient. It's better to have a permanent task on core 1 that normally waits for a semaphore or task notification and gets to work as soon as it receives this.

Hi,

Let's consider that I need to create one application in which it requires almost 9 to 10 different tasks with different priority and stack size then which method is better like create & delete each task if not required permanent or create all tasks initially and wait for task notify event for that particular task?

Because I think it's waste of memory if we create Initially without any requirement.

Let me correct if I am wrong.

It depends on how you want to architect your application. There are a few things to take into account: 1. the cost (CPU-wise) to create and delete a task, 2. the total memory usage of your app, 3. the risk you want to take wrt 'over-booking' your RAM.

For 1, it's pretty simple. FreeRTOS lives under the assumption tasks aren't created that often and as such has no real speed optimization for these calls: it fills memory with stack canaries, happily modifies a fair lot of variables etc. This takes a while, and if you spin up a task e.g. every millisecond, you'll see a lot of time taken up by spinning up and deleting tasks.

For 2 and 3, the idea is that for an embeded application, ideally you'd want there to always be enough memory to fit all processes that can be going on at the same time to fit into all available memory. If that's the case, you can just happily spin up all tasks at boot-up and leave it at that. If you have an application that worst-case cannot fit into RAM, you can start to think about 'over-booking' your RAM: dynamically allocating and freeing memory (maybe in the form of tasks) and hoping that you won't run into the worst-case scenario because that would lead to an out-of-memory situation and if not handled well anywhere where memory is allocated, this can lead to a crash.

ESP_Sprite wrote:It depends on how you want to architect your application. There are a few things to take into account: 1. the cost (CPU-wise) to create and delete a task, 2. the total memory usage of your app, 3. the risk you want to take wrt 'over-booking' your RAM.

For 1, it's pretty simple. FreeRTOS lives under the assumption tasks aren't created that often and as such has no real speed optimization for these calls: it fills memory with stack canaries, happily modifies a fair lot of variables etc. This takes a while, and if you spin up a task e.g. every millisecond, you'll see a lot of time taken up by spinning up and deleting tasks.

For 2 and 3, the idea is that for an embeded application, ideally you'd want there to always be enough memory to fit all processes that can be going on at the same time to fit into all available memory. If that's the case, you can just happily spin up all tasks at boot-up and leave it at that. If you have an application that worst-case cannot fit into RAM, you can start to think about 'over-booking' your RAM: dynamically allocating and freeing memory (maybe in the form of tasks) and hoping that you won't run into the worst-case scenario because that would lead to an out-of-memory situation and if not handled well anywhere where memory is allocated, this can lead to a crash.

Thanks for providing response with details.