Mail Archives: geda-user/2015/07/26/11:41:18
On 07/25/2015 08:01 PM, Jason White (whitewaterssoftwareinfo AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> If you think users will use it as a crutch, you are right! That
> indicates something quite important, the footprint creation process is
> not intuitive.
The mainstream ECAD providers have gone to supplying libraries of footprints
that are tweakable with three versions of everything, and autogenerated, not tediously named.
They worry less about "vetting" footprints and seem to know that sometimes users
redo a footprint just after a prototype run, choosing one with less or more solder paste area
to solve fabbing problems. the standard library is never enough -- needs help for every design,
and making the "help" part faster, simpler, more intuitive is a boon, and no one will look
back when it comes to gEDA tools.
On 07/25/2015 08:52 PM, gedau AT igor2 DOT repo DOT hu wrote:>> I feel like the default library should be a simple set of ready made
>> files. These files may or even should be produced algorithmically at
>> compile time.
>
> I disagree here. There are way too many combination. This method results in too many files _and_ missing files. Often through
> mechanisms involving "dip pacakges above N pins are always wider", which is just not true. As an user I find learning such custom
> rules, or what the N, M or W suffix really means is harder and more risky (footprint-mismatch-wise) than a proper generator.
+1
How libraries are handled needs to be manageable/simple enough that some change/improvement is feasible, so it can happen.
Developing a shorthand language of mods to base footprints might be good. The base library could stay small,
and the tweaking language could apply in ways like: extend some in X. truncate some in Y. Shrink pads numbered (1,2,4,7)
bloat pads numbered (3,5,11,12,13).
Maybe apply that shorthand as attribs in gschem, then run a forward annotate script.
On 07/25/2015 09:14 PM, Larry Doolittle wrote:> 3. I've learned to like a database-ish mechanism where a footprint named
> foo can be defined to be "just like" or "a copy of" bar, except with a
> specified parameter changed (and new value provided). In combination with
> (1), I think this is the lowest barrier to a user tweaking a nearly-OK
> footprint for real-life use.
+1
On 07/26/2015 06:06 AM, Roland Lutz wrote:> I found what's really necessary is a kind of "configuration" file which holds the
parameters for one or some related series of
> footprints (see [0] for an example).
What if the config file was structured so it could be an attribute? Or the attrib could be a pointer to a
config file that is relative to the location of the .sch file,
but that can be tough to manage when deleting/replacing parts in a design schematic.
I'd like best to make most things brief enough that the parameters for footprint generation/tweaking
fit in an attribute line.
- Raw text -