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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
