max_packet_size was a default with a setter that code generation called
after construction, so it could be raised above the size of a link's
buffer. It is now a constructor parameter, and a link with a fixed buffer
takes the buffer as a std::span, so its size is the link's limit and the
two cannot differ.
Co-Authored-By: Claude Code <noreply@anthropic.com>
The receive buffer is sized by code generation to max_packet_size, but
set_max_packet_size() can raise the limit afterwards, and the received
bytes would then overflow the buffer. The link now takes the buffer as a
span and stops at its size too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It allocated a vector for each call, which invites heap churn. Only the
tests used it; they now have a local helper.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Code generation declares the UART link's receive buffer as a static
array of max_packet_size bytes, so it is not allocated at run time
- Move the increment out of the condition in note_received_()
- Initialise the UART transmit copy buffer
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A packet interface moves packets over a channel, with a uart link and a
packet_transport platform that uses any packet interface. Later layers
stack on the same base class.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
