kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #35445
[RFC] Remove bus joining behavior from KiCad after 5.0 release
Hi all,
I am proposing to remove some behavior from KiCad as part of my bus
connections changes. I know we generally don't remove features in new
releases without good reason, but I think this is an exceptional case.
The user manual describes a way in which you can connect multiple different
buses together with junctions. If you aren't already familiar with this
behavior, please check out the manual:
http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports
The section in question is called "Global connections between buses" and
comes with the following image and describes how these bus wires with
different labels are connected together:
Allowing this kind of behavior is problematic for a number of reasons:
1. It means that net wires and bus wires behave differently, since net
wires can't have more than one label. This is potentially confusing for
users.
2. It means that junctions need a lot of special logic in order to resolve
which "branch" of a bus is called what name (for example, what if one of
those three branches in the above image didn't have a label? What would its
nets be called?)
3. Maybe most importantly, it breaks the label->netlist paradigm, since an
electrical net will only have one label in the eventual netlist, and there
is no way to determine which label should "win"
4. I don't think there's a way to map this behavior onto the new bus system
I have built that allows arbitrary bus members (instead of just a
sequential vector) in a way that would make any sense to the user.
My proposed changes in this area are as follows:
1. Remove this section from the user manual.
2. In my new connectivity algorithm, treat all connected bus wire segments
as being part of the same bus (meaning they all will have the same "name")
3. Add an ERC warning about having more than one label attached to a bus
(the warning would appear in the case of the example picture above)
4. Add a note to the user manual stating that this warning is new for 6.0
The only downside that I can see in this approach is that any users who
relied on this feature will suddenly get new ERC warnings. But I think
that this is an "anti-feature" in that it creates confusion instead of
adding value, so we should nudge anyone who uses it towards a different
approach.
Anyone see any issues with this plan?
Thanks,
-Jon
Follow ups