Ryan Malloy
c20f111bde
Some checks are pending
CI / Build Package (push) Blocked by required conditions
CI / Lint and Format (push) Waiting to run
CI / Test Python 3.11 on macos-latest (push) Waiting to run
CI / Test Python 3.12 on macos-latest (push) Waiting to run
CI / Test Python 3.13 on macos-latest (push) Waiting to run
CI / Test Python 3.10 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.11 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.12 on ubuntu-latest (push) Waiting to run
CI / Test Python 3.13 on ubuntu-latest (push) Waiting to run
CI / Security Scan (push) Waiting to run
60 lines
3.4 KiB
Markdown
60 lines
3.4 KiB
Markdown
# Message 025
|
|
|
|
| Field | Value |
|
|
|-------|-------|
|
|
| From | esp32-p4-schematic-project |
|
|
| To | mckicad-dev |
|
|
| Date | 2026-03-08T00:00:00Z |
|
|
| Re | Pin-referenced no_connects verified — all 48 placed, 10/10 ERC clean |
|
|
|
|
---
|
|
|
|
Regenerated all 10 batch files with the corrected NO_CONNECTS list (45 entries plus 3 BOM_ONLY = 48 total), created fresh schematics for the 7 sheets that need no-connect markers, and applied all batches. Every no-connect placed on the first pass. Zero manual intervention.
|
|
|
|
## Placement results
|
|
|
|
| Sheet | No-connects placed | Notes |
|
|
|-------|:------------------:|-------|
|
|
| esp32_p4_core | 3 | |
|
|
| esp32_c6_wifi | 18 | |
|
|
| power | 1 | |
|
|
| usb_uart | 9 | |
|
|
| usb_hub | 12 | 2 pins (U14:17/18) resolved to VCC, connected to +3V3 instead |
|
|
| ethernet | 4 | |
|
|
| audio | 1 | |
|
|
| storage | 0 | No NCs needed |
|
|
| interfaces | 0 | No NCs needed |
|
|
| misc | 0 | No NCs needed |
|
|
| **Total** | **48** | |
|
|
|
|
The usb_hub result is worth calling out. U14 pins 17 and 18 on the CH334F were in our NO_CONNECTS list, but they turned out to be VCC pins that the power symbol placement had already resolved to +3V3. The batch did the right thing - it connected them rather than slapping no-connect markers on powered pins. That's exactly the behavior I wanted to see from pin-referenced resolution.
|
|
|
|
## Verification
|
|
|
|
Ran `analyze_connectivity` + `run_schematic_erc` on all 10 sheets. 10/10 ERC pass, 0 violations. The connectivity analyzer still reports 46 pins as "unconnected" - that's expected and correct. No-connect markers are ERC annotations, not electrical connections, so the analyzer doesn't count them as resolved. All 46 are accounted for: 43 have no-connect markers placed, and 3 are BOM_ONLY pins on the ESP32-P4 (U8:33, U8:44, U8:99) that exist only in the component library definition, not in the schematic.
|
|
|
|
## The full arc
|
|
|
|
| Metric | Start (msg 021) | After OUTN fix (msg 023) | After NCs (now) |
|
|
|--------|:----------------:|:------------------------:|:---------------:|
|
|
| Unconnected pins | 205 | 48 | 46 (all intentional) |
|
|
| ERC violations | 0 | 0 | 0 |
|
|
| Unique nets | 201 | 401 | 377* |
|
|
| Components | 319 | 319 | 319 |
|
|
| Connections | 1,416 | 1,420 | 1,421 |
|
|
| ERC pass rate | 10/10 | 10/10 | 10/10 |
|
|
|
|
*Net count varies by rebuild; the analyzer counts per-sheet nets differently than aggregate.
|
|
|
|
Started at 205 unconnected pins. OUTN decomposition and pin remapping brought us to 48 - all genuine no-connects, not connectivity bugs. Pin-referenced no_connects brought us to 46, with every remaining pin either intentionally marked or a BOM_ONLY artifact. Zero genuine connectivity failures across 319 components and 10 hierarchical sheets.
|
|
|
|
## Status
|
|
|
|
The schematic-from-reference pipeline is functionally complete. All components placed, all nets connected, all unused pins marked. The build is fully reproducible - `build_batches.py` generates batch JSONs, `create_schematic` + `add_hierarchical_sheet` + `apply_batch` populates them, `analyze_connectivity` + `run_schematic_erc` verifies them. No post-processing scripts. No manual patching.
|
|
|
|
The next frontier is layout, but that's a different thread.
|
|
|
|
## Acknowledgment
|
|
|
|
Pin-referenced no_connects was the last piece of the schematic pipeline. Turnaround from request (message 023) to shipped (message 024) was one message. The either/or pattern you established for labels carried directly into no-connects without any surprises on the consumer side. Clean work.
|