On 3/25/2011 1:05 PM, Dick Hollenbeck wrote: > > >>> name for this might be "conduit". >>> >>> >>> Then this alternative uses the term conduit instead of pin_group or bus. A >>> conduit is a container of signal names rather than pin names, and it exists >>> in a "conduit registry" within the schematic, available for all to see. I >>> suppose another name for signal is net. (Hold net_group as a back up >>> candidate term.) >>> >>> If the schematic editor would let you work by conduit or by wire, then you >>> could connect your parts up with single conduits, as long as you stuffed >>> those conduits with compatible wires/signals/nets. >>> >>> Lets imagine what has to happen as a conduit is brought into a part using a >>> mouse drag, just as the part is entered with the mouse pointer, extending >>> the end of the conduit up to the part. Remember, the conduit is defined by >>> a set of signals. >>> >>> What does that algorithm look like? Let's ask what information has to be >>> available within the part to allow this conduit to magically connect all its >>> signals to the correct pins. There has to be a match on the signal names >>> within the conduit to something in the pins. >>> >>> >>> Can anyone take it from here, and imagine if this is practical? >>> >>> And how this impacts my original question about the pin attributes in the >>> new design, which currently are: >>> >>> 1) number and >>> 2) name >>> >>> I still think improvements can be made to number and name. Firstly, a pin >>> number which allows letters in it can be confusing, I thought a number >>> excluded letters. 'Name' would be better for that use. >>> >>> So I ask for feedback on changing from -> to >>> >>> number -> name >>> name -> net or signal >> This seems logical to me. I personally think "signal" more descriptive than >> "net". However, "net" is such a common metaphor in schematic and PCB editors >> that the term "signal" may be less obvious to users. > > > > After sleeping on it, net is a poor pin attribute choice. > > > The part designer, who is the person designing the part, will have no prior > knowledge of the net name used to eventually hook up the part. They will > often be different people. > > Part designer only has a general sense of the use of the pin. Choosing > signal is good, and this pertains to the part, not to the board. > > As far as pin_groups, bus_pins, and conduits go (which by the way are all 3 > *different* concepts), I want to defer them until we get a working eeschema > on top of the sweet libraries. The current problem is big enough, without > moving the target.
Agreed. If memory serves, this change requires moving to an S-expression schematic file format. I should be able to start working on the new schematic file format in the next week or so. If there is no objection, I will use the same format as I did for the part file (Sweet) format document. I'll need your input on embedding the parts into the schematic to provide access to external projects when I get to that point. Wayne > > Remember for months from now: conduits are not part centric, but board > centric, whereas pin_groups and bus_pins are part centric. > > > So for short term, we are then unified on using: > > padname and signal to replace number and name respectively. > > > Thanks, > > Dick > > > > _______________________________________________ > 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
