Add async gpio support #64
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d3zd3z
force-pushed
the
embassy
branch
3 times, most recently
from
37d825c to
15f1cb3
Compare
Add methods for get and set of pin logical values. Signed-off-by: David Brown <david.brown@linaro.org>
Allow the dt-rust.yaml file to specify a `static_type` value for device nodes. The generated code for the nodes will reserve a static value of that type, and pass it into the constructor. There is a NoStatic which is the default. As it is zero size, it will not cause any code to be generated for the types that do not need static. Fix the flash device to accept this argument, but the fix for gpio will come in a subsequent patch. Signed-off-by: David Brown <david.brown@linaro.org>
Implement a general async `wait_for_high` and `wait_for_low` to the GpioPin interface. The waiting is supported at the level of the gpio driver. Each Gpio instance has an array of `AtomiWaker` to hold the wakers that are waiting on the pins, as well as the callback handler from using the pins in interrupt mode in Zephyr. Although most of the examples of gpios in Zephyr use irq-gpios instead of gpios in the custom properties, there isn't anything that happens when this is done, and regular 'gpios' properties work just fine with interrupts. Signed-off-by: David Brown <david.brown@linaro.org>
This is a basic test to test for the waiting gpios. Currently, this test requires a specific hardware setup. To test on the rpi-pico, it is necessary to connect GPIO-0 to GPIO-6 with a button or switch. Running should then print Pressed/Released on a debounced version of that switch, with the code not polling the gpio while waiting. Signed-off-by: David Brown <david.brown@linaro.org>
Enable the async functionality so it will be included in the generated documentation. This also requires enabling an additional KConfig needed to be able to configure the state of interrupts on gpios. Signed-off-by: David Brown <david.brown@linaro.org>
cfriedt
approved these changes
Mar 7, 2025
teburd
approved these changes
Mar 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a cargo feature to the
zephyrcrateasync-drivers, which enables support for async driver calls. These are built around standard Rust async, and should work with any executor (except for the kio one which is non-standard).Currently, this adds
wait_for_highandwait_for_lowto the gpio driver (currently, only level triggering, not edge). The implementation both tries to avoid races as well as avoid excessive interrupts. However, as the Zephyr gpio API does not provide a way to read an individual interrupt status, this does require the IRQ to always fire. In the case where the pin is already at the desired level, the IRQ callback will happen between the enable, and the status check, which means the async task will not pend, but simply return, just with the overhead of an irq and the callback.There is a single callback per gpio controller.
This includes a new mechanism in the devicetree mapping that allows static data to be associated with each instance. Static data is needed as the callback and the state cannot be moved.