Mail Archives: geda-user/2015/03/17/23:21:28
On Tue, 17 Mar 2015, Bernhard Kraft wrote:
> But it is true: the footprint and symbol libraries are quite unsorted.
I think it is worse than usorted. My favorite is the diode-1 and diode-3
symbols: they are the same thing with reverse pinout and it's really hard
to figure what you want unless you manually check the result on the PCB.
There's no clear indication on which one would pair up with a SOD or ALF
footprints (from the stock lib of PCB). If at least they had some real
name (e.g. diode-pcb and diode-sim or whatever the reason for the other
variant is) it'd be easier to remember...
<snip>
> For me gschem/pcb became really productive when I started to recall
> all the symbols/footprints I use in every design. So when you start
That was stage 1 for me.
Then I figured in some cases it's much easier to just roll my own lib
- which is very easy with gschem+pcb. However, the threshold where you
start doing this over the default lib is too low, imo. This was stage 2.
Stage 3 is when you figure you need more flexible mapping between
footprints and symbols, because the same sch is realized on breadboard
with tru-hole components then on PCB using SMD. The toolkit is strong in
supporting custom workflows and externasl scripting, and this is the first
stage where I don't feel I had to switch to this sooner than I'd expect.
I think, at some point, it's be a real major step forward if the standard
lib could be separated from gschem and pcb into a standalone package. Then
there could be standard lib variants: the current set for those who
already have a lot of designs depending on these and a new, clean
set. The clean set would have only one plain diode symbol that actually
has a pinout that fits the PCB footprints and is also good for spice
simulation.
Furthermopre the clean set wouldn't have a 100_Pin_jack, a KEYSTONE_1062
or an MSP430F1121 footprints in PCB, it wouldn't have the Allegro
Microsystems, Apex Microtechnology, DEC and similar symbol directories in
gschem. It would have a clear scope: a minimal set of the most common
generic devices for beginners and for experts who want to use it as a base
for their local symbol lib they will build from whatever sources.
Although I'd go on using the old, clumsy lib (because of the designs
accumulated over the years), I'd make the new, clean set the default and
would rework all the official documentation/tutorials and kill all
references to the "historical" lib.
Regards,
Igor2
- Raw text -