kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

Hi Reece,

Have a look at an earlier message regarding bus upgrades [1].

Cheers,
Orson

1. https://lists.launchpad.net/kicad-developers/msg32423.html

On 04/20/2018 05:15 PM, Reece R. Pollack wrote:
> 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
>

Attachment: signature.asc
Description: OpenPGP digital signature