Pins that are explicitly connected in the schematic should not have an
"unconnected pin" ERC error. But stacked pins do not count as
explicitly connected because the schematic designer has not connected
them
Now that we are dealing with individual connection elements that do not
update their connected elements as well, we can thread the update, just
being careful to guard any remaining updates (bus_enty/busLine) that
need reciprocal updating
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
If the SCH_ITEM has already been processed, the extra time needed to
iterated over the memberset and get the SCH_CONNECTION when we won't use
it is not neccesary.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
Normally, you will gain by resursing a nested loop only over the
pairs that are not already handled. In this case, however, you lose
time because you step outside of the cache by adding the reciprocal test
at each step.
Instead, we process one element at a time, keeping it cached and loop
over all other elements to add to the connection. This saves us about
75% of the time for larger loops (e.g. stacked power pins on a large
BGA)
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
We want to shorting the processing time by marking symbols that have
already been processed. But we must avoid marking symbols that will not
be processed due to their other flags
Fixes https://gitlab.com/kicad/code/kicad/issues/11164
Needed to find bottlenecks in fns, so break out individual sections of
the massive function for easier understanding.
buildItemSubgraphs (one section of the previous function) would build
millions of connections that were never used as stacked pins created X!
connections. Also tested using sets instead of lists and keeping unique
lists to avoid flagging but none of these were as performant as using
flags to remember which items had already been processed.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
They don't define a KiCad string class, so the header file name was
somewhat misleading. But the fact that they didn't match definitely
made coding more difficult.
Certain situations can trigger the stale cleanup being run
on a bus that doesn't actually contain the stated member.
In this case we should just keep calm and carry on -- who knows
what netlist will be generated, but we shouldn't crash.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8530
ADDED a new pin electrical type "free" for internally unconnected pins.
CHANGED the "unconnected" pin electrical type is now represented by
"no_connect" in files and netlists. (The legacy syntax is also accepted
in files.)
This way the net names can be inspected in eeschema and cross-probing works.
Testcases updated for the name changes
CHANGED: all unconnected pins are now included in the netlist with no_connect_ prefixes
This behavior provided shorter net names, but was confusing if
the user gives an explicit strong driver in the subsheet but not
one in the parent sheet.
Testcases updated for net name changes; connectivity is the same
Fixes https://gitlab.com/kicad/code/kicad/-/issues/4201
Seth Hillbrand
Jeff Young
Jon Evans
jean-pierre charras
Wayne Stambaugh
Marek Roszko