kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 6/5/2015 2:24 PM, Henner Zeller wrote:
> On 5 June 2015 at 11:08, Andy Peters <devel@xxxxxxxxx
> <mailto:devel@xxxxxxxxx>> wrote:
> 
> 
>     > On Jun 5, 2015, at 10:01 AM, Henner Zeller <h.zeller@xxxxxxx <mailto:h.zeller@xxxxxxx>> wrote:
>     >
>     > Hi,
>     > I stumbled about a similar things with double-diodes. I see why it is done, and this is one acceptable solution to the problem at hand.
>     >
>     > But it is hard to navigate.
>     >
>     > I have a long-term suggestion (that I am happy to help implement), and a short-term suggestion to get things out of the door quickly for a stable release, but helps users to not be confused and gives us a chance to improve things later.
>     >
>     > Longer term (after the next stable release), it makes sense to re-evaluate data-structures. It would probably be best to simplify the proliferation of symbols by separating symbol from pin assignments+possible footprints.
>     >
>     > So associate the schematic symbol with a number of variant footprints, which essentially adds a sub-relation, something like
>     >
>     >   symbol (generic FET for instance)  ->  (multiple variants of assignment to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)
>     >
>     > (I think this is how it is mostly done in other tools as it helps to have simple symbol _and_ a way to associate to a number of footprints). So each symbol can have a number of separate logical to pin-assignment.
>     >
>     > Main advantage for the user is, that they can see a tree view: they choose a symbol, then the sub-variant that applies to their case (pin-assignment). There or in pcbnew they then finally choose the package.
>     >
>     > Anyway, details need to be hashed out and require some discussion. And certainly not something to change now in preparation for a good next release.
>     >
>     > In the meantime, while that is not in place yet, how about this:
>     >
>     >    - we store one optional additional field in a schematic symbol, think of it as a 'tag' that ties symbols together into one family. In Adams' example, that could be for instance "Q_PMOS". All the symbols are still separate, but they have this 'unifying' field that associates things across symbols. For the younger audience: think of it as a hashtag :).
>     >
>     >    - The component chooser (which I have largely contributed in its current form) can use this additional information to present these components under one sub-tree. So the tag has no semantic meaning right now, it is only used to better display things.
>     >
>     > That way we have
>     >   1) A much more 'logical' way to present these components to a user without making their heads explode.
>     >   2) Almost no implementation overhead for an upcoming release (and importantly: very slim chance to introduce new bugs while stabilizing). No data structure is fundamentally changed, but we just add another optional field (most components never set this).
>     >   3) a chance in the future to automatically adapt schematics to a possibly new long-term data structure later.
>     >
>     > If this sounds like an acceptable solution, I am happy to work on it.
> 
>     That all seems way too complicated.
> 
>     Footprint pins should be numbered in the standard way. Since a
>     footprint can be used for many many completely unrelated devices,
>     there is no point in making the pin function part of the footprint.
>     I mean, an SOIC-8 can be used for op-amps and SPI DACs, and nobody
>     proposes an op-amp SOIC-8 footprint and an SPI DAC footprint, right?
>     So why have a dozen different variants on the TO-220 with the
>     attempt to support different voltage regulators and MOSFETs and BJTs
>     and what-not? It’s crazy.\
> 
> 
> Please read what I wrote. I suggested to just use whatever we have now
> in the schematic symbol (where the symbol explodes all the variants),
> but just tie them together. This will only affect the current generic
> symbols - which will have to be there until there is a useful big
> library that has all common components in there.
> 
> The 'long term solution' is as well only discussing the internal data
> structure to help getting to a state where we have a huge library.
> Ideally for the user, they choose a specific component.
>  
> 
> 
>     The schematic symbols already have the capability of giving a pin
>     both a name and a number. So if you want to have your transistor’s
>     pins named E, G and C, you can do that, and just make sure that you
>     map the pin function to the footprint number. Yeah, I realize that
>     too many people want to place a generic NPN on the schematic, but
>     how hard is it to create an MMBT2222 (where part name implies both
>     function and footprint), anyway?
> 
> 
> Well, I think if there is a discussion, then it should mostly focus on
> re-using parts of what you need. It would be silly to re-draw the same
> symbol many times for each transistor. You rather take a generic symbol
> (which probably is not even exposed publically to choose from by the
> user), and combine it with the necessary information (which pins, which
> footprint) to make it MMBT2222.

Redrawing symbols isn't necessary.  Symbols can have unlimited (at least
until you run out of memory or the parser crashes) aliases.  You could
create a single symbol for all GSD (123) FETs with an SOT-23 package and
add an alias for each transistor part number that follows that pin
convention.  Editing the alias list might be a bit unwieldy using the
symbol editor.  It would probably easier to edit the alias list with a
text editor.

> 
> 
>     I realize that there’s an argument that goes, “Well, the library
>     will be super big if we want to support all of the possible
>     transistors out there.” And that argument is silly. Does anyone use
>     a generic op-amp symbol instead of placing a TL072ACD (there it is
>     again, symbol name calling out footprint!) on the schematic? No, of
>     course not. So why is that OK for transistors?
> 
> 
> I am all for super-big library (and then made manageable with filters of
> 'personal preferences' or 'available in my stash' or similar).
> In fact, I would like to see the whole Digi-key, Mouser or Farnell
> catalog be available, and provide a simple way for these companies to
> export what they have in a way that we can (assisted-)automatically
> generate a huge library (including digikey and mouser and farnell order
> numbers..)

All still doable even with the limitations of the current file format.
However, this would require a one symbol per physical component symbols
library which would definitely be very large.  If you choose to go this
route, you might want to break your transistor libraries down by
manufacturer to prevent them from being too large.  It sounds like we
have some volunteers :)

>  
> I see the generic library elements as just a (sad) artifact of how
> limited the KiCad library had been in the past - where you essentially
> are forced to choose a generic component and make it work for you.
> 
> -h
> 
> 
> _______________________________________________
> 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
>