FSC-BT1058 had ended up with two footprint/symbol libraries on disk
(FSC-BT1058 and MIKILAB_FSC-BT1058) after a re-import baked the
"MIKILAB_" nickname prefix into the component name itself. Since that
prefix is normally added automatically when sym-lib-table/fp-lib-table
are generated, the double-prefixed copy (MIKILAB_MIKILAB_FSC_BT1058)
was invisible to collision checks and left the original as a stale,
outdated duplicate.
Consolidated onto the single correct library (symbols/other and
footprints/other without the redundant prefix, matching the rest of
the library's naming convention), fixed the symbol's Footprint
property and the footprint's 3D model reference, and regenerated both
lib-tables from disk.
To stop this class of bug from recurring:
- lib_common.check_component_name() rejects any --name that already
starts with "MIKILAB", used by import_component.py's import_symbol/
import_footprint (and therefore also by add_component.py and the
SnapEDA/UltraLibrarian importers, which call into the same core).
- check_library.py now flags any on-disk symbol/footprint whose name
already carries that prefix as an ERROR, independent of how it got
there.
- import_component.py gains --remove to cleanly delete a component
(symbol, footprint library, 3D model) and regenerate the lib-tables
in one step, for exactly this kind of cleanup.
Errors: 0 on check_library.py after the fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The importers previously refused to touch an already-imported component by
design, which meant re-importing an updated UltraLibrarian/SnapEDA zip for
the same part-number errored out. Add --update to import_component.py's
import_symbol/import_footprint (and thread it through import_snapeda.py and
import_ultralibrarian.py) so an existing symbol/footprint can be replaced
in place instead, with the manifest recording it as UPDATED rather than NEW.
Used it to refresh XTAC5212IRGER from a newer UltraLibrarian download
(single-unit symbol layout vs. the previous split power/signal units;
same 29 pins).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Imports were done via import_snapeda.py for the SnapEDA parts and the new
scripts/import_ultralibrarian.py for XTAC5212IRGER (UltraLibrarian export),
mirroring import_snapeda.py but handling UL's timestamp-named symbol files
and its multiple pad-size footprint variants (nominal/-L/-M).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Si4684-A10-GM (Skyworks FM/DAB/DAB+ receiver): extracted from unmerged
kicad-symbols MR !4782 (cannot_be_merged, failing pipeline), then
independently validated with kicad-cli and cross-checked against two
unrelated sources (Skyworks public product summary block diagram, and
PE5PVB/SI4684-DAB-Receiver's built/fabricated symbol) -- all comparable
pin names/numbers agree. Symbol only, standard Package_DFN_QFN
footprint.
FSC-BT1035 (Feasycom BT 5.2 audio module): hand-authored from the
official Feasycom datasheet's Table 3-2 pin definition (all 52 pins),
validated with kicad-cli. Symbol only -- no reliable footprint/3D
source was found; see README for what was tried and how to add one
later (manvalan/DigiRadio has a fabricated footprint for this exact
part, but its geometry lives in EasyEDA's proprietary JSON format).
scripts/import_snapeda.py: unzips a SnapEDA "Download KiCad" export and
hands off to import_component.py's existing core logic (same
validation/collision/lib-table rules as every other import path).
The easyeda2kicad.py-generated file had an unquoted URL as the
(generator ...) value: '(generator https://github.com/uPesy/...)'.
Bare/unquoted s-expression tokens can't contain ':' or '/', which broke
KiCad's parser and made the whole library silently fail to load (the
symbol was present on disk and correctly registered in fp/sym-lib-table,
but invisible in KiCad). Wrapped the value in quotes.
Also added a check_library.py rule to catch this class of error (an
unquoted generator value containing ':' or '/') automatically going
forward.
- scripts/generate_global_tables.py generates sym-lib-table.global /
fp-lib-table.global using a custom env var (default MIKILAB) instead
of ${KIPRJMOD}, for use across every KiCad project
- README §1 now has concrete, tested install steps for this machine's
KiCad 10.0 setup (per-project vs. global), including a merge script
and a note about stale kicad-personal-library entries already
present in the user's global sym-lib-table
Self-contained KiCad library (symbols, footprints, 3D models, docs,
import/check tooling) with no dependency on kicad-personal-library.
- Fixed sym-lib-table/fp-lib-table: single (version 7) header, one entry
per library, MIKILAB_<name> nicknames, ${KIPRJMOD}-relative URIs
- Resolved the SOT95P280X145-5N footprint collision (TPS7A2012PDBVR vs
TPS7A2018PDBVR): confirmed byte-identical modulo KiCad's internal
tedit timestamp, unified into one shared footprint
- Resolved a case-insensitive filename collision between the official
Diode.kicad_sym and a custom diode.kicad_sym
- Wrapped standalone footprints (ESP32-S31-WROOM-3, IC_TPS63020DSJT,
SOT95P280X145-5N) into their own .pretty libraries so they're
actually registered in fp-lib-table
- Fixed broken symbol->footprint references (including one pointing at
a nonexistent easyeda2kicad library)
- Added scripts/check_library.py, import_component.py, add_component.py,
import_batch.py, and lib_common.py
micheleandClaude Sonnet 5