These two statements are logically contradictory. If schematic shouldn’t care about pin numbering of transistors, even less for resistors/caps which don’t care about pin functions at all (both pins are identical functionally). And I have to do much unnecessary work rotating those parts, just because the software forces me to do so (cares about pin numbers).
Using the generic symbols from the standard library, I do need to think about pin numbers. Because at the moment when I choose the physical part I have to know which variant to choose - GDS, GSD etc. If I didn’t care or didn’t know at first I now possibly have to change the symbol. This would be easier if there were different pin order variants inside one symbol, selectable from a drop-down list.
No, they don’t!
I said that I don’t care for rotating a resistor or a cap. It is just an annoyance I can well live with. If fixing this breaks the DRC, I’m more than happy to wear out the “r”-key on my keyboard.
I’m mainly a software developer. So I do know that wishes that do sound simple might have terrible implications on the software. I imagine that this would require an attribute like “swappable” and what pins can be swapped with what.
But I also wouldn’t like if KiCAD swaps pins unasked. I bet there are situations with unwanted results.
Keep things simple, clear and foreseeable!
Nick
1 Like
I kind of included that in my response already 
There would then need to be a way to change this somewhere central for example in cvpcb. Right now the symbol name takes care of this.
And that’s exactly where the problem is!
I don’t care at all what the pinning of the MOS is. I just know it is an N-MOS. What one exactly will be decided at a later step. After I have searched for a good match for my requirements.
It is like asking what size and technology a resistor has if you place it. It is just an R. No specification if THT or SMT, no wattage, no tolerance, no temperature coefficient. This is decided at a later step.
Nick
Wow - I found @nickm have the similar ideal to Some thoughts on the underlying data model (symbols). So I just make sure everyone aware to not double talk in to place :-).
@nhatkhai Thanks for directing me to that thread. I wasn’t aware of it.
Seems we are both on the same track.
In short, I think in a schematic, pins should be defined by function, not pin number.
I’ll read that thread and post accordingly.
Nick
Then the later step involves matching pins 1, 2 and 3 of the symbol with pins 1, 2 and 3 of the footprint.
Basically, all of you are saying more or less the same thing and in any case, this late step must be done before generating the netlist.
Kicad libraries allow the selection of the pin numbering as the last step or the first one. Not a big difference.
Not really. The pin numbering is fixed in the symbol so you select the numbering when selecting the symbol from the library. What the guys want is a way to have this determined at some later stage.
1 Like
It’s always possible to plop down random mosfet symbol and then once you picked actual part to go with it swap the symbol to the one with matching pin numbering. That’s what I do at least.
4 Likes
I do this too - the issue again is that if you got 100 symbols to swap out. if I lucky to have the identical graphical drawing, I can do a search and replace with text editor. If not, one by one.
No sorry.
You are not matching pin 1 to pin 1, you are matching gate to pin 1 (or whatever pin that is). You are matching function to pin. That is a huge difference.
Nick
Right now the mapping is done by the pin inside the symbol. This pin holds the name (the description of the function) and the pin number (the pointer to the footprint pad).
One alternative is to move the mapping to some other entity. That entity would then need to have both a pointer to the symbol pin (via the name field perhaps) and a pointer to the footprint pad (via the pad number).
This “connector” could either reside inside the symbol itself (as some complex field) or it could be a separate library system altogether. (The latter is what @Seth_h suggested, I would assume the former is what the inheritance stuff of the new file format will provide.)
OK. I can’t figure out how to solve your wish.
As pin numbers are alphanumeric, so far it can be done by numbering pins D,G,S in the symbol and the footprint.
But this way we only move the problem from symbol to footprint.
For example, a sot23 footprint could have pads with numbers D,G,S for a transistor but we need another sot23 footprint with K,A,A for a single cathode double anode diode.
Maybe you need some dynamic way to map pins by function. From my side I’m quite comfortable with the actual system.
Yes, pin numbers are fixed in the symbol but at a later stage they can choose a footprint with pins 1,2,3 or 1,3,2 or any other of the six possibilities. I know they don’t want this method.
I would not like that method either. Footprint pad numbers should not deviate from how they are defined by JEDEC or some other standards body, or at the very least by the datasheet. (*) That would be confusing and extremely hard to maintain. I would even prefer giving the footprint the pad “numbers” G, D, S in that case to be honest.
*) Yes i am aware of the fact that some packages do not really have a standardized numbering scheme but lets ignore them for the time being.
1 Like
How many different MOSFET types do you use? I use only few. When I select the element to be used I define it in my library, connect with right footprint and forget a question of pin-numbers forever.
Yep that another way to do. But if your start to use your library for multiple projects, changing it is a problems, or each project have difference version of same library also a problem in my point of view.
For what I see - JEDEC/other standard is for manufacture to follow and use - I don’t have power over them so just accept it. Then my library allays follow the datasheet to get as close match as I can.
I think I like this more than another translation layer between symbol and footprint. Because it can be treat at another column in BOM table. And can be easily mass edited. But I may be wrong.