kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26243
Re: Proposal for signal harnesses in eeschema
On 9/15/2016 4:32 PM, Chris Pavlina wrote:
> On Thu, Sep 15, 2016 at 04:06:13PM -0400, Wayne Stambaugh wrote:
>> On 9/15/2016 1:54 PM, Dan Weatherill wrote:
>>> Hi all,
>>> I've been using kicad for about 5 years. Recently (mostly with CERN
>>> changes - especially differential pair support), it's become suitable
>>> for more and more of my more complex projects (I'm switching from Altium
>>> Designer). I also have about 10 years experience working on c++
>>> projects, but am not what you would call an "expert".
>>> A feature I've been especially missing in Kicad for several projects
>>> is something akin to Altium's "harnesses": that is, basically a
>>> "bus-like" entity which contains named signals, possibly of different
>>> types (e.g. input, output, passive etc). Harnesses are very useful for
>>> drawing things like e.g. SPI, I2C, CAN connections which have well
>>> defined named signals. Harnesses contain better information than
>>> numbered busses for this application, but can help with schematic
>>> "overcrowd" when wiring up chips with many signals such as micros, FPGAs
>>> etc. This is often a big problem especially in hierarchical designs
>>> where to do this using wires requires possibly dozens of hierarchical
>>> labels.
>>> I've been thinking about implementing this for a while, but have not
>>> started due to being aware that eeschema is under fairly major
>>> re-factoring at present.
>>>
>>> With guidance from c4758p on #kicad, I think that this feature could
>>> be implemented with the following steps:
>>> 1) add two new items in NETLIST_ITEM_T enum, likely called NET_HARNESS
>>> and NET_HARNESSLABELMEMBER, which have similar functionality to NET_BUS
>>> and NET_BUSLABELMEMBER but for harnesses
>>> 2) several changes to connection rules in netlist.cpp (most majorly in
>>> pointToPointConnect() and a new function
>>> NETLIST_OBJECT_LIST::connectHarnessLabels() )
>>>
>>> 3) minor UI additions (harnesses can be just a different colour wire,
>>> and harness-to-wire connections at this time can be just the same as
>>> wire-to-Bus connections)
>>>
>>> The main question usability wise would be how to label harnesses. I see
>>> two possible options:
>>> 1) new syntax: a harness has a label using new type of brackets, with
>>> harness type in brackets, e.g. an I2C bus called A would be "A{I2C}".
>>> The wires would be then labelled exactly like bus labels, e.g.: "A[SCL],
>>> A[SDA]"
>>
>> You have to be careful here. Using curly brackets in labels hasn't been
>> defined in the schematic editor so users may have used them for some
>> personal notation. I think the risk is low but breaking someone's
>> schematic is no going to make them happy.
>
> IMO, if this is implemented properly, the labels shouldn't have an
> effect unless they connect to a harness anyway, so existing schematics
> shouldn't be affected.
I suspect it could be implemented properly, just a cautionary note.
>
>>
>>>
>>> 2) bus-like syntax: using same brackets as bus syntax, but make a
>>> harness when the contained type is a string rather than numbers, i.e.
>>> "A[I2C]" for harness label, "A[SCL], A[SDA]" for harness members.
>>>
>>>
>>> I guess there are implications for the schematic file system which I
>>> need to understand, and need to be discussed.
>>
>> Whatever support you are going to need to implement this in the
>> schematic file format needs to be discussed soon because I'm hoping to
>> start on that in the not too distant future.
>>
>> Also be aware that there are going to be some major refactoring of the
>> eeschema core code so if you start before that gets completed, be
>> prepared for lots of disruptions to your work.
>>
>>>
>>> All suggestions welcome, and I hope to start working on this soon.
>>
>> Since this is a major change to the schematic editor, it would also be
>> useful if you write up a detailed blueprint on how you are planning on
>> implementing harnesses so other developers can comment.
>>
>>> Thanks,
>>> Dan W
>>>
>>>
>>> _______________________________________________
>>> 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
References