Hi!
general question about FreeRTOS working on a multicore chip like ESP32: how tasks are scheduled on the two cores if no "pin" option was chosen when created? WIll FreeRTOS schedule the tasks based on the first available core? Or a task is always executed on a single core (the one chosen at the first execution?)
is there a way to "know" (and maybe printout) which core is executing the task?
thanks!
FreeRTOS multicore behavior
Re: FreeRTOS multicore behavior
@kurtzweber,
Your question is great and I too keenly await any feedback on it. I had a grunge through the source and it "appears" that we can determine which core we are running on by using the macro:
This will return either 0 or 1 depending on the currently executing core. I'm not sure if this is an exposed/documented API or not, so your mileage may vary.
Your question is great and I too keenly await any feedback on it. I had a grunge through the source and it "appears" that we can determine which core we are running on by using the macro:
Code: Select all
int id = xPortGetCoreID();
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
-
- Posts: 9723
- Joined: Thu Nov 26, 2015 4:08 am
Re: FreeRTOS multicore behavior
Your asumption indeed is correct; not pinning the task essentially allows the scheduler of any of the two CPUs to pick it up, which in a way means that whichever CPU has computing time left will run it. Kolbans way of figuring out the CPU that the task running on is correct. Take care, however; because the CPU the task is running on can change at any moment, it's possible that after returning from this function the core already changed, making the value you got invalid. (To get around it, you can wrap the entire thing in a critical section; that disables context switches for the duration of that section.)
Re: FreeRTOS multicore behavior
One exception to the above rule are non-pinned tasks which use FPU. In the current implementation FreeRTOS will pin them to the CPU they are running on the first time the code tries to use FPU.
Re: FreeRTOS multicore behavior
The comment on the FPU brings up a follow on question ... as I understand it ... FPU is a "Floating Point Unit" which is (I believe) and internal component of a CPU. If we are writing arbitrary C applications, how do we know or control whether the FPU is being engaged?
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: FreeRTOS multicore behavior
Unless you are running something like an interpreter which allows arbitrary code to be executed, most of the time you can tell whether use are using floats and doubles in the application. If you are operating on float and double variables, FPU will probably be used. If you don't have anything related to floats and doubles in your task code, FPU will not be used, because all the "system" components (RTOS, TCP/IP stack, etc) don't use floating point operations. One obvious exception to this are C library formatting functions, when floating point formats are used in the format string.
-
- Posts: 64
- Joined: Tue Jan 10, 2017 1:09 pm
Re: FreeRTOS multicore behavior
guys, thanks a lot for your explanation!
Re: FreeRTOS multicore behavior
This thread has been very helpful.
I wonder if there has been any progress made to remove the CPU pinned on FPU usage?
My application uses the cJSON library included in the IDF. It stores and parses every numerical value as a double... there for FPU usage, right?
Seems like any process that touches a JSON is going to get pinned to a CPU... or at least any JSON which contains a number value.
I wonder if there has been any progress made to remove the CPU pinned on FPU usage?
My application uses the cJSON library included in the IDF. It stores and parses every numerical value as a double... there for FPU usage, right?
Seems like any process that touches a JSON is going to get pinned to a CPU... or at least any JSON which contains a number value.
Re: FreeRTOS multicore behavior
Hi coopDis,
Yes, any task which does floating point calculations will end up pinned to a core. Working with numeric values in cJSON will probably cause this to happen.
This is still planned to be addressed in a future update, but we don't have an ETA for it yet.
BTW, since this thread was started the ESP-IDF docs have been updated with descriptions of the SMP features:
https://docs.espressif.com/projects/esp ... s-smp.html
Yes, any task which does floating point calculations will end up pinned to a core. Working with numeric values in cJSON will probably cause this to happen.
This is still planned to be addressed in a future update, but we don't have an ETA for it yet.
BTW, since this thread was started the ESP-IDF docs have been updated with descriptions of the SMP features:
https://docs.espressif.com/projects/esp ... s-smp.html
Who is online
Users browsing this forum: No registered users and 120 guests