kicad-developers team mailing list archive
Mailing list archive
Re: Atomic Libraries Proposal
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Fri, 24 May 2019 08:32:28 -0400
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint. This means that in order for
the atomic libraries as proposed to be portable, the symbol, footprint,
and 3D model would have to be available on the host machine. Otherwise,
any missing symbol, footprint, and/or 3D model would break the library.
Given what I've read so far, it's not clear to me that everyone
On 5/24/19 5:54 AM, Simon Richter wrote:
> On Thu, May 23, 2019 at 03:41:20PM -0400, Seth Hillbrand wrote:
>> After some discussion, we are trying to decide whether implementing
>> a basic atomic library support would be useful during v6 or would
>> cause more headache than worth while trying to work with the
> I have a counter-proposal, but not yet written in document form, aiming to
> integrate atomic libraries with the existing ones.
> The basic idea is that symbol definitions form an inheritance tree:
> - symbol type (e.g. "diode", "resistor", ...)
> - component specification (e.g. "1N4001")
> - package (e.g. "0603")
> - vendor
> - supplier
> Each layer adds more information about the part, and possible actions in
> the UI depend on the level of detail currently selected.
> E.g. if I have placed a generic diode, I can neither convert to PCB nor
> simulate, but the symbol is there already. If I select the particular
> diode, but not a package yet, simulation becomes possible because the SPICE
> model is attached to that layer. If I have a package selected, I can design
> a PCB, and a "change package" action in the PCB can present me with
> different package options as well.
> There are quite a lot of details to be worked out still, random thoughts:
> - US vs EU vs GOST symbols, can we somehow make them use the same pin
> positions and different graphics, so these become interchangeable?
This technically isn't atomic but could be supported with the new file
> - multi-unit components, can we somehow make them inherit the generic
> symbol multiple times and thus allow unit mapping without changing the
> schematic (i.e. gate swapping)?
I'm not sure what you mean here. Doesn't changing a symbol gate change
the schematic? The symbol will have to be a complete symbol not just
one of the sub-units. I don't see how it's possible to associate a
footprint to a single gate of component.
> - on which layer should pin to pad mapping happen? Can we fold our six
> transistor symbols (BCE, BEC, CBE, CEB, EBC, ECB) into one and allow
> switching mappings during PCB design?
This is not atomic. AFAIK, a single transistor part number cannot have
different pin out. Most of what you are describing below falls under
the same category. Maybe I don't understand what "atomic" means.
> - can we hardcode that hierarchy, or should the library be free to diverge
> from that (i.e. generic inheritable properties)?
> - are there any symbols that would not fit that mold?
> - can we add additional fields sensibly (e.g. generic "resistor" would
> define that there is a field "power rating", and the package or vendor
> layer would provide a value)? Can we filter on these?
> - while we're at it, can we drop the requirement that ICs have a graphical
> symbol, and just treat the pin table like a hierarchical sheet?
> Such a hierarchical system would IMO be the best of both worlds: atomic
> libraries would benefit from being able to reuse graphics with a single
> click, and it would still be easy to throw together a quick schematic from
> generic components and successively refine without having to decide on
> packages and suppliers right away.
> Last but not least: a way to version individual symbols and allow users
> access to multiple versions might also be very useful here.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp