You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix fbuild, then Teensy through auto research then the rest. there are a lot of FL_WARN, you need to audit and remove as much as possilbe in auto research, collate failures into terse information to live in teensy's small tx buffer.
Status notes (2026-06-22 loop session — checkpoint 2)
Progress made on the cross-repo follow-ups since the meta was opened:
✅ AutoResearch FL_WARN audit — landed in FastLED PR #3342 (loop/3219-autoresearch-warn-audit). Three changes in examples/AutoResearch/AutoResearchTest.cpp: per-byte capture dump 26 lines → 1, dumpRawEdgeTiming() body N lines → 1 collated, decode-failure raw-edge dumps EdgeRange(0, 256) → EdgeRange(0, 32). ~10x reduction in device-side serial-line volume per test.
✅ Wrapper-side RPC send counter — same PR. RpcClient._sent_count increments on every send() / send_and_match() attempt; printed on verbose close.
✅ FlexIO RX wait() honest TIMEOUT on empty-buffer SUCCESS — same PR. Was returning SUCCESS even when transfers_done == 0. Now reclassifies that path as TIMEOUT. Also collapsed ~3 verbose register-dump FL_WARN_Fs per wait into 1 collated line.
✅ DriverNotRegistered enumerates registered drivers — same PR. When runSingleTest is invoked with a driver that isn't enrolled (e.g. --lpuart against Teensy 4 where the engine isn't yet implemented), the error now lists what IS available instead of returning generic "DriverSetupFailed".
✅ --spi wrapper-skip wording — already removed by the PR #3341 wrapper-skip elimination; no separate action needed.
⚠ 100-LED jitter — originally labeled "not solvable from software". That framing was wrong and has been corrected. Filed as FastLED #3343 with explicit "re-measure 10x against post-#3342 firmware BEFORE any bench-only conclusion stands" acceptance criteria.
⏳ LPUART driver actual implementation — multi-day work (FastLED #3157 engine + #3182 ISR streaming). Out of loop scope.
PR #750 (closes #749) refactored crates/fbuild-daemon/src/handlers/websockets.rs::handle_serial_ws() from a single tokio::select! loop into three concurrent tasks (reader, writer, inbound). That eliminated the per-line WS-frame backpressure that caused the daemon to silently drop serial lines on bursty TX, and unblocked the FastLED #3219 wrapper-response-miss.
The fix shipped clean but deliberately deferred three categories of follow-up work:
Lost protocol semantics — ClearBuffer and GetInWaiting used to reach into the broadcast receiver from the inbound handler. Post-split, inbound and reader are different tasks and those calls became logged no-ops.
Test coverage — the split topology has no unit or integration tests. Reviewer feedback (and project-internal best practice) wants both.
Cross-repo follow-ups discovered during the FastLED #3219 session
These were identified while working through the wrapper-response-miss investigation. Most live in FastLED (sketch, library, wrapper) rather than fbuild — they should be split into FastLED issues but are noted here so the cross-repo dependency chain stays visible. Each is independently actionable.
FastLED follow-ups
(FastLED #3342) Sketch-side [CORRUPTION @ LED X] verbosity — landed in PR #3342. Per-byte dump 26 lines → 1 collated; dumpRawEdgeTiming() N lines → 1; decode-failure dumps 256 edges → 32. ~10x reduction in serial-line volume per OBJECT_FLED test.
(FastLED #3343) 100-LED jitter at the ~5% level — needs FULL re-investigation post-#3342. After PR #3341 fixed the wrapper/decoder/RX cheats, 100-LED OBJECT_FLED tests still corrupted 1-8 of 100 LEDs per run randomly. Originally labeled "bench-level / not software-solvable" — that was wrong. Device-side FL_WARN blocks on a full UART TX FIFO, which starves ObjectFLED's TX-DMA refill and stretches pulse widths past the midpoint classifier boundary. PR #3342 cut device-side FL_WARN volume ~10x, so this may already be fixed or substantially reduced. Re-measure 100-LED autoresearch 10x against post-#3342 firmware before any "bench-only" conclusion stands. Filed as [teensy4] OBJECT_FLED 100-LED autoresearch: ~5% jitter — re-investigate post-#3342 FL_WARN audit FastLED#3343.
(FastLED #3342) LPUART driver not exposed via AutoResearch on Teensy 4 — diagnostic improved. PR #3342 enumerates registered drivers in the DriverNotRegistered error when an unimplemented driver is requested. The actual LPUART engine implementation is FastLED #3157 / #3182 — multi-day work, out of loop scope. The diagnostic improvement keeps users from chasing generic-error wild geese.
(FastLED #3342) FlexIO RX wait() always returns SUCCESS — landed in PR #3342. Now returns TIMEOUT when transfers_done == 0 (DMA-complete-with-empty-buffer case documented in #3066 iter 4). Also collapsed 3 verbose register-dump FL_WARN_Fs per wait into 1 collated line. FlexIO RX is still documented dead-end (#3066 iter 9) but the cheat in its wait() is fixed for consistency with FlexPWM.
(FastLED) --spi on Teensy currently wrapper-skipped with a misleading reason — already removed by the PR #3341 wrapper-skip elimination; no separate action needed.
Do not add the deferred work as one mega-PR. Each sub-issue is its own focused review surface.
Do not open FastLED-scoped items as fbuild sub-issues — they're noted in the "cross-repo follow-ups" section above for visibility only. Convert each to its own FastLED issue before working on it.
Do not declare a software-domain bug "bench-only" before re-testing against the latest firmware. The 100-LED jitter case (#3343) is a concrete example: we labeled it "not solvable from software" while still in the same session that cut the device-side FL_WARN volume by 10x. Re-test first.
Fix fbuild, then Teensy through auto research then the rest. there are a lot of FL_WARN, you need to audit and remove as much as possilbe in auto research, collate failures into terse information to live in teensy's small tx buffer.
Status notes (2026-06-22 loop session — checkpoint 2)
Progress made on the cross-repo follow-ups since the meta was opened:
loop/3219-autoresearch-warn-audit). Three changes inexamples/AutoResearch/AutoResearchTest.cpp: per-byte capture dump 26 lines → 1,dumpRawEdgeTiming()body N lines → 1 collated, decode-failure raw-edge dumpsEdgeRange(0, 256)→EdgeRange(0, 32). ~10x reduction in device-side serial-line volume per test.RpcClient._sent_countincrements on everysend()/send_and_match()attempt; printed on verbose close.wait()honest TIMEOUT on empty-buffer SUCCESS — same PR. Was returning SUCCESS even whentransfers_done == 0. Now reclassifies that path as TIMEOUT. Also collapsed ~3 verbose register-dump FL_WARN_Fs per wait into 1 collated line.runSingleTestis invoked with a driver that isn't enrolled (e.g.--lpuartagainst Teensy 4 where the engine isn't yet implemented), the error now lists what IS available instead of returning generic "DriverSetupFailed".--spiwrapper-skip wording — already removed by the PR #3341 wrapper-skip elimination; no separate action needed.ClearBufferandGetInWaitingsemantics restored via internal control mpsc + oneshot reply between inbound and reader tasks. No protocol change. Will ship in next fbuild release.Background
PR #750 (closes #749) refactored
crates/fbuild-daemon/src/handlers/websockets.rs::handle_serial_ws()from a singletokio::select!loop into three concurrent tasks (reader, writer, inbound). That eliminated the per-line WS-frame backpressure that caused the daemon to silently drop serial lines on bursty TX, and unblocked the FastLED #3219 wrapper-response-miss.The fix shipped clean but deliberately deferred three categories of follow-up work:
ClearBufferandGetInWaitingused to reach into the broadcast receiver from the inbound handler. Post-split, inbound and reader are different tasks and those calls became logged no-ops.This meta tracks all three. Sub-issues are scoped so each can land as its own focused PR.
Sub-issues (fbuild)
ClearBuffer+GetInWaitingsemantics. Merged as PR feat(serial): ReaderControl restores ClearBuffer + GetInWaiting (closes #756) #761.handle_serial_wsreader/writer/inbound topology. Covers per-task contracts, bursty-traffic coalescing, non-Data event ordering, clean shutdown, andRecvError::Laggedhandling. Includes a 320-line burst integration test that regression-guards the original perf(serial): per-line WebSocket messages drop lines under sustained TX bursts #749 bug.Suggested merge order
chore: address rustfmt + CodeRabbit review debt from PR #750 admin-merge #758 first— partially done via PR fix(ci): cargo fmt + split 4 .rs files under 1000 LOC #752.feat(serial): ReaderControl channel to restore ClearBuffer + GetInWaiting #756 next— DONE via PR feat(serial): ReaderControl restores ClearBuffer + GetInWaiting (closes #756) #761.Cross-repo follow-ups discovered during the FastLED #3219 session
These were identified while working through the wrapper-response-miss investigation. Most live in FastLED (sketch, library, wrapper) rather than fbuild — they should be split into FastLED issues but are noted here so the cross-repo dependency chain stays visible. Each is independently actionable.
FastLED follow-ups
(FastLED #3342) Sketch-side
[CORRUPTION @ LED X]verbosity — landed in PR #3342. Per-byte dump 26 lines → 1 collated;dumpRawEdgeTiming()N lines → 1; decode-failure dumps 256 edges → 32. ~10x reduction in serial-line volume per OBJECT_FLED test.(FastLED #3343) 100-LED jitter at the ~5% level — needs FULL re-investigation post-#3342. After PR #3341 fixed the wrapper/decoder/RX cheats, 100-LED OBJECT_FLED tests still corrupted 1-8 of 100 LEDs per run randomly. Originally labeled "bench-level / not software-solvable" — that was wrong. Device-side FL_WARN blocks on a full UART TX FIFO, which starves ObjectFLED's TX-DMA refill and stretches pulse widths past the midpoint classifier boundary. PR #3342 cut device-side FL_WARN volume ~10x, so this may already be fixed or substantially reduced. Re-measure 100-LED autoresearch 10x against post-#3342 firmware before any "bench-only" conclusion stands. Filed as [teensy4] OBJECT_FLED 100-LED autoresearch: ~5% jitter — re-investigate post-#3342 FL_WARN audit FastLED#3343.
(FastLED #3342) LPUART driver not exposed via AutoResearch on Teensy 4 — diagnostic improved. PR #3342 enumerates registered drivers in the
DriverNotRegisterederror when an unimplemented driver is requested. The actual LPUART engine implementation is FastLED #3157 / #3182 — multi-day work, out of loop scope. The diagnostic improvement keeps users from chasing generic-error wild geese.(FastLED #3342) FlexIO RX
wait()always returnsSUCCESS— landed in PR #3342. Now returns TIMEOUT whentransfers_done == 0(DMA-complete-with-empty-buffer case documented in #3066 iter 4). Also collapsed 3 verbose register-dump FL_WARN_Fs per wait into 1 collated line. FlexIO RX is still documented dead-end (#3066 iter 9) but the cheat in itswait()is fixed for consistency with FlexPWM.(FastLED)
--spion Teensy currently wrapper-skipped with a misleading reason — already removed by the PR #3341 wrapper-skip elimination; no separate action needed.fbuild follow-ups (now landed)
Anti-goals
Cross-links