@askuric @runger1101001 PTAL :)

Hey, once again thank you!

AFAIK, in Arduino there is the ARDUINO_RUNNING_CORE and that one should keep the loop() function?

How about the interrupts, that has been a question I wanted to look into… generally speaking I think users would expect the interrupts to run on the same core as the loop, so prevent concurrency issues?

Some users, especially on single core systems would like to run their motor loops exclusively, disabling other tasks - there’s a couple of threads on the forum recently related to this on C3 and C6 MCUs.

So I guess I have the question whether we can ensure that motor task and its interrupts don’t migrate and thereby perhaps also avoid the need for locking?

Hey @runger1101001, the idea of this change is to cover custom cases where ESP32 users don't want to pin the FoC loop into the arduino loop or a particular task, this is particular advantageous on ESP32 with dual core support because it increases the scheduler throughput but at cost of the loop or or any concurrent access of the ADC to happen at different cores.

This will just translate to an s32ci instruction on ESP32 with dual cores and will not disable the interrupts, just protects the resource to be accessed by other core, on single core chips liike C3 or C6 it will be treated as a noop call since they don't support spin-locks.

In respect of your question the only way to guarantee that is to also control the interrupt allocation using the intr_alloc module from ESP-IDF which is in Arduino core underneaths.

@runger1101001 just a friendly reminder, will we follow with this PR?

No pressure, just following-up.

Thank you 😃

@runger1101001 @askuric just a friendly ping.

Hello @runger1101001 @askuric , just doing another friendly follow-up

Hello @runger1101001 @askuric , just doing another friendly follow-up

Hey @uLipe,
This is an interesting discussion but also one that cannot necessarily be addressed in one single PR. So LGTM