strange behavior with use of cpu=0 for application Tasks

[snahmad75]

Hi,

I was using cpu=0 for both wifi and LWIP
cpu=1 for rest of my threads which are about 4 with same priority=6.

I move my TCP/UDP data process thread from cpu=1 to cpu=0 then I got strange behavior with my LED flashing stop working properly.

Can i use cpu=0 for my application Task?

[eagi223]

I've seen similar behavior on a device I'm developing on a custom board that has a piezo for beeps and an RGB led. When wifi is connecting for, the piezo/led will stutter, even though they are being driven by FreeRTOS timer callbacks. I believe this may be caused by wifi blocking both cpu 0 and cpu 1 briefly during the wifi connection process, though I'm not sure why that would happen if all wifi backend processes are only happening on cpu 0. I think best practice for the ESP32 is to leave cpu 0 for wifi and Bluetooth (since they are both processor hungry) and run everything else on cpu 1.

[snahmad75]

I've seen similar behavior on a device I'm developing on a custom board that has a piezo for beeps and an RGB led. When wifi is connecting for, the piezo/led will stutter, even though they are being driven by FreeRTOS timer callbacks. I believe this may be caused by wifi blocking both cpu 0 and cpu 1 briefly during the wifi connection process, though I'm not sure why that would happen if all wifi backend processes are only happening on cpu 0. I think best practice for the ESP32 is to leave cpu 0 for wifi and Bluetooth (since they are both processor hungry) and run everything else on cpu 1.

ok, thanks for sharing your experience.

How about LWIP socket Task for selection for cpu=0 or cpu=1

[eagi223]

I've seen similar behavior on a device I'm developing on a custom board that has a piezo for beeps and an RGB led. When wifi is connecting for, the piezo/led will stutter, even though they are being driven by FreeRTOS timer callbacks. I believe this may be caused by wifi blocking both cpu 0 and cpu 1 briefly during the wifi connection process, though I'm not sure why that would happen if all wifi backend processes are only happening on cpu 0. I think best practice for the ESP32 is to leave cpu 0 for wifi and Bluetooth (since they are both processor hungry) and run everything else on cpu 1.

ok, thanks for sharing your experience.

How about LWIP socket Task for selection for cpu=0 or cpu=1

All tasks that I'm manually creating with xTaskCreatePinnedToCore() are assigned to core 1. Everything that the IDF uses in the background is being set to the default core (I think they're all on 0). Maybe this is some outdated thinking leftover from when the ESP32 was going to originally be setup to have core 0 (PRO CPU) for handling protocol tasks and core 1 (App CPU) for handling the user application. The Pro CPU naming is leftover from that if I'm not mistaken. Pro for protocol, not professional. I structured my firmware this way just following the suggestion of a pretty experienced ESP32 dev that comes and helps us with projects occasionally and it seems to be working out pretty well.

If you're having the LED driven directly from a task (like a loop setting the pin high, then low, repeat) then it may help the consistency of the blinking to trigger that off of an interrupt or a FreeRTOS timer callback. Though as I said before, I still have my LED and piezo stutter as wifi is connecting even with them being triggered from timer callbacks.

[snahmad75]

ok, no worries. I will follow recommendations. use cpu=1 for all my applications tasks. set cpu=0 for wifi and LWIP in menuconfig. seem works for me so far.