kicad-developers team mailing list archive
Mailing list archive
Re: Re: Libraries - files and components naming policy
Brian Sidebotham <brian.sidebotham@...>
Thu, 8 Oct 2009 14:36:49 +0100
2009/10/8 Manveru <manveru@...>:
> 2009/10/8 Mateusz <komorkiewicz@...>
>> > What about pin number of such universal decals? If case of simple transistor
>> > there is 6 possibilities of connection in the physical element. Even simple
>> > diode is an a problem as my example shows, when I get Eagle imported module
>> > for miniMELF package and polarization was inverted. There has to be a way to
>> > tie case and symbol on schema to be not overwritten by settings from cvpcb,
>> > what is currently possible (should allow to select module and mark in by
>> > close padlock icon) - sometimes engineer knows what part will be on the
>> > board at the design stage.
>> > I am not telling about different version of some digital chips - the problem
>> > is deeper as someone prefers same symbols for the same logic and someone
>> > prefers every version in the library with separate symbol.
>> 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.
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 am not really strongly opinionated about it, but I think the heavy
system has benefits for many users who have posted up questions on the
kicad-users group. They expect to select a component and it already
have its correct package assigned. CVPCB is nice, but I think in
reality it shouldn't be needed. I think most people who use the
standard libraries just want a plug-and-play schematic + pcb entry
tool. I have never used a symbol or module from the standard library
because I know what we want and need. KiCAD provides pretty easy to
use tools to generate them so it didn't take too long to create a new
set of libraries for our company.
The problem in schematic entry as I see it is that you are limited to
picking an object that has all of the graphics primitives in it along
with the pinning information. I think you would really require a set
of graphical representations (Say a 2-input AND gate, NPN transistor,
PNP transistor, etc) which could have pin locators on it (I also do a
lot of my pins as zero length. I don't see that they really need any
length other than to draw them a different colour and I always end up
in black and white anyway).
Then an electrical symbol can be based on a graphical representation,
a module definition and all the other user fields that we have now and
the pin numbering information.
So that would give you:
* Common Graphics Symbols
* Schematic Symbols
* PCB Modules
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.
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.
Apologies for the long email and good luck with everything.