LPC8xx Stage 6: FastLED canary — Blink/DemoReel100/FxEngine compile for lpc845/lpc804 #550

Activity

1. fastled-project-sync

   added this to FastLED Trackeron Jun 13, 2026
2. fastled-project-sync

   moved this to Triage in FastLED Trackeron Jun 14, 2026
3. zackees commented on Jun 15, 2026

   

   zackees

   on Jun 15, 2026

   MemberAuthor

   More actions

   /clud-fix investigation report — scope is structurally ambiguous

   /clud-fix was invoked on this issue from the meta #586 burn-down. Stopping at the intake gate because the acceptance criterion ("fbuild build of Blink / DemoReel100 / FxEngine links clean for lpc845 + lpc804") can be satisfied two structurally different ways, and the right call needs your decision rather than a guess. No PR opened in this run.

   What's actually shipped right now

   • ✅ Items 1 + 2 of the acceptance (upstream zackees/ArduinoCore-LPC8xx register-level GPIO + FastLED LPC8xx platform shim) — both shipped per meta [META] LPC845-BRK on-hand burn-down: cover the open LPC8xx work end-to-end #586's audit comment. Confirmed at src/platforms/arm/is_arm.h:17 (#include "lpc/is_lpc.h").
   • ✅ fbuild's existing tests/platform/lpc845/ fixture — lpc845.ino is a plain Arduino HAL Blink (no <FastLED.h> include); compiles green today. Matches the structural pattern of every other tests/platform/<board>/<board>.ino fixture in this repo (teensy41, attiny85, etc. — Arduino HAL only).
   • ✅ FastLED-side LPC canary CI — FastLED/FastLED#3080 just merged (2026-06-15 17:30 UTC), wiring pip install fbuild && fbuild build . -e <variant> for all 5 LPC variants against the Blink example. So Blink-via-fbuild on LPC8xx is now exercised in FastLED's own CI.

   Why the remaining work is ambiguous

   Item 3 of the acceptance ("Blink / DemoReel100 / FxEngine link clean") can mean either:

   Option A — lightweight: extend FastLED-side CI matrix.
   Edit my #3080 workflow files (.github/workflows/build_lpc{804,845,...}.yml) from args: <variant> Blink to args: <variant> Blink DemoReel100 FxEngine. ~5 files × 1 line each. Validation is "CI green on FastLED master." Risk: DemoReel100 / FxEngine flash usage may overflow the 64 KB LPC8xx budget — that becomes a FastLED bug to chase down (palette tables / EngineEvents / gamma LUT bloat), not a CI wiring issue.

   Option B — heavy: build a FastLED-dependency fixture in fbuild.
   The existing tests/platform/<board>/ model is Arduino-HAL-only. Pulling FastLED in as a test-time dependency means either (i) adding libs/FastLED/ to each new fixture dir following the tests/platform/lpc845_build_flags/libs/ precedent and pinning a FastLED commit, or (ii) extending fbuild's test infrastructure to fetch a remote library. Either way, ~3 new fixture dirs per board × 2 boards = ~6 new fixtures + matching build-*.yml workflow files. Validation is "fbuild's CI green on main."

   Option A is dramatically simpler and tests the same compile-link gate the issue body cares about. Option B is the literal reading of "fbuild build" — but stretches fbuild's test-fixture model beyond what it currently supports.

   Recommendation

   Option A. The "fbuild build" wording in #550 reflects that the issue was filed before #3080 existed — at the time, no FastLED-side CI exercised the fbuild stack on LPC at all, so "validate via fbuild build" defaulted to fbuild's own CI. Now that #3080 is wired, FastLED's CI runs fbuild build . -e <variant> against FastLED's examples directly — that's the validation surface the issue actually wants, just on the FastLED side. Extending the matrix to three examples (Blink / DemoReel100 / FxEngine) closes the structural gap with ~5 lines of YAML and gives the issue a clean validation path.

   The 64 KB flash margin concern is real on lpc804 (4 KB SRAM / 32 KB flash) and may bite either DemoReel100 or FxEngine. If that happens we get a clean signal (linker overflow with a specific size delta) that the next round can address — exactly the kind of falsifiable check that makes /clud-fix's validation step useful.

   Open questions for you

   1. Option A or Option B? (My vote: A.)
   2. If A: should I also lift the args: <variant> all pattern that build_attiny85.yml / build_apollo3_red.yml use? Or hold at the explicit 3-example list to match LPC8xx Stage 6: FastLED canary — Blink/DemoReel100/FxEngine compile for lpc845/lpc804 #550's wording?
   3. If a specific example overflows the LPC8xx flash budget, do you want a CI carve-out (skip that example on that variant) or a FastLED-side flash-reduction follow-up?

   Re-invoke /clud-fix https://github.com/FastLED/fbuild/issues/550 after you've picked an option and I'll execute against the chosen direction.

   Filed via Claude Code — /clud-fix skill intake-gate report.
4. zackees

   closed this as completedin FastLED#3091on Jun 15, 2026
5. pull

   added a commit that references this issue on Jun 15, 2026

   ci(lpc8xx): extend canary to Blink + DemoReel100 + FxEngine (closes f…

   ...

   This issue will close once commit 8d7af6d is merged into the 'master' branch.

   8d7af6d