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
