Pin debouncer for buttons rather than gamepad debouncer + improved logic #857
Conversation
This file contains 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
a couple classes had their own debouncer or reference to the gamepad debouncer. this seemed inefficient and caused potential for incongruent behavior, thinking that instead we should just debounce the GPIO pins (for buttons). this does that. this doesn't yet clean up all the code (specifically the old debouncer) but it does get everything on the new debouncer. things appear to work as before, maybe they solve some debouncing problems for folks, work to be done
this fixes boot time shortcuts that were broken by my refactor
bsstephan
force-pushed
the
pin-debouncer
branch
from
f6136b7
to
4978e06
Compare
bsstephan
changed the title
the previous debouncer logic would try to only wait for the debounceDelay on button depresses, IIRC in an attempt to get the real button press immediately, but the more I look at it, the more I come to the same conclusion as Feral that such logic is flawed, and will register flapping switches because it's eagerly not debouncing them. with this change, button presses only register if it's been debounceDelay (default 5ms) since the last change. buttons will still register immediately as long as the delay has been met, so in practice this may only affect a latency tester and some kind of superhuman who mashes buttons at sub-5ms speeds. this applies Feral's logic (from the button debouncer) to the refactored pin debouncer. Co-authored-by: FeralAI <13342258+FeralAI@users.noreply.github.com>
Closed
bsstephan
changed the title
Merged
arntsonl
approved these changes
Feb 26, 2024
There was a problem hiding this comment.
Fantastic work, thank you @bsstephan . This is so much cleaner, one centralized place to handle our debouncing logic.
|
Ive tried this fw, and debouncing works fantastic, but on xbox mode X button wont respond, sometimes I got shutdown menu on my xbox. On oled screen it show that button is pressed. |
|
@strusic can you make an issue for that? I'll look into it, its probably something I didn't catch with the logic I'm using to do xbox one. https://github.com/OpenStickCommunity/GP2040-CE/issues |
|
@arntsonl done, as you requested. Looking forward to new pull that fix this ;) |
This pull request was closed.
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.
A couple classes had their own debouncer or reference to the gamepad debouncer. this seemed inefficient and caused potential for incongruent behavior, thinking that instead we should just debounce the GPIO pins (for buttons). this does that.
Meanwhile, Feral questioned the logic of our gamepad debouncer as of 0.7.6, which was a plausible explanation for reports of double inputs cropping up lately. Feral's bugfix has been incorporated into this refactor and we're reaching out to see if it addresses those issues.