Dual core

User avatar
urbanze
Posts: 157
Joined: Sat Jun 10, 2017 9:55 pm
Location: Brazil

Re: Dual core

Postby urbanze » Mon Jun 12, 2017 2:37 pm

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 :twisted:

JohnKed
Posts: 13
Joined: Sat Jun 24, 2017 9:07 am

Re: Dual core

Postby JohnKed » Mon Jun 26, 2017 3:03 pm

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?

User avatar
kolban
Posts: 1460
Joined: Mon Nov 16, 2015 4:43 pm
Location: Texas, USA

Re: Dual core

Postby kolban » Mon Jun 26, 2017 5:08 pm

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.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32

JohnKed
Posts: 13
Joined: Sat Jun 24, 2017 9:07 am

Re: Dual core

Postby JohnKed » Tue Jun 27, 2017 10:09 am

Thanks kolban! It was very helpful

ahue32
Posts: 15
Joined: Mon Nov 06, 2017 10:09 am

Re: Dual core

Postby ahue32 » Fri Jan 12, 2018 12:15 pm

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

Code: Select all

xTaskCreatePinnedToCore(...)
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?

ESP_Sprite
Posts: 1572
Joined: Thu Nov 26, 2015 4:08 am

Re: Dual core

Postby ESP_Sprite » Sat Jan 13, 2018 3:10 am

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.

Ritesh
Posts: 485
Joined: Tue Sep 06, 2016 9:37 am
Location: India
Contact:

Re: Dual core

Postby Ritesh » Tue Jan 16, 2018 5:33 pm

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.
Regards,
Ritesh Prajapati

ESP_Sprite
Posts: 1572
Joined: Thu Nov 26, 2015 4:08 am

Re: Dual core

Postby ESP_Sprite » Wed Jan 17, 2018 3:33 am

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.

Ritesh
Posts: 485
Joined: Tue Sep 06, 2016 9:37 am
Location: India
Contact:

Re: Dual core

Postby Ritesh » Wed Jan 17, 2018 8:34 am

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.
Regards,
Ritesh Prajapati

Who is online

Users browsing this forum: No registered users and 2 guests