Conversation
fnc_poll() reads one byte and then calls poll_extra(), which called wifi_poll() unconditionally in USE_WIFI builds. With the transport set to UART that is about 100,000 calls a second at 1 Mbaud, and the reader could not keep up. Over UART wifi_poll() only services OTA, so call it every 20 ms instead. WiFi and ESP-NOW keep the per-byte call, where it refills the receive buffer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reading one byte per uart_read_bytes() call capped the pendant at about 50 KB/s, while FluidNC sends at up to 100 KB/s at 1 Mbaud. The 256-byte receive buffer filled within milliseconds of a large transfer such as preferences.json, bytes were dropped mid-document, and the macro list came back empty or partial. The UART driver's own overflow events confirmed the loss. - Read up to 256 bytes per driver call and hand them out from a local buffer. - Enlarge the driver receive buffer to 16 KB, enough for a whole preferences.json while the loop is busy. - Let the main loop drain up to 1024 bytes per pass instead of 64. It still stops as soon as nothing is buffered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
On a wired M5Dial, large responses such as preferences.json lost bytes, so
the macro list was empty or incomplete. The UART driver's overflow events
confirmed it: the pendant read about 50 KB/s while FluidNC sent up to
100 KB/s at 1 Mbaud.
UART. It now runs every 20 ms there.
per byte, and enlarge the receive buffer to 16 KB.
Afterwards the driver reported no overflows over repeated preferences.json
transfers, and every macro loaded each time.