kicad-developers team mailing list archive
Mailing list archive
This is turning out to be a real jewel, and will likely be one of the more
useful features of the new schematic part architecture.
To facilitate it, it is necessary to require uniquely named schematic pins. This
is a departure from old school, but I think it is worth it. Most any prior need
to to have duplicately named schematic part pins is addressed by (pin_merge...)
I realize this puts a wrinkle in smooth conversions from old school to new, but
automated tools should be able to do this duty. I solved a similar problem doing
the specctra export to Freerouter, where it wanted uniquely named pads.
The sweet *.odt file is now up to date, as of this morning, and concisely
describes the (pin_merge) support. (The committed code does not yet match the
I duplicate some of the specification here. But before getting into (pin_merge),
lets review the part's (pin) support:
(at X Y [ANGLE])
# Length of the pin in logical units. This is optional, depending on
# SHAPE, which in some cases may imply a fixed length
# Use signal to describe the purpose of the pin. Signals do not have to be
# uniquely named within a part. Signal can be blank.
(signal“NAME” (font[FONT] (size HEIGHT WIDTH) [italic][bold]) (visible YES))
# Use padname to uniquely identify the pin, according to the pin number
# in the datasheet for the part. Padnames may not be blank and must be
# be unique within the part.
(padname“NUMBER” (font[FONT] (size HEIGHT WIDTH) [italic][bold])
The main observations here are:
1) pin signals are not unique,
2) pin padnames must now be unique.
So now we can understand the shiny new (pin_merge):
# Pin merge is used to group a number of pins that are connected to the same
# net and show only one pin symbolizing the group. The group is
# called a merge set or merge group. It is typically used to hide all but
# one power pin on parts that have a large number of power connections
# such as FPGAs and micro-contollers. VISIBLE_PADNAME is the padname of
# the one pin which remains visible within the merge set. Pins with padnames
# listed within the (padnames...) element are all made invisible, and so
# are are all pins which may have any of the signal names listed in the
# (signals...) element. A pin may only exist within one merge group.
# Any number of (pin_merge...) statements maybe made, including more than
# one re-stating the same VISIBLE_PADNAME, which is the anchor pin for the
# merge set.
[(padnames HIDDEN_PADNAME1 …)]
[(signals HIDDEN_SIGNAL1 …)]
This means that in just one line of SWEET, you can group all your VCC pins
together with something as simple as this:
(pin_merge 5 (signals VCC))
This may gather up 10's of pins (all that have signal == VCC) and put them under
the umbrella of pin 5, saving you connection time.