Dick Hollenbeck wrote:
How [ are measurements ] done? What software?
That's with fped, the tool I wrote to make the footprints we use in
gta02-core, and that's also my platform for trying concepts that
should hopefully yield a better module editor:
- partial documentation of the GUI:
http://people.openmoko.org/werner/fped/gui.html
- description of language and concepts:
http://people.openmoko.org/werner/fped/README
In fped, you use vectors to define all points that are used to
construct pads, silk, etc. Vectors can be concatenated and their x/y
size is a fairly arbitrary arithmetic expression. Vectors are also
labeled, so that they can be referenced by name. (You don't have to
do this manually - if you construct things through the GUI, you'll
probably never label a vector. fped will generate suitable names.)
To draw a pad, you define the two corners, then create the pad with
these corners. The pad only has the corner references (and the pad
name), no coordinate calculations.
In the fped language, this looks like this:
package "Example"
unit mm
ll: vec @(10mm, 10mm)
ur: vec .(5mm, 10mm)
pad "1" ll ur
E.g., the "lower left" (ll) vector starts at the origin (@) and goes
to (10, 10). The "upper right" (ur) vector continues from the previous
vector (.) and goes for another (5, 10). Then pad "1" is made between
points ll and ur.
Since we now have a nice and simple geometry, we can define measurements
through the same set of references:
measx ll >> ur -1mm
measy ll >> ur 1mm
measx means that we only measure along a parallel of the x axis, not the
diagonal. >> means that we measure between (the minimum) ll and the
maximum ur. In this case, there's only one of each anyway, but if you
add repetition, there may be several instances of the same vector, and
fped can distinguish between the "next" and the "last" instance.
At the end, there's the distance the measurement is offset from the line
being measured. (I'm not proud of this bit. I think fped should figure
out such things on its own.)
This is what the result looks like:
http://people.openmoko.org/werner/fped-pad.png
Keeping all geometry tied to vectors helps to visualize things and keeps
the number of "hidden parameters" low. I.e., the calculations that go
into a vector may not be trivial, but you can readily see what it does.
This model is a bit unconventional. For measurements, you could get the
same functionality by, say, extracting coordinates from pads. To be
able to also include silk screen objects in measurements, you'd have to
be able to name/reference them as well.
By simple, I mean the footprint editor has to be able to edit the
file in a WYSIWIG mode, i.e. graphical editing mode as now.
Yes, I think this is crucial. I would also say that it's important that
the textual representation is sufficiently readable and efficient that
people would choose it over making their own scripts. Otherwise, we'd
once again end up with the problem that the common format isn't the
format people actually use.
How do you name pins in a loop without introducing a reasonably rich
programming language? Then such language is not easily editable in
a WYSIWYG mode.
In fped, loops come in two flavours: you have the usual counting loop
and you have tables. Tables define an iteration over multiple variables.
Here's a fairly complex example:
http://people.openmoko.org/werner/fped-table.png
A simpler case would be the association between BGA row names and the
row number (for calculating the position).
To make all this GUI-friendly, iterations are declarative, not
procedural.
This means that fped iterates over all values and instantiates the
respective objects for each of them.
You control what is affected by the loops through so-called frames. The
variables in a frame only affect what's going on in the frame and any
child frames. So if you wanted to make a line of pads, you could make a
"pads" frame, put a counter or table in it, then have a vector point to
i*pitch, and add a "pad" frame at each point. The pad frame would name
the pad "$i" or maybe first set name = i+1, then use "$name".
Most of this is fairly natural if you structure things from the
beginning.
One of fped's current shortcomings is that the GUI doesn't make it
easy to
rearrange items if your structure turns out to have a problem.
We cannot make commitments for anyone else. So writing a
specification without a commitment to code it is pointless. I am
trying to suggest things I suspect somebody can code in short order.
My objective here is to find out where we want to go. Once the goal is
set, we can look for ways to get there in reasonable steps, and recruit
volunteers.
I think now is a good time for considering this, because 1) you're
revamping the module format anyway, 2) the natives are more restless on
the library front than ever, so we may actually see something happen,
and 3) we have a playground (fped) to experiment with crazy new ideas.
Now, my C++ fu isn't strong enough for me to commit to any heroic
deeds on the module editor in KiCad. But if we should consider a "bag
of tools" approach (similar to what we have now for routing), at least
temporarily, I could implement anything interesting we come up in fped.
