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.
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.
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@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
