meta: CH32V003 bring-up — fbuild hardware validation + FastLED platform port

[zackees]

Goal

Get a WCH CH32V003 driving WS2812s under FastLED, built and flashed by fbuild. Hardware is on the bench. This is the tracking issue; all work happens in the two children.

Children

#	Repo	Scope	Blocked by
#1208	fbuild	Validate the existing CH32V pipeline on real silicon; close hardware-visible gaps	—
FastLED/FastLED#3755	FastLED	src/platforms/wch/ platform port (detection, fastpin, clockless, CI)	Phase 2 needs #1208

Target

CH32V003F4P6 — RV32EC @ 48 MHz, 16 KB flash / 2 KB SRAM, no hardware multiply, 16 registers (ilp32e), single-wire debug (SWIO), no USB peripheral. Programmer: WCH-LinkE (1A86:8010 RV mode). wchisp is not usable — V003 has no factory USB-ISP bootloader.

State of play

fbuild is ~90% done but 0% proven. Toolchain (xPack riscv-none-elf-gcc 14.2.0-3), orchestrator, 17 CH32 board JSONs, wlink deployer, and green CI all landed across #1102–#1130. None of it has ever executed on silicon — it is entirely compile-verified. #1208 is validation, not implementation.

FastLED has nothing. No src/platforms/wch/. The only artifact is ci/boards/package_ch32v_index.json (commit 5cf16c9157, 2025-10-24) — a board-manager index snapshot, never wired to anything. #3755 is a from-scratch port.

Critical path

#1208 Phase 0  probe enumerates            ── hardware gate
#1208 Phase 1  build → .bin under 16 KB
#1208 Phase 2  flash → measured blink      ── BRING-UP MILESTONE
      │
      ├─ #3755 Phase 0  multiply-free feasibility spike  (can start now, no HW)
      ├─ #3755 Phase 1  platform skeleton, GPIO toggle
      └─ #3755 Phase 2  clockless driver → WS2812 on a scope   ── needs #1208 P2
         #3755 Phase 3  CI integration

#3755 Phase 0 and #1208 Phase 0/1 are independent — run them in parallel.

Risks

1. No hardware multiply is the project risk. scale8, nscale8x3, hsv2rgb_rainbow all become libgcc softmul calls inside a 16 KB budget. #3755 Phase 0 measures this before any platform code is written. If it doesn't fit, the port needs multiply-free variants and the plan changes shape.
2. 2 KB SRAM is below every supported FastLED part. The tiny memory class is documented <=1KB and holds the ATtinys; 16 KB flash is smaller than anything in the tree. Tiering in sketch_macros.h and ci/boards.py needs extending.
3. Toolchain split-brain. fbuild uses xPack GCC 14 + -march=rv32ec_zicsr; FastLED's ci/boards.py assumes framework="arduino", which pulls PlatformIO's GCC 8.2.0 + rv32ecxw (WCH's proprietary extension). Same chip, two toolchains, two CI paths. Unresolved — tracked in #3755.
4. __riscv gates assume ESP-IDF. FastLED treats RISC-V as a sub-branch of ESP. This bit us in #2576/#2577 (fast_isr.S re-gated on __riscv_atomic because C3 lacks A). RV32EC lacks A and M.
5. platforms.h's final #else is AVR, not #error — an unrecognized CH32V003 silently compiles against AVR headers.

Decisions taken

• Toolchain: what fbuild already ships (xPack riscv-none-elf-gcc 14.2.0-3, -march=rv32ec_zicsr -mabi=ilp32e). Lowest risk, already wired end-to-end, matches ch32fun. Not the OpenWCH GCC 8.2.0 / rv32ecxw path. Revisit only if bring-up surfaces a codegen problem.
• Framework: arduino. framework = ch32v003fun is rejected by validate_ch32v_framework() today and stays out of scope (fbuild#1108).
• WCH-LinkE USB IDs go to the FastLED/boards registry, not fbuild. Per CLAUDE.md, VID/PID must never be embedded in this repo.

Out of scope

minichlink deployer · GDB / fbuild debug for CH32V · QEMU rv32 emulation · probe-rs (upstream doesn't support CH32 — probe-rs#28) · framework = ch32v003fun (fbuild#1108)

Done when

A CH32V003 runs a FastLED sketch driving a physical WS2812 strip, built and flashed end-to-end by fbuild deploy, with CI compile coverage in both repos.