X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1427807172;
	bh=d1LfRlwFxXVevkenQFzaRUYwM0EQiPalbtRIJ00mx5g=;
	h=Date:From:To:Subject:Message-ID:In-Reply-To:References:X-Mailer:
	 MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=uyd0mPp/FC2ilQqlq0lTmi9zb6KMrHe6PzDoc0vjMIGD4ONaZGrPFSrdXUMdBI4Vg
	 7RKiQqLM/s1jQdz4rz2ImRvamFOmvv7GsdgLIyWxs6PS1WGqIk/fJE4jRh1cYPuurU
	 Bi1eGrOn6S8q5Nd+fgPVcY/FkV5ye9M/bQ7mEdI0=
Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru
Date: Tue, 31 Mar 2015 18:05:47 +0500
From: Alexey Shaposhnikov <canisdirusleidy AT yandex DOT ru>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pcb alternatives
Message-ID: <20150331180547.7e2354a4@warrawoona.sti>
In-Reply-To: <alpine.DEB.2.00.1503220540200.25799@igor2priv>
References: <CAHLh21Cdm=YZuqCQ+gCHSviJquahr6cnAQ-VBLR4BSs-nfHOig AT mail DOT gmail DOT com>
	<CAOFvGD4+4bHXNYLvePi70wb_1A4=dQgb_Ov3xBghoKbXQUsSGA AT mail DOT gmail DOT com>
	<5508413E DOT 4000405 AT ecosensory DOT com>
	<46050a0c DOT 619 DOT 14c2850d052 DOT Webtop DOT 45 AT optonline DOT net>
	<CAGYR9veihi_M+B0HXptGYQLMO8=B_KOLM2wmrRNkMLG_9MdQrA AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1503180357520 DOT 25799 AT igor2priv>
	<20150322070658 DOT 7eea49a8 AT warrawoona DOT sti>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1503220540200 DOT 25799 AT igor2priv>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t2VD6LSU022226
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 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



-- 
С уважением, Алексей Шапошников.