Reuse of EEPROM debounce logic #14699
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
zvecr
changed the title
drashna
approved these changes
Oct 5, 2021
fauxpark
approved these changes
Oct 5, 2021
|
Looks like this broke via, because it calls rgblight's version, which is mapped to rgb matrix, for compatibility. |
14 tasks
ptrxyz
pushed a commit
to ptrxyz/qmk_firmware
that referenced
this pull request
Apr 9, 2022
* reuse rgb debounce logic * Refactor led matrix * Remove log line * timeout should not be hard coded
BorisTestov
pushed a commit
to BorisTestov/qmk_firmware
that referenced
this pull request
May 23, 2024
* reuse rgb debounce logic * Refactor led matrix * Remove log line * timeout should not be hard coded
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.
Description
Partially borrowed from RGB Matrix, the idea is to provide debounce of arbitrary sections of EEPROM.
Ideally the process would be completely transparent, but minimising the RAM/execution overhead is tricky. For example, with STM eeprom emulation you would end up with a write log on top of a write log. Implementing linked lists/maps, to store only the most recent changes burns extra cycles to get the latest value. The RGB Matrix tracks the changes of its own block of data, with a periodic write. This has been generalised a little with some gross macros, but should help with some consistency in behaviour.
For some additional context, this is some WIP of the additional use case -18ee1f5.
Types of Changes
Checklist