Mail Archives: geda-user/2015/07/16/23:14:56
On Thu, 16 Jul 2015, karl AT aspodata DOT se wrote:
> Igor2:
>> lately there was some activity on collecting footprint generators, so I'd
>> add mine to the list. It's part of a bigger happening in pcb-rnd:
>> - cleaning up newlib
>> - replacing the m4 footprint generator with a language-neutral mechanism
>
> What are your ideas about "replacing m4" ?
>
> Mine is directly in perl, so I can use all sorts of programming
> constructs to generate mult. footprints, and e.g. keep track of bounding
> box around all pins/pads. And I think it's easier to use a prog.lang.
> than to define a new syntax just for the fp. generator. If I need
> something new, eg. a silk cross, I just make a function for it and it
> is readily available, I don't have to write a parser too.
> Any thoughts ?
I agree with these considerations. For the first sight it may seem that
footprints are data, but if the parameters get tricky there may be some
decisions and calculations the generator should do. In this very simply
connector example I avoid overlapping pin rings by adjusting ring sizes
when I detect overlap. I can imagine other cases where overlap is exactly
what I want or I even want to calculate the size to get proper overlap. So
I fully agree that the simplest way is to use scripts.
My approach on "replacing m4", is this:
1. I remove all references to m4 from all the sources (... in my fork,
obviously)
2. I make the footprint attribute syntax clearly decide whether the user
wanted to have a file element or a generator. If the attribute
value contains parenthesis, the user wants a generator and the name of the
generator is the token before the "(". If there's no parenthesis, the
attribute is a file name.
3. There will be a small C lib (and external tool, a minimalistic CLI
binary built around this lib) that can interpret the footprint attribute,
decide whether it's a generator or not, apply search paths or run
generators. The whole thing will be centralized and implemented only once,
so gsch2pcb won't need to reproduce parts of the heuristics/code of PCB.
4. Generators are external programs. They are just ran as-is, the system
doesn't care about what language they are. They are not in m4 or perl,
they are in anyt language you like or coded in C or assembly, or they are
even on an external server (and fetched using svn cat, wget, RPC or dns
queries, haha). So PCB, gsch2pcb and whatever other tool that needs a
footprint just runs the lib descrbed in 3., which in turn calls system()
to handle generators (on windows this may need a wrapper, tho, but that's
part of point 3.).
5. My generators are in awk, but that's only because I really like awk. I
have a common.awk that provides all the building blocks so a typical
footprint gen will run some sanity checks on the arguments and run some
loops to generate the stuff.
Sidenote: a funny little feature: the footprint-to-png converter is a
~200 lines long awk script that converts a PCB footprint file to an
animator script. I compiled a "headless" SDL and a static linked animator
for the purpose, so I didn't have to install a lot of dependencies on
repo.hu. I originally wanted to use PCB for this but the amount of
dependencies (even without the GUI hids) made me play a bit with a render
script.
>
>> svn://repo.hu/pcb-rnd/trunk/pcblib-param
>
> I see you also have an element_begin and element_end, though mine is
> called element_start and element_stop; I also have a element_pin func.,
> seems we have somewhat similar thought about the generator.
Cool! I will have functions to generate pads too.
I think the PCB footprint format is pretty simple and straight-forward so
these utility functions are sort of directly derived from the format,
whatever language one uses.
>
> ...
>> http://igor2.repo.hu/cgi-bin/pcblib-param.cgi
>
> (Your preview is missing the little diamond, for the origo, though I
> realize that it is redunant; just used to see it.)
Good point, thanks! I will add it.
> Isn't silkmark = square or angled difficult to read when the connector
> is mounted ?
Thus they are options. The default "square" option is what the original
m4 script had and is what we have for headers in PCB normally.
I think "square" and "angled" are useful if you populate your boards by
hand and you also have a key pin or a mark on the connector. I do it
often, sometimes with single sided hobby boards of mine and such silk
marking saves the some time flipping the board.
> Hmm, looking through my own footprints I see that I mostly only use a
> quare pin as a marker. Does it help to have it in the silk also ?
For me, sometimes. Especially the "external" variant, when I have a board
mounted and want to plug in a header that doesn't have a key. Or when
everyting is put together, fails to work and I have to debug.
Anyway, with the tricky syntax with optional named arguments it's really
cheap to have such options without forcing to user to remember the order
of 10 positional arguments or specify them every time, so I think my
genertors will tend to have such options.
Regards,
Igor2
- Raw text -