Let's not forget the pending wishlist item Bug #1419146
<https://bugs.launchpad.net/kicad/+bug/1419146> to support buses of
named members.
You shouldn't have to remember that I2C_DATA is better known as I2C_0
and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1?
Extending this idea so a bus can contain another bus makes sense. Let's
take an LCD display. In addition to the 4 or 8 data lines, there are
several control lines that should be part of the bus. I want an LCD bus
that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And
while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it
named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.
-Reece
On 04/15/18 22:39, Seth Hillbrand wrote:
Hi Jon-
The major issue I think we would need to address is migration. I
don't think that only an ERC warning is sufficient in this case.
Users will rightfully expect that their old schematics will generate
valid netlists when opened in a newer KiCad.
One option here would be to translate the implicit net connections
into explicit ones when bus junctions are encountered. Unfortunately,
I think that this feature is lightly used, so we might not get much
user feedback until they encounter problems and then the problems will
be very bad
An alternative might be to increase the functionality of the bus
junction. Spitballing here but we might add a "mapping table" dialog
that allowed the user to specify the winning name and mapping order.
That should address your points 2-3 although point 4 might be the
issue. I think we could have a default mapping that follows the
expected convention but allow users to change it by double-clicking on
the junction and editing the mapping table. Then previous users could
keep their functionality while still allowing the arbitrary member
arrays you are building.
Thoughts?
-S
2018-04-15 16:40 GMT-07:00 Jon Evans <jon@xxxxxxxxxxxxx
<mailto:jon@xxxxxxxxxxxxx>>:
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
<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
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
<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
_______________________________________________
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
