aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorSelene ToyKeeper2020-09-14 02:48:34 -0600
committerSelene ToyKeeper2020-09-14 02:48:34 -0600
commit46db889558b953d5a8831c7912bfff4570ae9305 (patch)
treeb8ee1f10e58a2472dd00a9f37e770a6cb1c3b8f9 /README
parentfixed bug: ramp 2H at floor went up instead of staying at floor (diff)
downloadanduril-46db889558b953d5a8831c7912bfff4570ae9305.tar.gz
anduril-46db889558b953d5a8831c7912bfff4570ae9305.tar.bz2
anduril-46db889558b953d5a8831c7912bfff4570ae9305.zip
fixed bug: ticks_since_last_event wasn't getting reset on button hold release
The visible symptom was: Ramp up for 1s or longer, release, wait more than 1s, then hold again. It should ramp up, but it would ramp down instead. The clause for resetting ramp_direction wasn't happening, because the EV_tick counter started at a value higher than 1s where it would normally trigger. The underlying cause was a bit complicated. Recent changes in PCINT_inner() were causing ticks_since_last_event to get set to 0 (at push_event()) and then back to its previous value (at emit_current_event()). The EV_tick counter would then start at whatever the button release event used. The fix involved removing the part of emit_current_event() where it would set ticks_since_last_event to "arg". That line was a very old bug which simply hadn't caused any visible issues until recently. Instead, it needs to set ticks_since_last_event more carefully, at other locations. Specifically, it resets to 0 now in empty_event_sequence() and one more location in the deferred WDT handler (when HOLD_TIMEOUT triggers). Additionally, push_event() was only ever used from PCINT_inner()... so I moved the tick reset logic to PCINT_inner() instead. This allows us to decrease size by about 10 bytes, since PCINT_inner() no longer needs to copy the counter before it gets reset. However, it also means push_event() should never be called from any other function.
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions
If you find this content useful please consider a small donation via bitcoin: bitcoin:1mxKyQsHHugqRxPKgwaA7wUwJEGCNthn2?amount=0.001&message=Donation Scraping git contents via cgit is very resource intensive. The continued hosting of these git repositories is entirely financed by your bitcoin contributions. For donations of a least 1 mBTC you include your IP address in the message of your bitcoin donation. This will remove this message in the future for requests from your IP, which will significantly reduce token usage. In any case, any contributions to bitcoin address 1mxKyQsHHugqRxPKgwaA7wUwJEGCNthn2 are very welcome. Thanks in advance for you contribution to a self-sustaining ecosystem.