kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26241
Re: Proposal for signal harnesses in eeschema
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.
>
> 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
Follow ups
References