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

[zackees]

Split out of META #487 (Stage 6) so the umbrella can close once the build + framework + CI staircase is in.

Goal

Blink, DemoReel100, and FxEngine compile clean for both lpc845 and lpc804 via fbuild build.

Why it's not done yet

The fbuild side compiles + links a real Arduino Blink against the bundled in-tree arduino_stub core today (verified in #479 / PR #549: pinMode/digitalWrite link as no-ops, delay is real SysTick). FastLED's example sketches additionally need real register-level GPIO + SPI from zackees/ArduinoCore-LPC8xx, whose cores/lpc8xx/ bodies are still TODO stubs (see #487 Stage 1 notes). Until that core lands real implementations — and a FastLED LPC8xx platform shim exists — DemoReel100/FxEngine can't link.

Acceptance

• zackees/ArduinoCore-LPC8xx wiring_digital/wiring_analog/SPI implemented against MCUXpresso SDK
• FastLED LPC8xx platform shim (clockless/SPI output)
• fbuild build of Blink / DemoReel100 / FxEngine links clean for lpc845 + lpc804

Tracking: #487

[zackees]

/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.