X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 22 Mar 2015 06:16:55 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] pcb alternatives In-Reply-To: <20150322070658.7eea49a8@warrawoona.sti> Message-ID: References: <5508413E DOT 4000405 AT ecosensory DOT com> <46050a0c DOT 619 DOT 14c2850d052 DOT Webtop DOT 45 AT optonline DOT net> <20150322070658 DOT 7eea49a8 AT warrawoona DOT sti> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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