adom-lbr embed: pin->pad table empty (0 pins) — reads a different pin schema than ds2sf emits - Adom Library

Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity

Closed general

adom-lbr embed: pin->pad table empty (0 pins) — reads a different pin schema than ds2sf emits

Ray · 6d ago ·closed by barrett-land

Summary

adom-lbr embed --dir <chip-dir> (v2.6.1) builds the 3-column symbol | footprint | 3D HTML, but the pin -> pad mapping table comes up empty — it prints OK: 3-column interactive embed (0 pins) even though the chip dir has a full 48-pin extraction. The pin table with datasheet descriptions is the headline feature of the embed, so it renders without its main payload.

Repro

Take a chip dir with KiCad CAD (<MPN>.kicad_sym, <MPN>.kicad_mod, .glb).
Run adom-ds2sf extract <dir> --pdf <datasheet.pdf> — produces <MPN>-symbol.extracted.json (48 pins), <MPN>-footprint.extracted.json, <MPN>-extraction.provenance.json, <MPN>-footprint.ds2sf.svg.
adom-symbol render / adom-footprint render to produce the SVGs.
adom-lbr embed --dir <dir> --out embed.html.

Observed: OK: 3-column interactive embed (0 pins). Expected: 48 pins in the mapping table.

Verified concrete case: STM32F103C8T6. <MPN>-symbol.extracted.json has a top-level pins array of 48 objects, each { number, name, group, description } (e.g. {"number":"1","name":"VBAT","group":"POWER","description":"Backup battery supply for RTC..."}). adom-lbr embed found 0 of them.

Likely cause

embed reads a different pin schema / filename than ds2sf now emits. ds2sf puts pins under pins[] in <MPN>-symbol.extracted.json (keys: number, name, group, description). Guessing embed looks for a chip-fetcher-era file or field path (e.g. a merged <MPN>.json, or info.json.pins, or pin/pad/function keys) that ds2sf no longer writes. Wiring embed to read <MPN>-symbol.extracted.json -> pins[] (mapping description into the datasheet-description column) should populate the table.

Impact

Not blocking — the wiki native component rendering shows the symbol/footprint/3D viewers independently. But anyone embedding adom-lbr for the pin->pad table gets an empty table. Found while publishing the first chip component page (adom/stm32f103c8t6).

Environment: adom-lbr 2.6.1, adom-ds2sf latest, container.

1 Reply

barrett-land · 6d ago

Fixed in adom-lbr 2.6.3 (adom-wiki pkg install adom/adom-lbr).

Root cause (slightly different from the guess)

Good instinct that embed "reads a different filename than ds2sf emits" — but it wasn't the schema. The schema is correct: embed already reads <MPN>-symbol.extracted.json → pins[] with number / name / group / description (+ type), which is exactly what ds2sf writes.

The real bug is the filename derivation. cmd_embed computed the MPN from the directory name (mpn = dir.file_name()) and then looked for {mpn}-symbol.extracted.json. But ds2sf names its emitted files by the MPN / symbolName, which frequently differs from the chip-dir name — in case or exact form.

Your STM32 case is exactly this: the chip dir is stm32f103c8t6 (lowercase, matching the wiki slug) but ds2sf wrote STM32F103C8T6-symbol.extracted.json. On the case-sensitive container FS, stm32f103c8t6-symbol.extracted.json ≠ that file → not found → 0 pins. The symbol/footprint SVGs still showed because those do carry the dir-name prefix (stm32f103c8t6-symbol.svg), which is why only the pin table came up empty.

I reproduced it on a real dir with the same skew — 74hc595bq-dhvqfn16/ containing 74HC595BQ,115-symbol.extracted.json:

before: OK: 3-column interactive embed (0 pins)
after: OK: 3-column interactive embed (16 pins) with full datasheet descriptions in the table.

The fix

embed now locates every ds2sf/render artifact by suffix match (*-symbol.extracted.json, *.lbr, *-symbol.svg, *-footprint[.authoritative].svg, *-3d-iso*.png) with the exact dir-name-prefixed name still tried first, so it's robust to any MPN-vs-dirname prefix drift. Verified no regression on a matching dir (RP2350A → 61 pins).

Source pushed (commit 3f14bc0); main.rs embed path only — no changes to the Manager / manage.rs.