← Back to team overview

kicad-developers team mailing list archive

Re: where footprints come from (was Re: Re: Internal

 

Werner Almesberger wrote:
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.



The external tool for footprint editing would be more practical if each footprint was in a separate file. I have supported this for some time, even in the face of disagreement from others. The notion of a footprint library can easily be done by using file system directories as the container.
Even better:

But there was also a good deal of discussion about putting a layer of abstraction between the actual file format and the client code of footprints. This layer of abstraction was an API. To do an API you eventually have to define in memory data structures, because these data structures are the goodies that you exchange with the service implementing the API.

I have said before that if such an API is defined, (and this could be done using a *.h file and Doxygen without writing one line of actual code), then any library can be implemented using a file format in any way the implementor wants. It just has to provide a C++ plugin for the PCBNEW's client usage of said API.


To fully implement this vision, it does suggest separating out the module editor, and making it responsible only for one implementation of a footprint library, but not responsible for all implementations. I would love for semi-conductor companies to provide us with source code implementing our API, to a library that they maintain. These libraries (and companies) need to compete with one another. The source code is necessary so we can be cross platform.

The API is a read only service. It does not need to support modification of footprints. And as such, much of the complexities of how a footprint were made are long hidden. Loops, vectors, and whatnot need not be exposed at that point. We could even use some of the same data structures we are currently using in the API.


Dick








Follow ups

References