Mail Archives: geda-user/2015/03/22/01:17:48
On Sun, 22 Mar 2015, Alexey Shaposhnikov wrote:
> On Wed, 18 Mar 2015 04:20:41 +0100 (CET)
> gedau AT igor2 DOT repo DOT hu wrote:
>
>> 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.
>
> It looks good in theory but in practice there is a problem:
> http://wiki.geda-project.org/geda:transistor_guide So these "diode-1.sym ...
> diode-infinity.sym" will quickly come back due to lack of any abstraction
> layer over symbols and footprints in current gEDA.
>
> P.S. I know what "fake slots" can be used for pin remapping, but, IMHO, it is
> no less tedious and error-prone method. Especially for beginner.
True, transistors are not easy with gschem+pcb. However, how much
complicated they really are als depends on your goal. I have a script on
top of gsch2pcb that does the absraction for me. My lib consists of three
objects {for example for a sot23 transistor}:
- a generic {transistor} symbol (for most things I use geda stock symbols)
- a generic {sot23} footprint (usually a stock PCB footprint works)
- a 100% device specific mapping file {bc817_sot23.devmap} that tells
which pin name of the symbol should be mapped onto which pin number of
the footprint
I consider this a relatively complex but generic solution.
However, what we are talking about now is not a generic solution, but an
entry level lib for beginners. In my opinion this necessarily means a much
narrower scope: out-of-box support for much less devices. The purpose of
the lib is to help those who start experimenting with geda and do their
first few "blinking led" boards. Once they got past of this level, they
will have a generic understanding of the tools and workflows so that they
can go for heavy symbols or pin remapping tricks.
I wouldn't support multi-diodes (e.g. common-cathode or common-anode,
in sot23). I'd say a diode always has an anode and a cathode, always
two pins, and you will always use a diode footprint from pcb (SOD, ALF).
Note how these footprints actually mark polarity. The only things we need
to worry about is that the polarity matches between the only one symbol
and the few footprints we have and that all the footprints are consistent
(the marking is always on pin 1 for example). And of course that the
simplest form of spice simulation has the polarity right.
Same rules would work for other polarized two-terminal devices: caps and
LEDs (I would ship led1206.fp among led3 and led5, just to mark polarity).
Transistor is a bit trickier but not impossible. First, the same "support
the simplest case only" rule applies:
- a transistor is a single device, and has three terminals; no support for
dual transistors in 6 pin devices or arrays or devices with 4..5 pins for
higher currents or better heat transfer
- most transistors I use has its pins as b-c-e or e-b-c; I'd just provice
two symbols suffixed with "BCE" and "EBC". Yes, this is as ugly as diode-1
and diode-2, but at least it's not -1 and -2 so one knows which one to
use in advance.
- we supply only a very few common footprints: to92, t126, to220, sot23.
Maybe sot323. I explicitly would avoid trying to support dpak: there are
variants here with different pin numbering that would mess up the
next point (whether the second pin is missing or the body of the device is
considered the 2nd pin or a 4th pin).
- we do NOT include footprint sot23D or any other "reverse pin mapping"
footprints. In a simple lib, we shouldn't provide two ways doing the
mapping, and we already did it with thw two symbols. I find the symbol
hack better, because the footprint information comes from the schematics
too so the problem is not split: you do all the symbol-footprint matching
in gschem ad by the tiem you use pcb you don't need to care
- both bce and ebc symbols work out of the box in the simples spice sim
The same principle probably works for FETs too. I'd definetly omit
optodiodes, optotransistors, IGBTs, triacs, etc. Keep it small and simple,
let the user collect symbols and build his lib later.
And that was the hardest part I think. The rest are ICs (e.g. lm358),
connectors (db9, headers) or non-polarized two terminal devices
(resistors, beads) and a few popular devices that have standardized
pinout (such as 78xx, lm317, maybe a few popular LDOs). These could have
heavy symbols. For dual row headers I would provide only one pinout in
symbols and one pinout in PCB (currently the default lib has two:
header*-1 and header*-2 - this is not something you want to deal with in
your first few led blink boards) .
Regards,
Igor2
- Raw text -