kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/15/2016 3:40 PM, Chris Pavlina wrote:
> On Thu, Sep 15, 2016 at 03:34:03PM -0400, Wayne Stambaugh wrote:
>> On 9/15/2016 2:47 PM, Chris Pavlina wrote:
>>> On Thu, Sep 15, 2016 at 06:54:59PM +0100, 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 _really_ want this. IIRC I submitted a wishlist item for it ages ago,
>>> and nothing ever really became of it (and as usual I ran out of time to
>>> implement it myself). These are hugely useful in complicated designs.
>>>
>>>> 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:
>>>
>>> For anyone who doesn't know yet, I'm c4757p on #kicad, or c4758p when my
>>> connection's dodgy ;)
>>
>> So your the guy who's been raking me over the coals on irc. ;)
> 
> In my defense, raking people over the coals is basically how IRC works.
> Actually I think the protocol doesn't work properly without it. ;)

I kind of figured that.  For what its worth, my nickname is ridesa7_
with various numbers of underscores depending on how many systems I'm
logged into.

> 
>>
>>>
>>>> 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)
>>>
>>> In light of the proposal to add line color support to eeschema, I'd like
>>> to see something different than just a color. They look like this in
>>> Altium:
>>>
>>> http://techdocs.altium.com/sites/default/files/wiki_attachments/231555/Harness+Connector+with+entries.png
>>>
>>> A point wrt. UI is that when eeschema is converted to GAL, a good bit of
>>> the UI code will need to be ported or thrown out. I don't think that
>>> should necessarily stall development, but I'd warn you to be prepared
>>> and write your code to be properly modular and easy to port. :)
>>>
>>>>
>>>> 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]"
>>>>
>>>> 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 haven't given this a huge amount of thought yet. Does anybody see a
>>> reason for this to me more than just a stylistic detail? We discussed
>>> this a bit on IRC and concluded that it would matter if harnesses were a
>>> subclass of buses, but if they're a separate object I don't think so.
>>>
>>>>
>>>>
>>>> I guess there are implications for the schematic file system which I need to
>>>> understand, and need to be discussed.
>>>
>>> As far as I can see, we just need to add a 'harness' type similar to the
>>> 'bus' type.
>>>
>>>>
>>>> All suggestions welcome, and I hope to start working on this soon.
>>>> 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
>>>
>>
>> _______________________________________________
>> 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