Blocker for FastLED/fbuild's CH32V deployer work: the published registry has zero WCH identities.
fbuild's rule is that all VID/PID records come from this registry (never hardcoded in fbuild). Verified 2026-07-21: the repo tree and the published usb-profiles.json artifact contain no wch, ch32, or 1a86 probe/board entries beyond the CH340 (1a86:7523) and CH9102 (1a86:55d4) UART bridges. Consequences in fbuild today: fbuild serial probe list shows a WCH-Link as an unidentified 1A86:8010, deploy port auto-selection finds nothing for Ch32v envs, and preemption never fires.
Entries needed
| Device |
VID:PID |
Role/purpose |
Sources |
| WCH-Link/LinkE/LinkW, RISC-V (RV) mode |
1a86:8010 |
debug probe + CDC serial |
probe-rs wlink driver constants; WCH-LinkUserManual V2.3; Community-PIO board hwids |
| WCH-LinkE, DAP/ARM mode |
1a86:8012 |
debug probe (invisible to wlink until mode-switch) |
WCH-LinkUserManual V2.3 (Olimex mirror); Bloom docs |
| CH32 factory ISP bootloader device |
4348:55e0 and 1a86:55e0 |
ISP/DFU-style flasher target |
wchisp src/transport/usb.rs (matches both VIDs); wchisp README udev rules |
Plus CH32V board entries for the families fbuild builds (CH32V003, V006, V103, V203, V208, V303, V307, X035, L103), so profiles_for/deploy-port matching can associate a probe/CDC with a board family. Suggested semantics: WCH-Link CDC and CH32V native CDC rows get "DTR/RTS informational only; no host-driven reset; reset via SWD probe" (matches fbuild's docs/usb-cdc-control-line-matrix.md policy).
One schema note: fbuild's consumer currently compares platform == "espressif32" while the published artifact emits "esp32" (tracked fbuild-side) — when adding WCH rows, agree on the canonical platform spelling first so the new rows aren't dead on arrival.
Requested during the 2026-07-21 CH32V bench-readiness sweep in FastLED/fbuild (meta issue there links back here).
Blocker for FastLED/fbuild's CH32V deployer work: the published registry has zero WCH identities.
fbuild's rule is that all VID/PID records come from this registry (never hardcoded in fbuild). Verified 2026-07-21: the repo tree and the published
usb-profiles.jsonartifact contain nowch,ch32, or1a86probe/board entries beyond the CH340 (1a86:7523) and CH9102 (1a86:55d4) UART bridges. Consequences in fbuild today:fbuild serial probe listshows a WCH-Link as an unidentified1A86:8010, deploy port auto-selection finds nothing for Ch32v envs, and preemption never fires.Entries needed
1a86:80101a86:80124348:55e0and1a86:55e0src/transport/usb.rs(matches both VIDs); wchisp README udev rulesPlus CH32V board entries for the families fbuild builds (CH32V003, V006, V103, V203, V208, V303, V307, X035, L103), so
profiles_for/deploy-port matching can associate a probe/CDC with a board family. Suggested semantics: WCH-Link CDC and CH32V native CDC rows get "DTR/RTS informational only; no host-driven reset; reset via SWD probe" (matches fbuild'sdocs/usb-cdc-control-line-matrix.mdpolicy).One schema note: fbuild's consumer currently compares
platform == "espressif32"while the published artifact emits"esp32"(tracked fbuild-side) — when adding WCH rows, agree on the canonicalplatformspelling first so the new rows aren't dead on arrival.Requested during the 2026-07-21 CH32V bench-readiness sweep in FastLED/fbuild (meta issue there links back here).