This repository was archived by the owner on Jan 28, 2021. It is now read-only.
Better packet validity checking #89
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This merge is a big one!
It addresses Issue #85 where the fault was manifesting as CRC failures when using Serial.
The underlying problem was actually caused by the slow arrival rate of serial bytes.
It was possible for a received packet to appear valid (with the expected class and ID) before the end of the message had actually been received. The CRC did of course fail as not all of the bytes had been received.
This would not have been seen on I2C / Qwiic because there the whole message appears in the module's buffer at the same instant and the complete message can be read all in one go.
The solution involves defining three states for the packet validity: VALID (the whole message has been received and the checksum is OK); NOT_VALID (the whole message has been received and the checksum has actually failed - which should be extremely rare!); NOT_DEFINED (we have not yet reached the end of the message and cannot yet check the checksum).
This has been checked using:
The standard examples have been tested successfully on all sets of hardware.
Confidence is high!
Enjoy!
Paul