On 3/24/2011 9:37 AM, Dick Hollenbeck wrote: > On 03/23/2011 04:59 PM, Dick Hollenbeck wrote: >>>> Pin name is, in fact, actually a pin description, and currently is just a >>>> comment. >>>> >>>> About pin "numbers" (currently a 4 characters identifier) I believe an >>>> enhancement in Eeschema could be the support of pins having >>>> multiple pin numbers. >>>> I see 2 cases: >>>> -Power pins in large ICs: >>>> they have 100 or more GND, VCC .. pins. >>>> In schematic an enhancement could be: put only one pin having one pin >>>> name (or description) and a lot of pin numbers. >>>> -"Bus pins" >>>> The is in fact a similar case: one pin having many pin numbers. >>>> Useful for components like memories and microprocessors to handle data >>>> bus and address bus with only 2 pins. >>>> the difference between these pins is mainly for netlist generation. >>>> >>>> In library files format and load/save functions, just allow the ability to >>>> store more than one pin number per pin. >>>> The cost is low. >>> Thanks for the clarification and out of the box idea on bus/pins. We can >>> spend a few emails embellishing the idea. >>> >>> >>> If I tie two such pins together with one wire, and these two bus-pins are on >>> two different chips, what ensures that the two pins hold all the same pin >>> numbers? What if the second bus-pin only has 90% of the pin numbers in it? >>> Do we have to have a public "class-definition" system for bus-pins? Must >>> the two pins have all the same pin numbers in order to be tied together? >>> >> I think another way to achieve this without losing the electrical >> directionality of each pin, is to support something like a pin_group. >> A pin_group is a more general term for a bus. It could be simply a >> collection of pins within a part. So the pin_group is a conceptual >> container of pin names only. The actual pins are held perhaps in a >> different container within the part. A part could have more than one >> pin_group. Not all pins need be in a pin_group. > > > Here's another idea to consider, slightly different. In reference to an > industrial electrical pipe holding many wires, perhaps unrelated to each > other (and therefore the term 'bus' is not optimal for this use), a good > 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. Wayne > > > Dick > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp