Verify the L103/F103 pin overlay: all 48 identical

Parsed the pin-definition tables out of both datasheets - Table 2-1-1 (CH32L103,
C8T6 column) and Table 2 (STM32F103, LQFP48 column) - and diffed them pin by
pin. Zero mismatches, including OSC_IN/OSC_OUT, NRST, PA11/PA12 for USB,
PA13/PA14 for SWD, and BOOT0. Power pins differ only in naming.

This was the one unverified assumption the whole project rested on: three
boards laid out to a footprint that has to accept either MCU. It holds.

Full table recorded in Documents/pinout-L103-vs-F103.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Documents/README.md

@@ -14,7 +14,8 @@ Diagrams, the BOM, and the datasheets for parts this design actually depends on.
 | `half-left.svg`, `half-right.svg` | The earlier row-staggered split, kept for reference |
 
 `bom.csv` carries LCSC part numbers, JLC basic/extended status and the
-swap-dependent parts.
+swap-dependent parts. `pinout-L103-vs-F103.md` is the 48-pin overlay that
+validates the dual-MCU footprint.
 
 ## Datasheets
 
@@ -27,7 +28,7 @@ CH32X035 and CH32V203 docs used to rule out crystal-less USB — lives in
 | `CH32L103DS0.PDF` | CH32L103C8T6 | The MCU. Pinout, 64 K flash / 20 K SRAM, HSI accuracy table (§3.3.6), USBFS with 8 device endpoints (§1.4.20). |
 | `CH32L103RM.PDF` | CH32L103C8T6 | Reference manual. USB clock path (§3.3.5.6), `RB_UC_DEV_PU_EN` internal 1.5 kΩ D+ pull-up, HSICAL/HSITRIM. |
 | `CH334DS1.PDF` | CH334R | The hub. Variant feature table (which packages expose `PSELF` and port power switching), crystal-free caveats (§6.2), and the CH213 reference design for VBUS protection. |
-| `STM32F103x8xB_datasheet_rev1.PDF` | STM32F103C8T6 | The pin-compatible escape-hatch MCU. Needed for the LQFP48 pin-number overlay against the CH32L103. |
+| `STM32F103x8xB_datasheet_rev1.PDF` | STM32F103C8T6 | The pin-compatible escape-hatch MCU. Source for the LQFP48 pin overlay, now done — see `pinout-L103-vs-F103.md`. |
 
 ## ⚠️ The STM32F103 copy is Rev 1 (preliminary)
 
@@ -36,7 +37,7 @@ exfiltrating a browser-side fetch). This copy came from a third-party mirror and
 is the **early preliminary revision, 65 pages** — the current one is Rev 20 at
 ~117 pages.
 
-For the LQFP48 pin numbering it is fine: that table has not changed since 2007,
+For the LQFP48 pin numbering it is fine, and the overlay has now been done against it: that table has not changed since 2007,
 and PC13/PC14/PC15, OSC_IN/OSC_OUT, NRST, PA11/PA12, PA13/PA14 and BOOT0 are all
 present and verified in this copy.
 

Documents/pinout-L103-vs-F103.md

