kicad-developers team mailing list archive

[Vesa Solonen <vsolonen@...>]

On Thu, 8 Oct 2009, Brian Sidebotham wrote:

> >> Good point! What about naming pins AC(Anode Cathode in diodes) or BCE (in
> transistors)? It is already done in some cases, look on FET_N or MOSFET_P in current
> device library.
> >>
> >
> > It would be nice to have a named pins feature. I even see this as following:
> > 1. The parts on schematics have unique pin names (here for example the
> > functional name GND is problematic as we need unique GND_TOP1 name,
> > and we do not want such long names on schematics)
> > 2. Mapping to modules uses pin names to match pins on part's case (cvpcb)
> > 3. Numbering of pins appears on schematics according to matched module
> > (this is important for further project maintenance)
> > 4. Change in module does not require change anything on schematics manually
> >
> > Above leads to some problems that have to be solved. One of them is
> > consistent unique pin naming.
>
> I am pretty much against pins being anything other than integers. It's
> probably just a personal thing, but all packages I come across simply
> use integers so they would directly relate to the kicad module. The
> SOT-23 package has a fixed pin numbering scheme, that is the only PCB
> module you should have to create. Anyone creating a new part will not
> have to create another version of the SOT-23 which would need to be
> audited to make sure it is all the same as the other ones. Then of
> course, a user might need to adjust their SOT-23 because it's not
> quite right for their process and they have to go through and edit 10
> or more of them instead of just one.
>
> I know the problems with different pinouts and the same symbol. SOT-23
> transistors, diodes and FETs are a good example. The amount of SOT-23
> packages you would have to create would be unreasonable and end up
> unmaintainable, and for-ever growing.

You see it gets heavy on one or the other side (sch/pcb), but if we 
desingn a matching system in between, embedded in the schematic library or 
even as a third 'definitions' file. All very component specific would get 
in to the definitions. I'd also like to see pin functions on layout as an 
option and the possibility of changing the EBC of a transistor to matching 
module pin numbering in schematic. And all combinations of the above. 
Clever light symbols allow all that, eve though I'm not too sure they are 
'light' anymore then.

> I am a fan of a heavy symbol system, although sometimes when things
> are in a hurry I have the odd moment of liking a light symbol system.

I'm going to like a hybrid approach. Easily generalised stuff as light and 
others as heavy. I don't want to pick my capacitors one by one while 
drawing the schematic as it has no use on the 'logic' stage, but on the 
implementation and detail stage.

> Changing a common graphics symbol means that someone could change how
> all transistors look, or how all diodes look, etc. But this might be
> abstracted too far and be a dream.

Almost like that everyone could get an open source UNIX-like operating 
system for free some years ago ;)

> Don't forget too, that as some processors have different amounts of IO
> pins available depending on the package type, you will inevitably have
> to do some distinction at the schematic level for some parts depending
> on their package anyway.

Say ATMega8 in dip and tqfp should be different symbols in schematic 
because they contain different logical pins. On the other hand AT90s8535 
should be the same symbols because they contain the same logical pins, and 
only added power pins. This may get a bit complicated as it would need 
pin number mapping matrices inside schematic symbol for each different 
variant. That pin mapping system is needed for working light symbol system 
anyway if we are going to benefit from standard footprint library. A good 
example for starters is 7805 in various packages :)

My strong opinion is that the resulting flexibility is very much worth the 
effort. Otherwise I wouldn't be here trying...

-Vesa