Repository navigation
vendors: ingest upstream PID allocation registries + Arduino-core boards.txt (vendors branch sync) #43
Description
Goal
Populate the vendors orphan branch with upstream-curated vendor PID allocation registries — the tier-1+2 sources fbuild's online-data aggregator (v1) was designed to ingest, but never did because the curation pipeline outgrew "a few scripts in one workflow." Per design.md, fastled/boards is the v2 home for this data.
Today: vendors carries only README.md + _meta.json (placeholder). No sync-vendors.yml workflow exists on main. No tools/sync_vendors.py exists.
The full upstream source catalog has already been triaged at FastLED/fbuild#722 with 17 per-vendor sub-issues. Since the architecture moved here, the ingestion belongs here — fbuild should consume the resulting vendors branch data, not re-do the upstream fetches.
Upstream sources to ingest
Tier 1 — authoritative PID allocation registries (gold standard)
These are the most precise sources — per-board PID resolution, not per-vendor.
Tier 2 — Arduino-core boards.txt (per-board manifests)
| Vendor | VID(s) | Upstream | Notes |
|---|---|---|---|
| Arduino (AVR) | 0x2341, 0x2A03 | arduino/ArduinoCore-avr → boards.txt |
Leonardo, Micro, Esplora, Yún |
| Arduino (SAMD) | 0x03EB, 0x2341 | arduino/ArduinoCore-samd → boards.txt |
Zero, MKR family, Nano 33 IoT |
| Arduino-ESP32 | 0x303A, partner VIDs | espressif/arduino-esp32 → boards.txt |
ESP32-S2/S3/C3 + UM TinyS2, LOLIN S2 Mini |
| Adafruit | 0x239A | adafruit/Adafruit_nRF52_Arduino → boards.txt |
Feather, ItsyBitsy, CPB, CLUE |
| Silicon Labs | 0x2341, 0x2886 | SiliconLabs/arduino → boards.txt |
Nano Matter, XIAO MG24 |
| STM32 (community) | 0x0483 | stm32duino/Arduino_Core_STM32 → boards.txt |
Nucleo, Discovery, Eval, generic STM32 |
| Teensy | 0x16C0 | PJRC teensy_loader source | Teensy 3.x/4.x/LC |
Tier 3-4 — community / archived / single-pair
| Vendor | VID | Upstream | Notes |
|---|---|---|---|
| Nordic Semiconductor | 0x1915 | NordicSemiconductor/nrf-udev → 71-nrf.rules |
Vendor-level only |
| Nordic (pca10059 explicit) | 0x1915 / 0x521F | NordicSemiconductor/nrf-device-setup-js (archived 2022-01) |
Single explicit pair |
Known gaps (no public registry — flag in _meta.json provenance)
- NXP (MCUXpresso): per-example USB descriptors only, no centralized registry.
- Microchip (Harmony USB): same shape.
- TI: no maintained list (
energia/Energiaunmaintained). - STM32 official: ST does not publish;
stm32duinois community-run.
See fbuild#722 for the full per-vendor breakdown of which sub-issue covers which source.
Proposed implementation
tools/sync_vendors.py(onmain) — fetcher + parser per source, modeled on the existingtools/sync_*.pypattern. Each source produces avendors/<vendor>.jsonwith the shape:{ "vid": "0x303A", "vendor_name": "Espressif Systems", "source_url": "https://github.com/espressif/usb-pids", "source_sha": "<commit hash>", "fetched_at": "2026-MM-DDTHH:MM:SSZ", "license": "<from source repo>", "boards": [ {"pid": "0x1001", "name": "ESP32-S2 Saola"}, {"pid": "0x4002", "name": "Unexpected Maker TinyS2"}, ... ] }.github/workflows/sync-vendors.yml(onmain) — nightly cron +workflow_dispatch, runstools/sync_vendors.py, then publishes the output to thevendorsorphan branch viatools/git_publish.py(force-with-lease, history pruned to ~200 commits — same machinery as the other orphan-branch workflows)._meta.jsonon thevendorsbranch — provenance record per source: URL, commit SHA, fetch timestamp, license, parse status. Known-gap vendors (NXP/Microchip/TI) listed with explanation so consumers know the data is intentionally absent.build_usb_ids.py(already onmain) — extend to foldvendors/*.jsoninto the aggregate so thesitebranch's SQLite carries per-board PID resolution.
Acceptance criteria
-
tools/sync_vendors.pyparses all 7 Arduino-core sources + 2 tier-1 PID registries + Nordic udev rules. -
.github/workflows/sync-vendors.ymlruns nightly + onworkflow_dispatch, publishes tovendorsbranch. -
vendors/_meta.jsonlists every source with its commit SHA + fetch timestamp; known-gap vendors documented. - First successful run carries at least 200 per-board entries across all sources.
-
build_usb_ids.pyingests the per-board data; thesitebranch's SQLitevidpidtable returns "Pico CircuitPython" for2e8a000b(not just "Pico SDK CDC UART"). - fbuild's #722 acceptance criterion ("
fbuild-core::usb::resolver::pretty(0x303A, 0x4002)returns 'Unexpected Maker TinyS2 Arduino'") passes once fbuild consumes from this branch instead of doing its own fetches.
Why this belongs here (not fbuild)
- Per
design.md: the curation pipeline outgrew fbuild'sonline-datav1 — the explicit purpose of this repo is to be the v2 aggregator. - The
vendorsorphan branch is already set up and waiting for data. - Other consumers (the public boards portal at the
sitebranch) need the same data and can read directly from this repo without depending on fbuild. - Single source of truth for VID:PID across the fastled organization.
Downstream coordination
Once this lands, FastLED/fbuild#722 closes — fbuild's online-data consumer simply reads vendors/*.json from this repo instead of re-fetching from the same upstream sources. The 17 per-vendor sub-issues (#723–#739) become trivially-done from fbuild's side because the data lives here.
Activity
zackees commentedon Jun 30, 2026
Status update — 2026-06-29 exhaustive source catalog
A 4-agent parallel sweep across (a) vendor PID registries, (b) Arduino-core
boards.txtecosystem, (c) bootloader/flashing-tool sources, and (d) system-level USB databases catalogued every known VID/PID data store. The full list below replaces and supersedes the smaller table from the original issue body.TIER 1 — Official vendor PID allocation registries (gold standard)
raspberrypi/usb-pid0x2E8Aespressif/usb-pids0x303AVVVV:PPPP descriptionpidcodes/pidcodes.github.com0x1209openmoko/openmoko-usb-oui0x1D50usb_product_ids.psv)obdev/v-usb+ VOTI0x16C0creationid/creatorsFound NEGATIVE for official registries: STMicroelectronics, NXP, Microchip/Atmel, Nordic, Silicon Labs, Texas Instruments, Renesas, Cypress/Infineon, Ambiq, WCH/openwch, DFRobot, Pimoroni. These vendors either reuse SDK-default PIDs across all boards or assign customer PIDs privately by email. Their per-board PIDs are only recoverable via tier-2 board-manifest sources.
TIER 2 — Board-manifest sources (per-board USB hwids embedded in board defs)
PlatformIO + already cataloged
hwidsarrayarduino/ArduinoCore-avrarduino/ArduinoCore-samdespressif/arduino-esp32adafruit/Adafruit_nRF52_ArduinoSiliconLabs/arduinostm32duino/Arduino_Core_STM32Arduino-core ecosystem (NEW — not yet in #43)
arduino/ArduinoCore-mbedarduino/ArduinoCore-renesasarduino/ArduinoCore-megaavrarduino/ArduinoCore-samarduino/ArduinoCore-zephyrearlephilhower/arduino-picoadafruit/ArduinoCore-samdsparkfun/Arduino_Boards(avr+samd)Seeed-Studio/ArduinoCore-samdSeeed-Studio/Adafruit_nRF52_ArduinoSeeed-Studio/ArduinoCore-mbedSeeed-Studio/ArduinoCore-renesasRAKWireless/RAK-nRF52-ArduinoIndustruino/IndustruinoSAMDHeltec-Aaron-Lee/WiFi_Kit_seriesEmbedded firmware / runtime sources
adafruit/circuitpythonports/*/boards/*/mpconfigboard.mk)micropython/micropythonports/*/boards/*/mpconfigboard.h)PaulStoffregen/coresARMmbed/DAPLinkprobe-rs/probe-rs(/targets)particle-iot/particle-usbSeeed-Studio/platform-seeedboardsTIER 3 — Bootloader / flashing-tool sources (hard-coded VID/PID tables)
esptool/loader.py+esptool/targets/esp32*.pypicoboot_connection/picoboot_connection.cboards.txt)tcl/interface/*+src/jtag/drivers/cmsis_dap_usb_bulk.cpyocd/probe/pydapaccess/interface/common.py(KNOWN_CMSIS_DAP_IDS)src/probe/{cmsisdap,stlink,jlink,wlink,ftdi,espusbjtag}/src/dfuse.c+src/quirks.cteensy_loader_cli.cutils/uf2families.jsonsrc/platforms/hosted/bmp_libusb.csrc/avrdude.conf.insrc/mbed_os_tools/detect/platform_database.pyboards.txt99-jlink.rules(mirror: 1847123212/jlink-5.10)config/udev/rules.d/49-stlinkv*.rulesTIER 4 — System-level USB databases (aggregator backbones)
vcrhonek/hwdata(Fedora upstream)woodruffw/usb-ids.rsunusual_devs.h, scattered driver tables)/lib/modules/$(uname -r)/modules.alias(generated by depmod)usb-ids.gowdy.usHKLM\SYSTEM\CurrentControlSet\Enum\USBGet-PnpDevicesystem_profiler -json SPUSBDataType/usr/sbin/system_profilerConfirmed NEGATIVE results (no per-board PID registry exists publicly)
Verified across vendor GitHub orgs + corporate sites:
VID/PID ambiguities to flag in downstream consumers
espressif/usb-pidsto disambiguate vendor.obdev/v-usb/USB-IDs-for-free.txt.Ingestion priority for
tools/sync_vendors.pyLand in this order (each is an independent commit):
raspberrypi/usb-pid,espressif/usb-pids,pid.codes,openmoko-usb-oui,obdev/v-usb,creationid/creators.hwidsregistry — covers everything else as a tier-2 fallback (~1500 boards).boards.txt— 22 cores total (catches boards PIO doesn't ship; especiallyearlephilhower/arduino-picofor its 11-VID partner-board coverage).usb.idsviavcrhonek/hwdata— last-resort vendor-name fallback for any unmatched VID.Skip: Tier-4 SDK example defaults (NXP/Microchip/etc.) — they generate false-positive collisions across unrelated boards. Skip the-sz.com, NirSoft, DriverPack, etc. (opaque provenance, redundant with usb.ids).
Updated acceptance criteria
tools/sync_vendors.pyparses 22 Arduino-core boards.txt sources (the 7 originally listed + 15 newly catalogued).pid.codes,openmoko-usb-oui,obdev/v-usb,creationid/creators).usb.idsingested viawoodruffw/usb-ids.rs(Rust-native) ORvcrhonek/hwdata(filesystem).vendors/_meta.jsondocuments 12 known VID ambiguities (FTDI clones, CH340 masquerade, Arduino split, etc.) so downstreampretty()can mark them with a confidence score.hwidsor vendor-specific Arduino-coreboards.txt.Original 9-source acceptance criterion is superseded — the real source count is ~50+ across all tiers.