kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

On 5 June 2015 at 11:08, Andy Peters <devel@xxxxxxxxx> wrote:

>
> > On Jun 5, 2015, at 10:01 AM, Henner Zeller <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.


> 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..)

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