Mail Archives: geda-user/2015/07/20/02:28:32
Hi again,
I've finished most of the infrastructural work on pcb-rnd regarding to the
new parametric footprints.
Summary of the major changes since the last mail (see rationale at the
bottom):
1. Default.pcb: vanilla pcb stores default sytles and layers and sizes in
a settings file. pcb-rnd does not do that, but always loads a default.pcb
with all the settings when a new pcb is to be created. There is a setting
for the path of the default.pcb, the user can change that from the command
line.
2. gsch2pcb-rnd uses the same default.pcb
3. Finished moving static footprints (file elements) from newlib to
pcblib; I tried to keep only common footprints.
4. Added more parametric footprints (check them:
http://igor2.repo.hu/cgi-bin/pcblib-param.cgi). Added funky little
parameters to RCY, ACY and ALF: options on marking the polarity or type of
the device.
5. I've decided about footprint generator policy vs. geda footprint
convetions: I went for the least surprise, so there are no jumps in sizes
above specific pin numbers. This is unfortunately not compatible with the
footprint naming convention linked earlier in this thread. This
decision affects only the stock parametric footprint generators - anyone
can easily add new generators doing things differently (see rationale).
6. Link against multiple GUI hids and don't mix them up. I am not sure how
vanilla PCB does this. I had to rewrite parts of the mechanism during the
scconfig transition. The way pcb-rnd handles it: it is possible to link
multiple GUI HIDs to a single executable and it will be possible to
select the hid to start in a command line argument.
I plan to finish the install scripts this week, test the stuff on clean
systems and roll a new release.
Rationale:
1. and 2.: gsch2pcb had its own defaults (I think derived from gnetlist's
gsch2pcb output). If I had another tool that had to generate a PCB, it'd
suffer from the same problem: it either loads PCB setting files or has its
own defaults. In the new setup, the external tool only needs to insert
default.pcb. Most often it's a blind copy. In worst case some tools may
need to understand some parts of default.pcb, but these tools should
already have an understanding on the PCB format so this is better than
getting them to learn the settings format too.
The way vanilla pcb handles the default font is very similar to the above
mechanism, so there has been a precendet for this in pcb already.
3. Libraries shipped with the software should be small and should contain
only the most common footprints. Extra footrpints should be downloaded by
the user. Deciding what counts as "common" is subjective, obviously.
5. Selecting the footprint for a new device is always an extra effort.
This effort can not be saved with any sort of defaults. The process
should involve looking at the 2..3 major dimensions in the datasheet and
checking whether they match the footprint in PCB. If this step is
necessary, I find it more convenient to have footprint generators always
do the same, not having sudden jumps in sizes/behavior at specific pin
numbers but let the user explicitly (and easily) specify the main
dimensions. This means a dip(8) is as narrow as a dip(40). A wider variant
is dip(8, 600) or dip(40, 600). The user needs to check the width anyway:
- with geda conventions to make sure the tools won't introduce an
unwanted jump in width;
- with my footprints to make sure the width matches or to specify the
exact width.
I also prefer the actual numbers instead of M or N suffixes - the
dimension can be looked up in the datasheet, while custom suffixes
require an extra step of checking against tool conventions.
I've implemented the same policy in SO*, SSOP*, TSSOP*, etc.
There is a mechanism so that a footprint generator can call another with
setting up some of the parameters. This means for those who prefer the
"jumpy" convention, it is easy to create a wrapper that changes the
parameters (deriving them from pin number or whatever other parameters)
and then calls the original generator.
6. Especially useful for testing: don't have to compile and run different
binaries to test whether all GUIs are still working on my developer
system. For an end user having a GUI hid and the batch hid selectable from
tthe command line may be useful too.
Feedback, testing, contribution are welcome.
Regards,
Igor2
- Raw text -