improve STOP/START handling #20
Open
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
Closed
|
Thanks! I'll want to test this one against a GD32 Model 100 before merge. |
Respond immediately when we get a STOP or repeated START while still selected. Otherwise, a START condition immediately preceded by a STOP could be missed. This probably will result in more clock stretching, but the ATmega firmware doesn't seem to handle retries, so it probably implicitly depends on the keyscanner doing clock stretching anyway. Anyway, the ATmega firmware seems to only issue STOPs when reading, so it's probably not too important in practice. (I only noticed when trying to do back-to-back LED commands that ended in STOPs.) Signed-off-by: Taylor Yu <[email protected]>
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.
Respond immediately when we get a STOP or repeated START while
still selected. Otherwise, a START condition immediately
preceded by a STOP could be missed.
This probably will result in more clock stretching, but the
ATmega firmware doesn't seem to handle retries, so it probably
implicitly depends on the keyscanner doing clock stretching anyway.
Anyway, the ATmega firmware seems to only issue STOPs when reading,
so it's probably not too important in practice. (I only noticed when
trying to do back-to-back LED commands that ended in STOPs.)
Signed-off-by: Taylor Yu [email protected]