-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for interrupts in addition to current polling for GPIO input #4
Comments
Thanks for the suggestion, and the link. I agree that adding support for GPIO interrupts would be nice to have. I've briefly looked into adding interrupts before, but only came across sysfs-based solutions. While I do have direct access to the relevant registers (GPEDSn), there doesn't seem to be a way to specify an ISR vector table, and polling the registers ends up causing the same issue you pointed out. Regardless, it's still worth it to use the sysfs interface just for interrupts, and I'll add it to the to do list. I'm open to suggestions for a better solution though. |
Perhaps you could use epoll. https://github.com/rust-embedded/rust-sysfs-gpio/blob/master/src/lib.rs#L554 |
Yeah, using epoll to wait for sysfs changes is the plan. I would prefer more direct access though, but that doesn't currently seem possible in userspace. |
Both synchronous and asynchronous interrupts have been added, and will be available as part of the upcoming 0.5.0 release. |
Do you have plans to support level-triggered interrupts? As far as I can tell, only edge triggered is supported. |
@braincore the interrupt code in the version of rppal currently in development uses the new /dev/gpiochipN interface through epoll, rather than the outdated sysfs interface used in previous versions. Since I don't specifically set the The BCM283x registers do have options to configure either level- or edge-triggered interrupts, but it's possible the userspace drivers don't support those. I'll look into what the drivers offer, and if it would make sense to build a level-triggered option in software instead. |
To handle signals on GPIO pins, a function to add a callback to a GPIO pin state is needed.
Polling can miss events and is possibly CPU intensive.
https://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/ has a discussion on the difference and explanation of Python functions to monitor GPIO inputs.
The text was updated successfully, but these errors were encountered: