Contribute — report a correction or propose a board

MCUID publishes one hardware fact store rendered in two languages, and every published field pins the official document it was read from. Corrections and new boards are welcome — this page explains exactly what to send so a report can be acted on without a round of guessing.

Report a correction

Copy the template below, fill every line, and submit it through the channel announced at the bottom of this page.

1. Page and location:
   URL: <the page address, plus the table row / section / claim you are reporting>
2. Board and revision:
   <board name as printed on the board, and PCB revision if you know it>
3. What is wrong:
   <the field or sentence, and what it should say>
4. Official source / evidence:
   <document title, version/date, section, table or figure — a link if public>
5. Reprint permission (if you paste text or images):
   <e.g. "quote only, with link" / "CC-BY-SA source, attribution given" / "my own photo">

An actionable report — example (real form, as accepted from an actual r25 review finding):

1. URL: /boards/raspberry/pico-w/ — claims table, gpio25.board_use.
2. Raspberry Pi Pico W, v1.
3. The page said GP25 is "unused by the board"; the SDK board header defines CYW43_DEFAULT_PIN_WL_CS 25 — GP25 is the wireless SPI chip select, not unused.
4. pico-sdk @ 079c6f39 (tag 2.3.1), src/boards/include/boards/pico_w.h — link attached.
5. Quote only, with link.

A report we cannot act on — example:

"The C6 pin table is wrong, GPIO numbers look off." — no page, no row, no source, no expected value.

The first can be checked against the cited document and either merged or answered in one pass. The second cannot: we do not guess which of 200+ contacts is meant, and we do not change published facts without a source.

Propose a board

A board lands on MCUID when its official documentation can be linked and pinned — for every key fact: identity, headers/pinout, power and boot behavior, and a start-developing entry. Use this template:

1. Board: <exact official name, vendor>
2. Why it fits: <which developers need it and for what task>
3. Official documentation you know of:
   - board user guide / datasheet: <URL + version if visible>
   - pinout diagram: <URL>
   - SDK board definition (if any): <repo + file>
4. Revisions / variants: <what you know — "unknown" is an acceptable answer>
5. Anything special: <known traps, strapping pins, revision differences>

"Unknown" answers are fine — unknown is a valid state on MCUID and will be marked as such rather than guessed. What we cannot accept is a board with no linkable official documentation: no placeholder pages are created for those (see About).

What happens after you submit

1. Received — the report is logged with its source links.
2. Checked — each claim is verified against the cited document, or the missing evidence is requested once, with the exact gap named.
3. Merged or declined — merged facts carry your cited source into the data record; declined reports get a short reason (usually: source does not say that, or applies to a different revision/board).
4. Closed the loop — the outcome is posted back through the channel the report arrived on.

Where to submit

The public intake channel is being set up. The project's code repository does not currently accept anonymous issue reports (its issue tracker is not publicly reachable — verified 2026-11-12), so until the standing channel is announced here, this page itself is the specification of what will be accepted: templates above, four-step handling, and the admission standard from About. When a confirmed channel with a named receiver exists, it will be listed in this section.

Writing standards for contributions

• Facts land with a fixed source (document + version + section) — "I remember it differently" is a lead, not a fact.
• Revision-scoped facts state the revision; a v1.0 fact must not silently apply to v1.1.
• Quotes are quoted, not paraphrased into new claims; reprinted text/images state their licence.
• Two languages, one fact store: submit in either language; the site keeps both renderings consistent.