kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> 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.

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