fix(USBSerial): bump per-line capture buffer 128 → 512 bytes - #5307
Open
packerlschupfer wants to merge 1 commit into
Open
fix(USBSerial): bump per-line capture buffer 128 → 512 bytes#5307packerlschupfer wants to merge 1 commit into
packerlschupfer wants to merge 1 commit into
Conversation
packerlschupfer
added a commit
to packerlschupfer/Prusa-Firmware-Buddy
that referenced
this pull request
Jun 1, 2026
GCODE_LOG_LINE_LEN was capping every notify_gcode_response line at 95 chars. Long Marlin output (M115 banner, M118 echoes, multi-field state dumps) was being silently truncated before reaching Fluidd's console. Ring footprint grows from 16 * 96 = 1.5 KB to 16 * 256 = 4 KB static. The per-frame WS render path already bounds payload against MAX_FRAME_PAYLOAD, so larger entries just mean fewer per frame, not overflow. entry.len is uint8_t and copy_len caps at GCODE_LOG_LINE_LEN-1 = 255, so the byte count still fits. Note: this fixes the ring-buffer ceiling but does not address the upstream USBSerial 128-byte lineBuffer cap (lib/Arduino_Core_Buddy/.../ USBSerial.cpp), which silently drops everything past 125 chars before the next newline. The M115 FIRMWARE_NAME banner (~235 chars) is still lost there. That cap is what pr/usbserial-bigger-linebuf (upstream PR prusa3d#5307) raises to 512.
packerlschupfer
added a commit
to packerlschupfer/Prusa-Firmware-Buddy
that referenced
this pull request
Jun 1, 2026
GCODE_LOG_LINE_LEN was capping every notify_gcode_response line at 95 chars. Long Marlin output (M115 banner, M118 echoes, multi-field state dumps) was being silently truncated before reaching Fluidd's console. Ring footprint grows from 16 * 96 = 1.5 KB to 16 * 256 = 4 KB static. The per-frame WS render path already bounds payload against MAX_FRAME_PAYLOAD, so larger entries just mean fewer per frame, not overflow. entry.len is uint8_t and copy_len caps at GCODE_LOG_LINE_LEN-1 = 255, so the byte count still fits. Note: this fixes the ring-buffer ceiling but does not address the upstream USBSerial 128-byte lineBuffer cap (lib/Arduino_Core_Buddy/.../ USBSerial.cpp), which silently drops everything past 125 chars before the next newline. The M115 FIRMWARE_NAME banner (~235 chars) is still lost there. That cap is what pr/usbserial-bigger-linebuf (upstream PR prusa3d#5307) raises to 512.
The USBSerial class buffers each line written to USB CDC and (when set) hands it to a lineBufferHook callback once the newline arrives. The buffer was 128 bytes; any line longer than 125 chars got truncated by LineBufferAppend() with ".." appended in place of the rest, with no way for the hook consumer to recover the rest of the line. 128 B is below several common Marlin response lines: - M115 FIRMWARE_NAME line: ~240 chars on most printers (FIRMWARE_NAME + version + URL + PROTOCOL_VERSION + MACHINE_TYPE + EXTRUDER_COUNT + UUID, all concatenated). - M503 settings dumps: many lines, several over 100. - M118 user-emitted messages: no documented length cap. The truncated output is misleading because the user can see *part* of the answer they wanted (e.g. the FIRMWARE_NAME prefix in M115) but the trailing bytes — including the UUID, which support cases sometimes need — disappear. Bump to 512 B. The ".." truncation marker still triggers for the rare line that's longer, so the behaviour degrades gracefully; only the threshold moves up. Static cost is one extra 384-byte buffer (single global USBSerial instance) — negligible vs the 196 KB total RAM on the xBuddy STM32F427. The truncation logic itself was already parametrised on lineBuffer.size() in USBSerial.cpp, so no code change there.
packerlschupfer
force-pushed
the
pr/usbserial-bigger-linebuf
branch
from
July 26, 2026 19:45
3904a3f to
d991f57
Compare
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
1 participant
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.
Summary
USBSerial::lineBufferis the per-line capture buffer fed tolineBufferHookcallbacks (e.g. when WUI's/api/v1/logsnapshots Marlin serial output). Its size was 128 bytes; any line longer than 125 chars was truncated mid-content with..appended.This is below several common Marlin responses:
M115FIRMWARE_NAME line — concatenatesFIRMWARE_NAME, version, source URL,PROTOCOL_VERSION,MACHINE_TYPE,EXTRUDER_COUNT, andUUID. ~240 chars on most printers. UUID (the last field) is silently dropped — support cases sometimes need it.M503settings dumps — many lines over 100 chars.M118user-emitted messages — no documented length cap.Bump to 512 bytes. Trade-off is one extra ~384-byte static buffer (single global
USBSerialinstance) on a 196 KB-RAM xBuddy MCU. The..truncation marker still triggers if a line exceeds the new size, so degradation is graceful — only the threshold moves up.The truncation logic in
LineBufferAppend()already useslineBuffer.size(), so no code change there.Test plan
M115over USB serial shows the full line (including UUID)./api/v1/login our fork) emits the full line without...Related
Hit while debugging
/api/v1/login a downstream fork — the captured M115 output was missing the UUID and Cap: lines were partially garbled. Fixing the buffer size at the root is cleaner than working around it in every hook consumer.