kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

>
> As for our standard libraries, we would have to get the buy in of our
> library developers


As one of the librarians, there are three current uses of invisible pins in
the standard libs:

a) Invisible power pins - especially the 74 series libs. This is not a
behaviour that I like necessarily, and there have been a few discussions on
github as to how to proceed with improving these libs. No action yet.

b) Stacking multiple pins - Instead of having to connect duplicate pins,
this allows many schematic pins to be mapped to a single footprint pin. In
lieu of proper one-to-many mapping (let's get v5 already!!) then this is a
somewhat acceptable way of achieving this.

c) Marking NC pins - To get the "match by pin-count" functionality (e.g.
CvPCB) to work, the number of symbol pins must match the number of unique
nets on the footprint. If the NC pins are not added to the symbol, this
feature does not work. Making the NC pins visible clutters the symbol.

It is mostly point c) that is the issue here. The functionality achieved in
b) is not quite so "invisible" to the user as there is at least one visible
pin to connect to. However under no circumstance should a hidden NC pin be
able to be connected to "accidentally".

Here are my suggestions for action:

1) Take no action.
2) Remove hidden NC pins as per c). This will break match-by-pin-number,
and require that fp filters be changed to match the pin count based on the
name of the footprint. Personally I think this is a good idea as
match-by-pin-count can be hit-and-miss and requires lots of extra pin data
added to the symbols.
3) Amend the patch I have attached to only ignore pins that are both
*invisible* and have electrical type *nc*. Perhaps this should be done
anyway, I cannot fathom a use case for silently connecting invisible nc
pins.

Personally I like 2) as it means that symbols become less messy. When the
.sweet format is implemented, and one-to-many is available, I don't see a
need for invisible pins at all.

Both 2) and 3) could be implemented simultaneously. 2) is a library
management issue, 3) is a source issue.

As I understand it, CvPCB is slated for removal anyway, and the
filter-by-pin-count functionality only exists there.

Cheers,
Oliver

On Wed, Feb 8, 2017 at 5:57 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 2/7/2017 1:15 PM, Andy Peters wrote:
> >
> >> On Feb 7, 2017, at 8:16 AM, Nox <noxfiregalaxy@xxxxxxxxx> wrote:
> >>
> >> From a user point of perspective I would claim that the issue only
> raises because there is the possibility to make pins invisible. Maybe
> someone can explain to me the semantically need of invisible pins in
> general (beside the fact that kicad needs it to solve n pads: 1 pin and
> global label issues)? Would be changing the "invisible" flag to a
> "hide-if-stacked" flag feasable?
> >
> > Professional electronics engineers and experienced layout people agree:
> invisible pins are a stupid idea and they should be banished. If you
> haven’t been screwed by invisible pins on a schematic, it’s only a matter
> of time.
>
> Maybe the reason I've never been bit by this in 30+ years is that I'm
> not a professional.  I've never found it particularly dangerous except
> for new users who don't understand that electronics require power to
> operate.  Once you get over that hurdle, it's pretty obvious when your
> footprint power pins aren't connected.  That being said *always* check
> you symbols and footprints.  I don't care how much you paid from them or
> from what vendor you got them from, there is always a chance that they
> are incorrect.  If they are incorrect and you did not check them, that
> is *your* fault.  That is something I learned my first year out of
> college.  AFAIK, it still applies.
>
> >
> > I suppose that the original idea for invisible pins began back in the
> days of SSI and MSI logic, where everything had one power rail called VCC
> and also a ground rail, and to avoid cluttering up the schematic, it was
> convenient to make the power pins on each part hidden and give them
> appropriate net names.
>
> It was done so you didn't need to wire a whole bunch of pins in you
> schematic that you knew needed to be connected to power.  For us old
> timers, this was obvious.  Maybe they don't teach that in engineering
> school any more.  It also required less screen real estate.  There were
> no 28" high resolution monitors way back when.
>
> Almost every board I've ever designed has multiple supply rails because
> I've mostly worked with analog I/O so the multiple supply argument is weak.
>
> >
> > Of course, that’s an immediate fail, as TTL has a +5V rail, and
> 4000-series CMOS parts could have whatever rail (within reason) the
> designer deemed appropriate.
> >
> > Nowadays, with multiple rails on even simple designs, simply calling a
> power pin VCC and giving it the netname VCC and hiding it doesn’t work.
> >
> > And I see in this thread that there’s a use case — stacking power pins
> and hiding all but one, so when a wire is added to that one visible power
> pin it is added to all of them. That one can make a connection to an
> invisible pin baffles me.
>
> Both of these things baffle me.  Stacking pins (visible or not) is much
> scarier than invisible power pins.  Connecting a wire to an invisible
> pin just seems confusing to me.  I'm guessing this is something that
> just got overlooked but fixing it could be tricky.
>
> >
> > Also, consider the technician who is bringing up a new board, or is
> trying to repair something. S/he wants to see power pins on the schematic,
> otherwise how can anyone begin to start debugging?
> >
> > I understand the desire to avoid cluttering up a schematic by hiding
> pins. I mean, we deal with monster FPGAs and CPUs here, and generally
> there’s a page on the schematic just for FPGA power connections (and the
> decoupling caps and all that). But hiding those pins has zero benefit and
> increases the chances of an expensive screwup.
> >
> > By all means, leave the capability for invisible pins in Kicad. But the
> standard libraries should never use them (for reasons Chris has mentioned)
> and their general use should be discouraged.
>
> Invisible pin support has to be maintained.  I'm guessing some users
> still prefer it and there are legacy designs which cannot be broken.  As
> for our standard libraries, we would have to get the buy in of our
> library developers.  I'm not sure how receptive they would be to the idea.
>
> >
> > -a
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>