Support discovery packets (00 00 control bytes) in frame parsing#48
Merged
Conversation
Replace the all-or-nothing frame parser with a sliding-window resync: on a bad header checksum, control bytes, length, end byte, or data checksum the parser discards a single byte and retries, recovering valid frames from stutters, cross-device collisions, and line noise (issue marklynch#46). Framing logic moves into a dedicated, host-testable framing.c module; error accounting is reworked from message-error counters into per-type resync counters surfaced on the status page and tagged through the unknown-message buffer. Tests: golden-file harness seeded with the real captures from the issue, plus chunked-input cases (| splits one case into multiple add_bytes calls) and a chunk-invariance property sweep proving frame recovery is independent of how the byte stream is fragmented across reads.
The bus also sends a second, shorter frame shape: discovery packets with 0x00 0x00 in the control bytes (vs the usual 0x80 0x00 data packets). These are always exactly 11 bytes (header + END), with no payload and no separate data-checksum byte - byte 9 is purely the header checksum. Classify each frame's control bytes into FRAMING_PACKET_DATA, FRAMING_PACKET_DISCOVERY, or FRAMING_PACKET_INVALID via a shared framing_classify_packet() helper in framing.h/.c, then branch the minimum-length and data-checksum logic in framing.c on that enum instead of re-deriving control-byte state in multiple places. message_decoder.c reuses the same classification to pick its own minimum length and payload size, replacing a hardcoded len==11 check and an independent 12-byte minimum that had been silently dropping valid 11-byte discovery packets. Add synthetic framing test cases for the new packet type (and the negative case of the same shape with the wrong control bytes), and extend the chlorinator/heater/touchscreen replay samples with real captured discovery packets, which decode cleanly and fall through to the generic "Unhandled" logger since none of their CMD bytes have a registered handler yet.
Owner
|
Looks great. |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Note - Stacked on #47 (feat/sliding_window) — please merge that one first. This PR's diff currently includes #47's commit too; once #47 merges, it'll shrink down to just the new commit below.
Summary
0x00 0x00control bytes (vs the usual0x80 0x00data packets), exactly 11 bytes with no payload and no separate data-checksum byteframing_classify_packet()helper (FRAMING_PACKET_DATA/FRAMING_PACKET_DISCOVERY/FRAMING_PACKET_INVALID) used by bothframing.candmessage_decoder.c, replacing scattered length checks (including a stale hardcoded 12-byte minimum that silently dropped valid 11-byte discovery packets)00 00control byte parsing, it does not add any new cmd parsing.