You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's no critical-section implementation for esp-lp-hal besides the default implementation that comes from not specifying an implementation.
This currently causes an issue that a project with both esp-hal and esp-lp-hal cannot be in the same crate. And it might means that, since HP and LP memory is shared the LP core could access memory used by the HP core during a critical section of code.
Solution
Implement a multi-core safe critical-section for esp-lp-hal.
Alternatives
The alternative to not having a critical section is to somehow ensure that the cores won't ever have any resource conflicts, but we cannot rely on Rust to give us these guarantees.
The text was updated successfully, but these errors were encountered:
This currently causes an issue that a project with both esp-hal and esp-lp-hal cannot be in the same crate.
Defining a critical section may not be a solution anyway. The ESP32-S3 and the C6 use different restore state types (I don't really know why, but that's besides the point), and so if the lp-hal ends up matches one of them, the other one would have the same problem you have now.
Also note that esp-lp-hal does have a critical-section implementation via the riscv crate.
Motivations
There's no critical-section implementation for
esp-lp-hal
besides the default implementation that comes from not specifying an implementation.This currently causes an issue that a project with both esp-hal and esp-lp-hal cannot be in the same crate. And it might means that, since HP and LP memory is shared the LP core could access memory used by the HP core during a critical section of code.
Solution
Implement a multi-core safe critical-section for esp-lp-hal.
Alternatives
The alternative to not having a critical section is to somehow ensure that the cores won't ever have any resource conflicts, but we cannot rely on Rust to give us these guarantees.
The text was updated successfully, but these errors were encountered: