kicad-developers team mailing list archive
Mailing list archive
Re: Re: Libraries - files and components naming
Vesa Solonen <vsolonen@...>
Fri, 9 Oct 2009 12:06:58 +0300 (EEST)
Alpine 1.99 (SOC 1136 2008-08-12)
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
> 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...