kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>