KiPart has been around for about a year. It takes a CSV spreadsheet file describing the pins of a part (or parts) and generates a KiCad schematic library.
I’ve added another utility to KiPart called kilib2csv. It “completes the circle” and allows KiCad libraries to be converted to CSV files that can serve as the input to KiPart. This allows you to take one or more existing KiCad libraries, convert them to a CSV file, edit all the parts in a spreadsheet, and then regenerate the library with KiPart.
I developed this primarily to use libraries of parts where they didn’t set the pin types correctly (i.e., they just made every pin an input). Making the wholesale changes was easier in a spreadsheet than laboriously clicking on every pin in the library part editor.
The only downside is that any graphics for the part symbol are discarded. (KiPart draws every part as a box.) That doesn’t matter to me since I’m moving away from designing schematics graphically and all I need is the pin data, but it might make a difference to you.
I also added the capability to set the part reference prefix for each part within the spreadsheet. (Previously, it just defaulted to “U”.)
That sounds a good idea.
You may also find useful the attached python file that generates a NET report from a PCB design, ( in PADS Ascii format - easily human scanned and version checked)
This would allow a design with multiple NET sources (any mix of SCH and/or multiple scripts), to save a PCB snapshot for verify of critical NET changes.
QEDA looks interesting. I’m for anything that reduces the amount of repetitive point-and-click and the other problems that GUIs introduce. But I don’t know much about YAML. Does it provide programming constructs that I can use to describe an entire symbol or footprint? Or do I have to specify every pin individually? Or is this something I would do in a general-purpose language by making use of a YAML library?
seems to use a simple list of X,Y to repeat.
The QEDA author has the parsing engine for those files, and applies IPC rules and PCB fab rules, to make the actual KiCad footprint files.
You could do your own parser, & there is a yaml parser for Python.
It is probably not a lot of work to at least add yaml as alternative choice to your csv for SCH side ?
The QEDA way seems to be one way - description > symbol+footprint - so that one always comes from the master description and creates current symbols+footprints.
KiPart is two way csv <-> symbol+footprint (within limits).
Personally I’d expect the KiCAD library maintainers to jump onto QEDA and use it - if it works reliably.
Should make library maintenance a breeze.
Yes, what I have seen impresses, and I’ve been looking around for ways to define parts in an ‘easier’ way.
Certainly KiCAD library maintainers could use this !
Yes, tho the same reverse path could be added, in either format I expect.