← Back to team overview

kicad-developers team mailing list archive

Re: Github part footprint filenames

 

Dick, Lorenzo,

Replying in one email to avoid forking things into two threads.

- Using the filename to build the footprint name sounds like a great idea.
- Lorenzo, your writeup is good and you should put that up on a kicad
wiki somewhere. I'd feel bad if your write up wasn't used elsewhere as
I was referring to names in a more generic sense. Let me provide a few
concrete examples that maybe we can discuss around.

- Use case 1. Github repository used directly
-- Directory hierarchy might indicate the part family (connectors vs.
ICs vs. displays etc), or not.
-- Because this is a filesystem we can't have more than one footprint
in a given directory with a given name. If we wanted to have more than
one version, because maybe people disagree which part is the better
one, we have a couple of options.
--- Different file names
--- Ability to look into the footprint git history. I'm not sure this
is a valuable approach.

- Use case 2. Web site generated repository
-- Directory hierarchy might indicate part family. Might also reflect
the maturity of the parts, /stable vs. /unstable directories etc. This
can be pretty dynamic.
-- A user may want to see a hierarchy based on part family but
footprint names based on maturity or rating. Like
molex_blah_4stars.xxx and molex_blah_2stars.xxx, for instance.
-- We should expect that as-of-yet unknown requirements will dictate a
dynamically generated format that we didn't anticipate so we want to
at least consider that there might be really odd dynamic layouts
generated.

I'm not sure if the dynamically generated repository is going to be a
big issue on the kicad side or not.

Chris




On Wed, Aug 21, 2013 at 1:38 AM, Lorenzo Marcantonio
<l.marcantonio@xxxxxxxxxxxx> wrote:
> On Tue, Aug 20, 2013 at 08:03:54PM -0400, Chris Morgan wrote:
>> one part footprint per-file, and use of the new s-expression format. I
>> was wondering though why this format isn't the default yet? I have a
>> June stable build.
>
> AFAIK the code isn't ready, yet.
>
>> So I was trying to figure out how we might name files that were stored
>> in github. If we begin by assuming that pcbnew will use github
>> directly, how should part footprints be named? Does the name inside of
>
> If you were crazy an 'official' name is the IPC footprint name. Totally
> unreadable of course! Search for 'IPC-7351B Naming Convention for
> Standard SMT Land Patterns' (it's free), and be aware the revision C is
> coming out.
>
>> I'm trying to figure out how we can have kicad use the blob sha. Doing
>> so would let us avoid issues where the filename was the same but the
>> content differed.
>
> Probably the whole footprint-table system will handle it :P
> Also, consider that pcbnew copies the footprint (unlike eeschema), so
> once it get inserted it is not 'vulnerable' to library changes.
>
> As usual, library naming is more a personal/organizational issue (since
> the standard is most unfriendly I refuse to use it). Actually often the
> 'built in' library is often designed with different technology
> parameters so at the end I always had to redraw most of the component,
> with any cad... Just pick a rule and do it consistently. I do it this
> way and find it useful, YMMV...
>
> - First of all each technology uses a different lib. So 0,2mm
>   clearance parts have the save name as 0,1mm clearance one. but they
>   live in another lib (another folder, actually). The fabrication level
>   is part of the technology (there are exception, but these are
>   product-specific...)
>
> - Run-of-the-mill chip components are named a R, L, C followed by their
>   EIA size. So R0603 is a 1.6mm resistor, then. This is because at least
>   here in Italy the metric designation is not really used for these;
>   also there is an ambiguity for a couple of sizes.
>
> - Molded tantalum are CPxxxx-y where xxxx is the metric case and y is
>   the Kemet package. Yes, Kemet, because we found that these are not
>   always compatible between brand, since the pin lenght varies... anyway
>   CP7343-D is a typical example.
>
> - Aluminum capacitors are CPCASE-y where y is the Panasonic case.
>   Actually these *are* interchangeable, usually, so probably they could
>   be named with their size, too.
>
> - Most other components are named preferably from the JEDEC name, or the
>   EIAJ name, or the manufacturer one, followed by the pin name pattern
>   (or nothing if numeric). Alternative names are stored in the tags. By
>   the way there are too many SOT23 variants around... example TO236 is
>   a numbered SOT23, TO236-AnK is a single diode in SOT23. Of course
>   MO220WGGD1 is not very readable as a name but at least is shorter
>   than the IPC one.
>
>   Example of manufacturer specific packages: NATIONAL-TJ7A is a D2PAK
>   regulator (IIRC), LINEAR-MSOP12 is a non-standard MSOP12 used by some
>   LT components.
>
> - Other stuff is named with the name of the component/series. Example:
>   WE-PD2-L is a Würth PD2 L-size inductor, which is *almost* the same as
>   SDR0805 (which is a Bourns SDR0805 inductor). Almost because the PD2
>   is bigger so even if the pads are the same, the courtyard is not!
>
> - Parts with have an industry-standard size but no official size are
>   named from the component used as a representative. Example:
>   FINDER-40.52 is the typical 5-mm pitch, 2 form-C contacts relay.
>
> - Really unique components use the component name. CB1aH-P is a huge
>   relay with trifurcated pins (fun to desolder).
>
> - Solder mask is the same as the pin; the fabricator does
>   enlargement/ganging.
>
> - I keep silk/assembly to the maximum material position and pre-trim
>   silk against pad (since mask enlargement is done by the fabricator we
>   can't use the builtin feature).
>
> - Silk/refdes size are a big issue since they depend *a lot* on the
>   fabricator. I use the 'standard' 1.2/0.12mm sizes but the old
>   technology based on 0.2mm screen is still very common :(
>
> Hope I have given some good ideas
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References