search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
700 stars 747 forks source link

Naming for the multi-footprint-approach #237

Closed jkriege2 closed 5 years ago

jkriege2 commented 6 years ago

Hi @evanshultz @poeschlr @pointhi @SchrodingersGat!

I'm currently reviewing @bobc's PR on EEPROM/EPROM: https://github.com/KiCad/kicad-symbols/pull/222 . There we have a lot of devices that are available in a plethora of 8-pin-packages without EP (e.g. DIP-8/SOIC-8/TSSOP-8) + a few with EP (e.g. DFN-8). How should we handle these cases in naming?

  1. Have a specific symbol for each package.
  2. Have a symbol for each pinout/pin-count, i.e. DFN-8 specific and all 8-pin-counts n one without footprint-field filled, but with FPFilters for all matching packages.

If option 2 is allowed, how do we handle naming? e.g. 25LC010A-MC for DFN, but what to use for the multi-symbol, which does not coper all packages? Still use 25LC010A?

Best, JAN

evanshultz commented 6 years ago

This is a bit of an aside, but when I reworked the old linear.lib everyone wanted the method where the FPfilter only included valid footprints for the symbol. So the symbols were separated logically and physically. I do not think your question above is this topic.

I like the first approach because it gives smaller file sizes and it's easier (at least for me) to identify the symbol you want when adding ALIASes later. I think that dropping the part of the MPN that identifies the package, as you've done above, is the way to go.

poeschlr commented 6 years ago

I vote for one symbol per package. Until the new file format allows inheritance of symbol data this is the best approach as it allows setting of default footprints. (Default footprints reduce the risk that the user selects a wrong footprint.)

bobc commented 6 years ago

The KLC http://kicad-pcb.org/libraries/klc/G2.1/ talks about defining generic and atomic parts. It gives some examples, but does not really express a preference for either style or any explicit guidance on which should be used. Therefore it gives the impression that either style is acceptable for submissions.

I again repeat the plea that we need to write in ALL preferences into the KLC, so that both contributors and reviewers know what standard is being worked to. It seems we frequently get held up on "philosophy" issues, when time would better be spent improving the many poor quality parts to a basic level of KLC compliance...

Personally, I would prefer a neutral generic part which can be associated with a suitable footprint and MPN, and atomic parts which associated directly with a footprint and MPN, but I would not insist all possible atomic variations of MPN and footprint are provided. That would be totally impractical considering for some parts there are thousands of variations. We can't hope to include all of them. If the user does not find the desired part in the atomic parts, he/she can use the generic part as a base, which at least saves them creating a new symbol.

poeschlr commented 6 years ago

In addition i think what we call atomic is not really atomic as we allow the use of generic footprints for multiple symbols. A true atomic part would have a 1:1 connection between symbol and footprint. (A few relay footprint/symbol pairs would fulfill this requirement.)

Maybe the term "fully specified symbol" would be better?

The thinking now is that we have 4 different possibilities:

True atomic only makes sense for a very limited set of parts (some relays are an example here)

Using the MPN to fully specify a part only makes sense for parts that are special to one manufacturer. Otherwise the package suffix should be used.

Generic parts are useful for different reasons:

Generic parts are only allowed in the libs listed above. Edit: I think some of the symbols in the regulator_linear lib can also be considered "generic" as they do not specify a default footprint but are linked to multiple footprints via multiple footprint filters. They however use the base part number for their name. They also have a datasheet linked.

poeschlr commented 6 years ago

@bobc i have created a PR that should clear up this particular rule: https://github.com/KiCad/kicad-website/pull/272

myfreescalewebpage commented 5 years ago

@poeschlr and @evanshultz following response of Rene above, I think this issue is answered and can be closed. Your opinion ? Joel

myfreescalewebpage commented 5 years ago

@poeschlr and @evanshultz ping?

evanshultz commented 5 years ago

Yes, prefer symbols with a specific footprint and never allow any footprints to be matched that are invalid for the symbol.

myfreescalewebpage commented 5 years ago

That's also my point of view. Closing the issue.