@@ -0,0 +1,60 @@
+# CH32L103C8T6 vs STM32F103C8T6 — LQFP-48 pin overlay
+
+**Result: all 48 pins identical. Zero mismatches.**
+
+Verified 2026-09-01 by parsing the pin-definition tables out of both datasheets
+in `Documents/` — Table 2-1-1 (CH32L103, C8T6 column) and Table 2 (STM32F103,
+LQFP48 column) — and diffing them pin by pin. This is the assumption the whole
+project rests on: the boards are laid out to this footprint so either MCU can be
+populated.
+
+Every pin below carries the same signal on both parts.
+
+| # | Signal | | # | Signal | |
+|---|---|---|---|---|---|
+| 1 | `VBAT` |  | 25 | `PB12` |  |
+| 2 | `PC13` |  | 26 | `PB13` |  |
+| 3 | `PC14` |  | 27 | `PB14` |  |
+| 4 | `PC15` |  | 28 | `PB15` |  |
+| 5 | `OSC_IN` | crystal | 29 | `PA8` |  |
+| 6 | `OSC_OUT` | crystal | 30 | `PA9` |  |
+| 7 | `NRST` | reset | 31 | `PA10` |  |
+| 8 | `VSSA` |  | 32 | `PA11` | USB D− |
+| 9 | `VDDA` |  | 33 | `PA12` | USB D+ |
+| 10 | `PA0` |  | 34 | `PA13` | SWDIO |
+| 11 | `PA1` |  | 35 | `VSS_2` |  |
+| 12 | `PA2` |  | 36 | `VDD_2` |  |
+| 13 | `PA3` |  | 37 | `PA14` | SWCLK |
+| 14 | `PA4` |  | 38 | `PA15` |  |
+| 15 | `PA5` |  | 39 | `PB3` |  |
+| 16 | `PA6` |  | 40 | `PB4` |  |
+| 17 | `PA7` |  | 41 | `PB5` |  |
+| 18 | `PB0` |  | 42 | `PB6` |  |
+| 19 | `PB1` |  | 43 | `PB7` |  |
+| 20 | `PB2` | BOOT1 | 44 | `BOOT0` | BOOT0 |
+| 21 | `PB10` |  | 45 | `PB8` |  |
+| 22 | `PB11` |  | 46 | `PB9` |  |
+| 23 | `VSS_1` |  | 47 | `VSS_3` |  |
+| 24 | `VDD_1` |  | 48 | `VDD_3` |  |
+
+## The nine that actually matter
+
+| Pin | Signal | Why |
+|---|---|---|
+| 5 / 6 | `OSC_IN` / `OSC_OUT` | 8 MHz crystal — both parts, same pins |
+| 7 | `NRST` | reset |
+| 20 | `PB2` | BOOT1 |
+| 32 / 33 | `PA11` / `PA12` | USB D− / D+ |
+| 34 / 37 | `PA13` / `PA14` | SWDIO / SWCLK |
+| 44 | `BOOT0` | boot select |
+
+## Caveats
+
+- Power pins differ only in **naming**: the L103 labels them `VSS`/`VDD`, the
+  F103 numbers them `VSS_1..3`/`VDD_1..3`. Same pins, same function.
+- The F103 datasheet used is **Rev 1 (preliminary)** — see `Documents/README.md`.
+  A released package's pinout does not change between datasheet revisions
+  (it would break every existing design), so this is sound. If you want
+  belt-and-braces, spot-check pins 32/33/34/37 against the current Rev 20.
+- This verifies **pin assignment only**. Electrical differences remain — most
+  importantly `R5`, the 1.5 kΩ D+ pull-up the F103 needs and the L103 doesn't.

README.md

@@ -96,10 +96,12 @@ L103 is pin-compatible with (same LQFP-48, `PC13`/`PC14`/`PC15`, `PD0`/`PD1` as
 Populate the F103 and it works with stock QMK today; populate the L103 when the
 port lands. Same board either way.
 
-> ⚠️ **Unverified assumption the whole board rests on:** pin *names and functions*
+> ✅ **Verified 2026-09-01: all 48 pins identical, zero mismatches.** Both
-> were confirmed identical from both datasheets, but the pin *numbering* was not —
+> datasheets' pin-definition tables were parsed and diffed pin by pin — including
-> the PDFs interleave four packages and extract badly. **Overlay the two pinout
+> `OSC_IN`/`OSC_OUT`, `NRST`, `PA11`/`PA12` (USB), `PA13`/`PA14` (SWD) and
-> drawings before routing.**
+> `BOOT0`. Power pins differ only in naming (`VSS` vs `VSS_1..3`). Full table:
+> [`Documents/pinout-L103-vs-F103.md`](Documents/pinout-L103-vs-F103.md).
+> This was the one assumption the whole project rested on. It holds.
 
 **Only one component differs between the two MCUs:** `R5`, a 1.5 kΩ pull-up on
 D+. The F103 has no internal one. The L103 does (~1.5 kΩ, enabled via