Q: How to use Wait::wait_for_low and avoid the race condition between interrupt setup and pin triggering?

[MarSik]

Hi folks,

I am trying to detect a brief pulse using embedded-hal-async GPIO Wait trait. The methods like wait_for_low are perfect for that in general (https://github.com/rust-embedded/embedded-hal/blob/master/embedded-hal-async/src/digital.rs#L34)

However most of the implementations I have seen configure the interrupt within the wait_for_low method which means it must first be polled at least once (but sometimes more) before the interrupt is set up properly. See for example how the esp waits for the setup to be possible here https://github.com/esp-rs/esp-hal/blob/87d501766f178a2dd812c382ca257d268ee266ad/esp-hal/src/gpio/mod.rs#L2242

Now, I have a device where the pulse can disappear on its own and I need to detect it reliably. I have custom code that first sets up the interrupt and only then triggers the behavior. This works, but I would like to rewrite my custom code to adhere to the embedded-hal-async traits.

Do you have any idea about how to use the wait_for_low in this way? First set-up the interrupts, then do something outside to trigger the activity and then wait for the interrupt to happen?

The code I have right know looks roughly like this:

let w = WaitForPin::listen(gpio, pin, LOW);
device.start()
w.await;

TLDR: How to use Wait::wait_for_low and avoid the race condition between interrupt setup and pin triggering?

[jamesmunns]

This was discussed a bit in chat today, with some pointers to other libraries like maitake-sync that allow you to ensure the waker is registered before moving on:

https://libera.irclog.whitequark.org/rust-embedded/2025-03-30#1743332480-1743333799;

But agreed: there isn't a way to guarantee this today, at least not easily/without clunkiness.