I've actually given this some thought. On one
hand it seems like a footprint file "language"
might seem like a good idea. But there is a lot
to consider. What is the real advantage over the
scripts you currently use to generate a fixed
format footprint file? What is the advantage
over a footprint generator? One of the clear
disadvantages of a footprint "language" is the
difficulty in verifying that you have correctly
"drawn" the footprint. You would need a tool for
that which would look a lot like a footprint
generator. It can also be problematic dealing
with bugs when the "language" gets used in the corner cases or unusual ways.
FreePCB has a pretty versatile footprint
generator that deals with all the standard sorts
of features in the standard footprints. It is
capable of understanding the files it generates
so that it can be used to edit these footprints
as well. If you have an odd part that has some
regular features and also odd features, it can
accommodate that too. I have never needed to
hand edit a footprint file when using this
tool. Best of all, it is GUI and interactive so
I can see exactly what I am doing.
A footprint language may be quick for some
things, but I think a GUI footprint editor with a
standard, non-programmable file format is a much better general tool.
Rick
At 04:55 AM 9/17/2010, you wrote:
Phil Frost:
...
> XML and YAML are equally capable of being made unreadable. Either can be
> made more readable by defining a reasonable schema and selecting a
> clueful output library.
>
> Neither sed nor awk can process XML or YAML the right way in all cases
> without reimplementing a libyaml or libxml in sed or awk.
Ack, one can make an file format unreadable, and one can make it
reasonably readable. But that is only one side of the problem.
I am also conserned with how easy it is to write it (e.g. footprint
files).
Currently I'm trying to learn to make footprint files (since I need them).
And it seems that I almost always end up making a script making the
needed files. For me, it means that the file format is not expressive
enough.
***
I would like the file format to be "programmable", at least at the
footprint level.
1, A first step could be to allow variables in the files, e.g. to be able
to write:
pad_dims = "1.1mm 0.5mm 1.300mm"
Pad [ -1.700mm -0.300mm -1.700mm 0.300mm $pad_dims "1" "1" "square"]
Pad [ 1.700mm -0.300mm 1.700mm 0.300mm $pad_dims "1" "1" "square"]
or
x = 1.7mm
y = 0.3mm
pad_dims = "1.1mm 0.5mm 1.300mm"
Pad [ -$x -$y -$x $y $pad_dims "1" "1" "square"]
Pad [ $x -$y $x $y $pad_dims "1" "1" "square"]
or
pw = 1.1mm # pad width
ph = 1.7mm # pad height
pd = 2.3mm # pad distance
x = $pd/2 + $pw/2
y = $ph/2
...
2, Next step could be to allow "subroutines" in the native format, eg.:
two_pads(pad_width, pad_heigth, pad_separation, component_width) {
...
}
1206_reflow_soldered = two_pads( 0.9mm, 1.7mm, 2.0mm, 1.6mm )
1206_wave_soldered = two_pads( 1.1mm, 1.7mm, 2.3mm, 1.6mm )
clearance = 0.5mm
soler_mask_clearance = 0.3mm
1206_my_version = ...
or (if you don't like positional parameters):
1206_wave = two_pads( pw=1.1mm, ph=1.7mm, pd=2.3mm, cw=1.6mm )
instead of file "1206_wave.fp":
# Vishay D../CRCW.... e3
#
http://www1.elfa.se/data1/wwwroot/assets/datasheets/flD-CRCW-e3_data_en.pdf
Element ["" "" "" "" 0 0 -0.7mm -0.8mm 0 100 ""]
(
Pad [ -1.700mm -0.300mm -1.700mm
0.300mm 1.1mm 0.5mm 1.300mm "1" "1" "square"]
Pad [ 1.700mm -0.300mm 1.700mm
0.300mm 1.1mm 0.5mm 1.300mm "2" "2" "square"]
ElementLine [ -2.510mm 1.110mm 2.510mm 1.110mm 0.32mm ]
ElementLine [ 2.510mm 1.110mm 2.510mm -1.110mm 0.32mm ]
ElementLine [ 2.510mm -1.110mm -2.510mm -1.110mm 0.32mm ]
ElementLine [ -2.510mm -1.110mm -2.510mm 1.110mm 0.32mm ]
)
file "1206_reflow.fp":
etc....
3, another possibility would be to use postscript or some other
language as the "file format".
/mm 72 25.4 div def
mm mm scale
0.1 setlinewidth
/pw 1.1 def
/ph 1.7 def
/pd 2.3 def
/x pd 2 div pw 2 div add def
/y ph 2 div def
...
***
Would patches for something like this be accepted?
Regards,
/Karl Hammar
---------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user