Skip to content

Conversation

@uLipe
Copy link

@uLipe uLipe commented Oct 31, 2025

On dual core esp32 the either the interrupts and the FoC task may migrate to a different core, making the ADC registers subject to corruption if the other core tries to manage the ADC while current core owns it, so add a spinlock around the ADC to avoid that. On single core devices this is call is a NOOP.

On dual core esp32 the either the interrupts and the FoC task may migrate
to a different core, making the ADC registers subject to corruption if
the other core tries to manage the ADC while current core owns it, so
add a spinlock around the ADC to avoid that. On single core devices
this is call is a NOOP.

Signed-off-by: Felipe Neves <[email protected]>
@uLipe uLipe marked this pull request as draft October 31, 2025 13:07
@uLipe uLipe marked this pull request as ready for review October 31, 2025 13:45
@uLipe
Copy link
Author

uLipe commented Oct 31, 2025

@askuric @runger1101001 PTAL :)

@runger1101001
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants