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
