kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi,

On Wed, Feb 08, 2017 at 11:04:21PM +1100, Oliver Walters wrote:

> I have amended the patch to only ignore connection of pins that are both
> INVISIBLE and NC (Electrical Type = Not Connected). This will improve the
> safety of the current libraries which do contain many parts with NC pins
> set as invisible.

Late to the party here. The use cases we currently have:

 - logic gates

There is no sensible standard to draw the power supply for logic gates, and
these are often multi-unit components. Older projects rely on the implicit
behaviour of connecting the hidden supply pins.

 - op-amps

These have a sensible standard for drawing the supply, but if the pin is
not hidden, it looks ugly in the schematic. The implicit connections are
somewhere between annoying and harmful to users, and ERC rules mean that
exactly one in four op-amps needs supply pins connected in the schematic,
which is quite silly.

 - multiple supply pins

This is basically a workaround for ugliness in the schematic -- it would
work fine to just place a lot of visible pins with the same net name and
different pin numbers on top of each other. That gives an ugly smudge in
place of the pin number, but at least it's more correct than listing only
one of the pins.

Ideas:

(1) add another flag "hide labels".

That would disambiguate between "proper" hidden pins (should not be
connected to with wires/are silently connected to nets with the same name)
and "for aesthetic reasons" hidden pins (are connected to with wires/never
implicitly connected). That would be cheap to implement.

(2) add support for pins with multiple pin numbers

This is a fairly large change, but would remove the "multiple supply pins"
use case from the problem set; also, the schematic would be more correct.

(3) add a mapping layer, similar to E*gle.

Pin numbers would be no longer listed in the component, but in a separate
"part" struct (which we can create from the component when pin numbers are
listed). This would allow us to get rid of a number of annoying things,
like the different components for "transistor with base in the middle" and
"transistor with base on pin 1".

This would be complex to get right with multi-unit components, but on the
other hand it would also collapse "op-amp as part of a two-unit IC" and
"op-amp as part of a four-unit IC" into a single component when done right.
While there are a lot of people who already know which exact part they will
use and how many units it has, I wonder why we need to care about that
during schematic entry already.

(4) add a flag "connect this common pin on all subunits"

This would be useful for the op-amp case again. Units from the same IC all
need their supply pins connected to the same net, or you get an ERC error.

All op-amps show their supply connections in the schematic, and we get
extra checking that those sharing a supply in a multi-unit IC actually are
meant to be sharing it.

Moderately difficult to implement, because it would extend ERC and doesn't
immediately fit into the way ERC is implemented.

(5) add a new schematic element "connection table"

A table that lists connections between hidden pins and nets, replacing the
implicit connections. If you have TTL ICs and want to connect Vcc, then you
create a table and add an entry "U2 : Vcc -> +5V, GND -> GND". This has two
advantages: there are no surprises for people who use op-amps that hang off
different rails, and it is actually written on the schematic how the supply
should work.

These ideas can probably be combined as well, with various degrees of
usefulness.

   Simon