search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
707 stars 744 forks source link

Seth made a suggestion about a separate atomic mapping file over on the mailing list. #1881

Open poeschlr opened 5 years ago

poeschlr commented 5 years ago

I assume not everyone is following the mailing list as closely. Seth had the idea that the current way (or even the suggested v6 option) of defining atomic (or fully specified) symbols could be improved by adding a third mapping file.

If anyone has feedback then by all means make your voice heard. An archive of the conversation is found here:

aewallin commented 4 years ago

Some random thoughts:

poeschlr commented 4 years ago

I am fully against true atomic file formats (If something is atomic then it is inseparable -> for us that would mean symbol and footprint data in the same file -> use eagle for a while to discover why this is a bad idea -> hint it scales very badly.)

a separate atomic-mapping improves on the current situation where a fully specified symbol is needed for e.g. the same op-amp in different footprints.

The inheritance feature of the new file format should be able to do the same (unless i misunderstood it) How it is represented to the user is another topic (For the user it could just look like there is a separate format for fully specified parts)

SPICE models could be included

I don't think anyone is keen on embedding spice models. The spice models will still live in their own libs and fully specified symbols will simply map to them like now. (The inheritance feature will help here) We are most likely unable to include models in KiCad unless manufacturers suddenly change their licensing. Which means it does not make sense to set up symbols for spice (for what model should we set it up?)

many footprints (and maybe 3D models) are script-generated. The script or a reference to the script could be included.

That information is best kept with the footprint no need for an atomic format. (If one even wants to embed this stuff. Do you really want to embed the Full generator which is build over a huge number of massive python files in every footprint? That would be insanely inefficient and the footprint would no longer be human readable) And a reference to the script is already in the footprints description.

If we want to improve footprints then give us a powerful fully parametric footprint editor (that keeps the parametric dimensions in the file format like the sketcher of freecad) and more than one description field (for example a separate field for linking to a datasheet or better still an unlimited number of datasheet links)