Re: gEDA-user: RFC: Footprint Builder

[Dave N6NZ <n6nz@xxxxxxxx>]

Robert Fitzsimons wrote:
> I've been working on a design for a software define radio and some of
> the components I'm planning on using don't have existing footprints.  So
> while thinking about the steps needed to create the slightly different
> footprints I needed, I decided to try knocking up a interactive program
> which could be used to create the footprints.

I presume you have looked at the interactive footprint scripts by DJ at 
  gedasymbols.org for twopads and dils.

> 
> So if we now move on a couple of weeks, I've now got a prototype Java
> program which is able to display a number of different footprint styles,
> (saving out to file is still on the TODO list).  And it's now at the
> point where I would like to get more input on the usability and any
> missing features.
> 
> At the moment the main goals are:
> - Interactive GUI
> - Scriptable with XML (?) input files
> - Support multiple output formats (pcb, kicad, etc)
> - Extra package details (height, keepout, etc)

I have some of my own footprint generators as well.  All are a little 
too delicate and poorly documented to release onto the world, so I 
haven't.  They should be cleaned up and released.  But I have thought 
about the problem of footprint generators.

Mine are all command line based one-shot programs, all parameters are on 
the command line.  A GUI would be nice, since I end up in an 
edit/generate/view-in-pcb loop.  It would be great to speed that up with 
an interactive viewer.

<strong-opinions>

IMHO, it is pointless to write a program that is *only* gui based.  I 
want a canonical text input file. Ideally, I want to be able to 
regenerate my entire footprint file for new design rules by running a 
make script.  I'm no where close to that, understand, but that's what I 
want.

In a perfect world, there would be two files:
a) A file of design rules that matches a fabrication process.
b) A footprint requirements file per footprint.

The footprint generator would apply "a" to "b" and either create a 
footprint or fail with an insightful and meaningful error message that 
was clear to the most casual observer.

The interactive tool would read "a", and either edit or create "b", and 
display the result nicely.

One thing that all of my tools do is embed the definition file in the 
footprint as comments.  When I use the gedasymbols.org generators, I 
hand copy the parameters into the footprint.  Again, it is mainly sloth 
that keeps me from sending DJ a patch to do that automatically.  I'd 
like to say I wouldn't use a tool that didn't embed it's definition file 
in the footprint as comments, but I've already admitted that's not true 
:)  But it's fair to say I'd never *write* a tool that didn't embed the 
definition file in the footprint, with a date stamp.

</strong-opinions>

Anyway, a good footprint synthesis system would be a great addition to 
the tool suite.

I'd like to encourage you to think about a plug-in architecture.  Seems 
like a core with a viewer and common infrastructure plus the ability to 
run a plug-in per footprint type (two pad, DIL, TQFP...) would be a 
powerful combination.

> 
> The prototype code is written in Java,
> 
> 1. http://cyclerecorder.org/footprintbuilder/footprintbuilder.jnlp
> 2. http://cyclerecorder.org/footprintbuilder/footprintbuilder.jar

I'll try to take a look at that in the next few days.

-dave



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user