Q: How to use Wait::wait_for_low and avoid the race condition between interrupt setup and pin triggering?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- rust
- Domain
- embedded-iot
Research direction
Start with embedded-hal-async/src/digital.rs at the Wait trait and compare the esp-hal GPIO implementation linked in the report. Determine whether the trait needs usage guidance or an API change to make interrupt setup safe before triggering activity, then document or specify the intended sequence and its completion criteria.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- Rust
- Stars
- 2.7k
- Forks
- 283
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-embedded/embedded-hal
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
rust-embedded/embedded-hal#742 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
rust-embedded/embedded-hal#747 · 5 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
rust-embedded/embedded-hal#746 · 2 comments · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rust-embedded/embedded-hal#745 · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
rust-embedded/embedded-hal#744 · 1 comment ·
All issues in rust-embedded/embedded-hal
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
Devolutions/picky-rs#546 · 1 comment ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zcashlabs/thus-spoke-zakura#153 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
topgrade-rs/topgrade#2395 ·
Maintainers usually reply within 1 day