ivmarkov

> I don't think I have the required knowledge to come up with an ideal implementation of it. > > The main challenge here, is to work asynchronously, since the...

> Hmm, I don't think this fix is the right way to go about this. The 802.11 spec says the SSID can either be valid UTF-8 _or_ unspecified data. Therefore...

> given the following code. is this a correct way to use the criticalsection to recreate an mutex'ish behaviour. (given that no one manual overrides the locked AtomicBool) I think...

OK. Forgot the one **major** difference between our `CriticalSection` implementations and a standard STD mutex: * Our critical sections are re-entrant (as in if a thread already keeps the lock...

> > But perhaps your biggest confusion is that somehow esp_idf_hal::task::CriticalSection does something very different from a Rust STD Mutex. It doesn't > > thx for the feedback! i somehow...

@Vollbrecht I'm pulling out this comment out of the code review, as it is related to the general approach in terms of `spi_pool` (the rest looks OK modulo some renames)....

@mr-sven Can you test with the latest compiler and let us know if you still see the issue? Otherwise, your approach is correct - you have to - from time...

If you want to busy-loop in the main (or whichever thread) *forever*, then I suggest you instead simply disable the TWDT as described [here](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html#config-esp-task-wdt-en). Note though that this is not...

I can also re-open this issue (you seem to feel very strongly about this :p) but I don't have time ATM to implement it. Would you be willing to spend...

> For instance let's assume I need to toggle a pin every 100 µs. I don't think this is too uncommon. How would I implement that? 100uS is quick, yet...