Communication protocols as contracts
Frame and validate messages while separating electrical signaling, byte transport, and application meaning for easier fault isolation.
- Design and trace a bounded message frame with addressing, length, error detection, timeout, and a documented retry policy.
Related study — optional context
Understand
The working idea
Devices communicate only when several agreements line up. The wire-level layer defines voltage, timing, and who may drive. A transport convention groups bits into bytes. An application protocol says that a particular byte means temperature, motor command, or error. Separating these layers helps diagnosis: clean electrical edges do not prove that two devices agree about byte order or units.
UART sends framed bytes asynchronously using an agreed baud rate. I²C shares clock and data among addressed devices and uses open-drain lines with pull-ups. SPI commonly uses a clock, two data directions, and a chip-select per target. Names alone do not guarantee voltage compatibility, pin assignment, mode, speed, or connector orientation. For an I²C sensor cable, choosing pull-up resistance involves bus capacitance and device sink current; blindly adding multiple breakout-board pull-ups can make the combined resistance too low.
At the message layer, a bounded frame might contain sync, version, type, length, payload, and checksum. If payload length is L, the receiver must reject L above its allocated capacity before copying. A simple sum checksum detects some corruption but not all; stronger CRCs provide specified detection properties. Timeout and retry rules must consider whether repeating a command is safe. “Set speed to 40%” is idempotent; “advance 10 mm” may execute twice unless it carries a sequence number and duplicate handling.
A common misconception is that a checksum provides security or proves semantic correctness. It only detects a class of accidental changes; a perfectly checksummed command can still use the wrong units. Another failure is endlessly waiting for a missing byte, freezing the robot. The build decision is to cap frame length, set a timeout based on baud and maximum frame size, and expose distinct errors—timeout, invalid length, checksum, unsupported version—so fault isolation is possible.
Follow the reasoning
Worked example
A UART link runs at 115,200 bit/s using 8 data bits, one start bit, and one stop bit. Estimate transmission time for a 32-byte frame and choose a timeout with 3× margin.
- 1
Each byte occupies 10 transmitted bits, so the frame uses 32 × 10 = 320 bits.
- 2
Ideal wire time = 320 / 115,200 s = 0.00278 s = 2.78 ms.
- 3
A 3× wire-time margin gives 8.33 ms; choose a practical 9 ms or larger value after accounting for sender scheduling.
The ideal wire time is about 2.78 ms; a starting receive timeout of 9 ms supplies slightly more than 3× margin, subject to system scheduling tests.
Sanity checkAt roughly 11,520 bytes/s, 32 bytes should take about 32/11,520 s, which is the same 2.78 ms.
Try it yourself
Independent check
Move to the bench
Implement a small serial frame parser and diagnose truncation, corruption, and duplicate commands from captured bytes.
- Microcontroller and USB serial link or two logic-level boards
- serial terminal
- jumper wires if using two boards
- logic analyzer optional
Experiment
- Define a frame with version, sequence, type, length up to 16, payload, and an explicitly named checksum algorithm.
- Write the receiver as a state machine with a bounded buffer and timeout; log accepted sequence numbers and error categories.
- Send one valid idempotent LED-duty command and confirm its acknowledgement.
- Introduce deliberate faults one at a time: wrong checksum, declared length 17, and a truncated frame; verify distinct rejection paths.
- Repeat the valid frame with the same sequence number and verify it is acknowledged but not applied twice.
Observe
- Expected: valid frames change the test output once; corrupt, oversized, or incomplete frames do not change it.
- Record actual transmitted hex bytes, receiver log, and elapsed timeout; expected acceptance is not evidence of receipt.
- Expected fault signatures are checksum error, length error, and timeout respectively, rather than one generic failure.
Write the layer-by-layer checks for a screen module that powers up but shows no sensor values: voltage/ground, bus pins and pull-ups, address, frame fields, then units.
- Confirm both boards use compatible logic voltage and a common ground before wiring; never connect RS-232, automotive, or appliance-level signals directly.
Keep evidence
Bench note
Record what you expected, what you actually measured or observed, and one difference worth investigating. This is self-reported evidence, not a certification.