Chips with distinct pin numbers per footprint type

[PCB_Wiz]

@Rui1973Martins

My suggestion just provides a way to guarantee, that once you assign pin numbers to a component, a “package type” will be guaranteed to be associated with it. It might not have a footprint yet, but if it has pin numbers, then it must have a “package type” (DIP, SOIC, TSOP, BGA, etc… it should include the pin count, like SOIC-32, for example).

??
Nope, a simple generic type is not nearly enough, there are a LOT of BGA’s for example, in FPGA land.
All possible with varying density of pin-fill, so you really do have to give an exact, vendor part code specific, footprint ID.

[Rui1973Martins]

@PCB_Wiz

Resuming, current component libraries, associate a component logical pins with their physical numbers, but forgot to save to which package type they apply to, and that’s the origin of the problem.

That one is really easy to solve, just use the footprint in the save-name. Already common.

And instead of Hacking a solution, why not integrate it in the software, will all the advantages that it can add.
Examples:

• Never have another component with pin numbers without associated “package type”.
  If you use an old component that doesn’t have it, it must ask for you to confirm the pin numbers for a specific “package type” before you can use it, then save it in library.
  Package type will be a property of the component.

• Never have another footprint wrongly associated (SSOP versus TSOP, etc …)
  If you use an old footprint that doesn’t have it, it must ask for you to confirm the applicable “package type” before you can use it, then save it in library.
  Package type will be a property of the footprint.

• Enforce that you can not choose a footprint that doesn’t match the associated componet “package type”(s).
  Package type will be a property of component and footprint, so that you can match them.

Basically components and footprints are split, because it makes sense to re-use them, and not defining them every time, since it’s a time consuming process to build a footprint or a component symbol.

The current problem is that all E-CAD softwares I checked have this pin nunbers problem in one way or another.

[Joan_Sparky]

Your suggestion would take away the optional-abilty of the current status quo, which serves both philosophy camps well.

Camp 1: We want to be able to assign footprints on the fly, after we’ve drawn the schematic. We are beginners and occasional users. We don’t want to maintain a parts library. Our designs are simple and low number. If stuff goes wrong, we can deal with it. We want easy access and fast results.

Camp 2: We want atomic parts. We do our own libs anyway. We maintain them and stick to the rule that we shall not have symbols in our libs that have no pre-defined footprint associated. We use our symbol library as parts library. We don’t use CVpcb. We wish for some part name stuff to make our life easier (that is probably being worked on while EEschema is being refurbished).

Live and let live

[Rui1973Martins]

@Joan_Sparky

Your suggestion would take away the optional-abilty of the current status quo, which serves both philosophy camps well.

Not it doesn’t.
It’s a real pain to not be understood

My only “imposition”, if we can call it that, is that you can only have pin numbers, on symbols, if you have a “package type” associated with it, which seems absolutely logical and evident to me.

I’m trying to fix the origin of the problem, not trying to change the work flow of others.

Live and let live

[Joan_Sparky]

@Rui1973Martins

My only “imposition”, if we can call it that, is that you can only have pin numbers, on symbols, if you have a “package type” associated with it, which seems absolutely logical and evident to me.

That’s exactly the point. There are people out there who use KiCAD and don’t want to have symbols tied down to footprints in any form or color. That’s camp #1 I was talking about.

[Rui1973Martins]

@Joan_Sparky

That’s exactly the point. There are people out there who use KiCAD and don’t want to have symbols tied down to footprints in any form or color. That’s camp #1 I was talking about.

Great !

Just don’t defined pin numbers in symbol definition. Done!

NOTE: They can still define pins, just not their pin numbers, because a pin number only makes sense, when you know the package it relates to.

I’m splitting part concepts like this:

Part
» Component(Symbol with Pin Definitions)
» » Pin Number/Package Type
» » » Footprint.

Resuming, what I’m suggesting to add, is the second level (» »)

You can break or stop these relations at any level:

• A part may not have a symbol associated/drawn yet
• A Component/symbol, might not have pin numbers.
• A Component/ symbol MUST have a package type, if it has pin numbers defined.
• A Part/Component might not have a footprint associated (might not even exist) yet.

So, this allows for every combination possible.
It just makes sure that information, when defined, is consistent.

But you have to understand the difference between these two concepts:

• A pin-definition
• A pin-number

Because currently in Kicad, they are defined together, although the pin number is optional.

[nhatkhai]

I’m reaching the exact issue now with a Photodiode part that footprint is 4-SMD, and the symbol should be just generic 2-pins LED/Diode. Without feature to allow customize the mapping - It seem to force me to create the same exact symbol but with difference pin number! This is not make so much senses some time.

[Rene_Poschl]

The generic symbol workflow is limited. In both what you can do with connecting to footprints and also what BOM Information you can include. This is why fully specified symbols make a lot of sense in such applications.

[nhatkhai]

The schematic can take care the fully BOM info part. The symbol don’t have to away have to contain fully info of part. However, I always like my symbol contain full BOM information for a “default” part Or I event just have field value as “TODO-PARTNUMBER”, “TODO-…”. When, I do schematic, I can either change them, or leave them along. Every design, will have some thing difference than the default. And the TODO- is the mark that help me easily to search/grep through my schematic file to make sure I did not miss anything. I use TODO mark for all generic symbol.

Some tool like Kifield, or reason feature in 5.x is very help full in this process. But I still like VIM, and Grep to avoid massive diff on my version control system.

For pin mapping - Just think about how spice pin mapping to the spice model is. The exact thing can be done for mapping to footprint pin!.

[Rene_Poschl]

The new file format will include powerful inheritance options. This would mean that you can for example inherit the graphics of a central symbol and set the bom, footprint and pin mapping Infos in the current symbol. (It might even be possible to work with parts that have a differing number of pins. A simple pin mapping thingy in between can not do that. At least not nicely.)

I however doubt that these advanced features will be done by v6.

[rbehm]

This creates the next problem. When I bring up or debug a board, I use the schematic to see where which signal is and goes. Therefor I need the pin numbers in the schematic. Your solution will not give me the correct pin numbers in the schematic because this will only be known when the footprint is assigned.

[Sprig]

@Joan_Sparky

Camp 1: We want to be able to assign footprints on the fly, after we’ve drawn the schematic. We are beginners and occasional users. We don’t want to maintain a parts library.

LOL!

Camp 3: We want to be able to re-assign footprints after the first fly, because new Tariffs have significantly affected what can be purchased!