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
proceed as normal (i.e. compile to -imac and use trap handler) but compile just embassy with opt-level = 0
Switch to -imc and fork defmt-rtt to use atomic-polyfill instead of core::sync::atomic
Regardless of which approach to use, I think that I should be eschewing core::sync::atomic in favor of atomic-polyfill in my code, to avoid this issue on any platforms without an atomic trap handler
I've been tracking my time spent debugging this (just for science) and I think I've spent about 24hrs over the last 4 days or so
The text was updated successfully, but these errors were encountered:
Switching to -imc should be preferred due to the performance implications of the atomic trap, and will have support in defmt-rtt when knurling-rs/defmt#702 is merged.
The bug in the atomic trap handler has been fixed due to esp-rs/esp-hal#207 and esp-rs/riscv-atomic-emulation-trap#4. This should be live with an upcoming release of esp-hal. They mentioned it would take some small changes to esp-wifi too though, and wifi is the next thing for me to test. So I may stay on 0.2 for just a bit longer till 0.3 is published and I confirm from them on matrix that esp-wifi should work
Next steps:
Test that those linked PRs actually fix the issue, and let the maintainers in esp-rs know
Adopt the -imc approach due to performance and portability, refactor my code to no longer rely on core::sync::atomic. atomic-polyfill should be used if I feel like I need atomics.
Looks like the atomic trap handler in
esp-hal
is being a ඞඞsussy bakaඞඞBlocked by esp-rs/riscv-atomic-emulation-trap#3 and also knurling-rs/defmt#597
Related: embassy-rs/embassy#995
Options for workarounds:
-imac
and use trap handler) but compile just embassy withopt-level = 0
-imc
and forkdefmt-rtt
to useatomic-polyfill
instead ofcore::sync::atomic
Regardless of which approach to use, I think that I should be eschewing
core::sync::atomic
in favor ofatomic-polyfill
in my code, to avoid this issue on any platforms without an atomic trap handlerI've been tracking my time spent debugging this (just for science) and I think I've spent about 24hrs over the last 4 days or so
The text was updated successfully, but these errors were encountered: