Mail Archives: geda-user/2015/03/31/09:07:10
On Sun, 22 Mar 2015 06:16:55 +0100 (CET)
gedau AT igor2 DOT repo DOT hu wrote:
> 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.
IMNSHO this is even worse.
> 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 -