kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
understands this.

Simon,

On 5/24/19 5:54 AM, Simon Richter wrote:
> Hi,
> 
> 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
>> solution.
> 
> 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
format.

>  - 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.
> 
>    Simon
> 
> _______________________________________________
> 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
>