vid-ingest: Espressif Systems (0x303A — ESP32 native USB) #723

Part of #722. Investigates a single USB vendor's public PID allocation sources.

Goal

Identify every authoritative or community-maintained public source of VID:PID → product/board name data for Espressif Systems, then add the best one(s) as a new tier in the online-data aggregator (online-data-tools/fetch_*.py + overlay_usb_vid.py).

Known VID(s)

0x303A — Espressif native USB on ESP32-S2/S3/C2/C3/C5/C6/H2/P4; also a sub-allocation registry for board-makers (TinyS2/S3, LILYGO, DFRobot, LOLIN, etc.)

Investigation checklist

Walk these in priority order. Stop at the first authoritative match; the rest are fallbacks.

• Official PID allocation registry. Does the vendor publish a public file at github.com/espressif/usb-pid or similar? (Examples that DO: raspberrypi/usb-pid, espressif/usb-pids.)
• Vendor-maintained Arduino core with boards.txt. Look at github.com/espressif/arduino* or espressif/Arduino*. Each board entry typically carries boardname.vid.N=0xVVVV + boardname.pid.N=0xPPPP.
• udev rules. github.com/espressif/*-udev files (e.g. 71-vendor.rules) often carry ATTRS{idVendor}=="VVVV" + ATTRS{idProduct}=="PPPP".
• Bootloader / flashing tool source. The vendor's flashing utility (esptool, picotool, pyOCD targets, openocd configs) typically hardcodes the bootloader VID:PID it talks to. Grep their source for the VID(s) above.
• SDK / HAL USB descriptor headers. Look for files like usbd_desc.h, usb_descriptors.c, usb_device_descriptor_t in the vendor's official SDK.
• Linux kernel drivers. drivers/usb/serial/*.c for bridge chips; the MODULE_DEVICE_TABLE lines list VID:PIDs they bind.
• Community board-package manifests. PlatformIO board JSONs, third-party Arduino cores, CircuitPython board lists.

Deliverables

When this issue is closed, the following must exist under online-data-tools/:

1. A new fetch_espressif.py script that pulls the chosen authoritative source, parses it, and emits {vidpid_str: product_name} JSON in the shape overlay_usb_vid.py --mode vendor-override expects.
2. A unit test under online-data-tools/test_espressif.py covering at least 3 known products from the vendor.
3. The new step wired into .github/workflows/update-data.yml with continue-on-error: true (same fault tolerance pattern as the existing tier-1/2/3/4 sources).
4. A brief note added to online-data-tools/README.md documenting the source URL + the per-vendor caveats found during investigation.

Acceptance criteria

• After the next workflow run, curl https://raw.githubusercontent.com/FastLED/fbuild/online-data/data/usb-vid.json | jq '."303a".products' returns at least the expected PIDs.
• A canned-query against the www SQLite DB (vidpid LIKE '303a%') returns the same PIDs with the curated product names.
• For VIDs already covered by the existing aggregator (linux-usb.org / hwdata), this issue's investigation either confirms the upstream is sufficient (close as wontfix) or proves the vendor source adds rows the upstream misses.

Gaps to note

If the vendor has no public registry and no Arduino-core boards.txt and the upstream usb.ids text databases already cover them adequately, document that finding in a closing comment so future contributors don't redo the search.

Tracker

Tracked by #722.