critical_section implementations

[MabezDev]

With the upcoming release of critical-section, default implementations for each arch are being removed. Instead, they should be implemented by the HALs/PAC on a per chip basis. This allows critical sections to be correctly implemented for dual-core chips, and or take advantage of hardware semaphores instead of spin locking.

A note on Xtensa implementations, we should not be disabling interrupts for our critical sections, this means the waiti instruction will never return. Instead, we should be raising the PS.INTLEVEL accordingly. See esp-rs/xtensa-lx#20.

The new release isn't out yet, but we should track the implementations we'll need here.

• Multicore aware Xtensa cs - esp32, esp32s3
• RISCV32 single core cs - esp32c3
• Xtensa single core cs - esp32s2

[jrmoulton]

I'm working on the SpiDevice trait but it seems like before anything is workable there is work that needs to be done for the 1.0 release of critical-section and its implementation here, correct?

[MabezDev]

You can use the Mutex's inside https://github.com/esp-rs/xtensa-lx/blob/master/src/mutex.rs for now, we can swap them out with critical_section implementations if that makes sense later down the line :).

[MabezDev]

I've just abandoned #90. We are semi-blocked on both critical_section 1.0 for configurable token sizes & and bare_metal minor release with Refcell convenience functions. Without either of these, we are probably better off using the xtensa_lx::mutex stuff for now, unless we really need it for something.

[jessebraham]

critical-section 1.0.0 has been released, so I suppose the only remaining blocker on this is a new bare-metal release.

[MabezDev]

I believe critical-section is now a full replacement for bare_metal (at least the parts we need (the Mutex)), I'll work on an implementation soon :).