X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: multipart/signed; boundary="Apple-Mail=_73A74A32-C08D-4C61-9FFE-30AC07A08AC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] Cross project collaboration on data models X-Pgp-Agent: GPGMail 2.5.2 From: John Doty In-Reply-To: Date: Wed, 23 Dec 2015 08:30:12 -0700 Message-Id: References:

To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) 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 --Apple-Mail=_73A74A32-C08D-4C61-9FFE-30AC07A08AC7 Content-Type: multipart/alternative; boundary="Apple-Mail=_3232B2A5-4AF4-49EB-9F84-DCF3F4D41BDA" --Apple-Mail=_3232B2A5-4AF4-49EB-9F84-DCF3F4D41BDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 23, 2015, at 1:04 AM, Erich Heinzle (a1039181 AT gmail DOT com) [via = geda-user AT delorie DOT com] wrote: > while writing the utilities to port kicad libraries (schematic = symbols) and modules (footprints) to gEDA's format, the key differences = which made direct translation difficult were: >=20 > gschema: >=20 > a different set of pin types: >=20 > in Input > out Output > io Input/Output > oc Open collector > oe Open emitter > pas Passive > tp Totem pole > tri Tristate (high impedance) > clk Clock pwrPower/Ground > Table 1: pintype valuesfor gschem >=20 > vs kicad's: > Input >=20 > Usual input pin >=20 > Output >=20 > Usual output >=20 > Bidirectional >=20 > Input or Output >=20 > Tri-state >=20 > Bus input/output >=20 > Passive >=20 > Usual ends of passive components >=20 > Unspecified >=20 > Unknown electrical type >=20 > Power input >=20 > Power input of a component >=20 > Power output >=20 > Power output like a regulator output >=20 > Open collector >=20 > Open collector often found in analog comparators >=20 > Open emitter >=20 > Open collector sometimes found in logic. >=20 > Not connected >=20 > Must be left open in schematic >=20 >=20 > obviously, seamless symbol interchange would be facilitated by having = equivalent categories of pin type. > gschema supports arbitrarily large numbers of attributes for elements = in a symbol, kicad does not. > This is not a big deal since the harder work of drawing and pin = labelling and pin type designation is not duplicated/wasted effort. >=20 I wouldn=92t obsess on this. Pin types are secondary, only used for DRC = checking. And DRC checking is really dependent on the kind of circuits = you=92re drawing and the engineering tradition they represent. It=92s = not =93one size fits all=94. Geda-gaf=92s DRC checking really only fits = logic design with a single MSI family, which I suspect is only a = minority of designs. KiCAD=92s looks similarly limited, but with a = little more detail. It wouldn=92t be terribly hard to write a DRC back end for gnetlist that = used KiCAD-style pin types. That=92s the geda-gaf way: write a script to = adapt the toolkit to the flow. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_3232B2A5-4AF4-49EB-9F84-DCF3F4D41BDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Dec 23, 2015, at 1:04 AM, Erich = Heinzle (a1039181 AT gmail DOT com) = [via geda-user AT delorie DOT com] = <geda-user AT delorie DOT com>= wrote:

while writing the utilities to port kicad libraries = (schematic symbols) and modules (footprints) to gEDA's format, the key = differences which made direct translation difficult = were:

gschema:

a different set of pin types:

in = Input
out Output
io Input/Output
oc Open collector
oe Open = emitter
pas Passive
tp Totem pole
tri Tristate (high = impedance)
clk Clock pwrPower/Ground
Table = 1: pintype = valuesfor gschem

vs kicad's:
Input
Usual input pin
Output
Usual output
Bidirectional
Input or Output
Tri-state
Bus input/output
Passive
Usual ends of passive = components
Unspecified
Unknown = electrical type
Power input
Power = input of a component
Power output
Power = output like a regulator output
Open collector
Open collector often found in analog comparators
Open emitter
Open collector sometimes found = in logic.
Not connected
Must be left = open in schematic

obviously, seamless symbol interchange would be facilitated by = having equivalent categories of pin type.
gschema supports arbitrarily large = numbers of attributes for elements in a symbol, kicad does not.
This = is not a big deal since the harder work of drawing and pin labelling and = pin type designation is not duplicated/wasted effort.

I = wouldn=92t obsess on this. Pin types are secondary, only used for DRC = checking. And DRC checking is really dependent on the kind of circuits = you=92re drawing and the engineering tradition they represent. It=92s = not =93one size fits all=94. Geda-gaf=92s DRC checking really only fits = logic design with a single MSI family, which I suspect is only a = minority of designs. KiCAD=92s looks similarly limited, but with a = little more detail.

It wouldn=92t be terribly = hard to write a DRC back end for gnetlist that used KiCAD-style pin = types. That=92s the geda-gaf way: write a script to adapt the toolkit to = the flow.

John Doty Noqsi = Aerospace, Ltd.

http://www.noqsi.com/

jpd AT noqsi DOT com

= --Apple-Mail=_3232B2A5-4AF4-49EB-9F84-DCF3F4D41BDA-- --Apple-Mail=_73A74A32-C08D-4C61-9FFE-30AC07A08AC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWer4EAAoJEF1Aj/0UKykRfMMP/iAmq99DTyjDOXKDsIkI4Wq6 OFrb71AocBoM61Wo3zaVyxAZ00QUIzoOKEUO12mS9DZbYYPG/AdHWh4s2EPiSODH 0RrC+uvmDo2N53L/R8Ftu7+eNw0itGQmOP7VEuTtKM4bakaxBrMWk2wb1Mj5/w8O YrAisqBL7FCEh0FThknIdGGjkCA2p1AiibbIHTaCajK7RipUrqK73HkvHXj2CRZV kSgAEfllqMNr5xsaI79bAPAjreVmdBdei/pzWKodJI5Rs70gTI6dep2V8FXUFtCe BS9QenO0Knob7YgOKihMRQJhYT9NTFdhgBNWJKnmjHw3sW81Oq43enIRnCVh4dUd nqq0C+URXKEIupHvHL4pZ2tSWSgrHINLLXcex4EnnJSjT6mwH1cenQhv3boGuXMn rB451KHI/4EiWL/EOsWqUCQrTZd/b2sMkvkYw8dGhP0ZNyOJFEIs/oHmOdy0In5q hiMsXGTJjSH3ra/GiLlSwgu0QFGULE8qaf2uau84buAY4xXTCfgG+Bz16OmS+X+H emFsZAhPZ5bVrjLHHnydPuXHnOAgk1cZvnFrrkpaYfPw6aHLIUcvhOBCuc7CFUjs VfZl1Gi83IrhBkf/EnbYbUSLfQAvi06grhi0Jl8k5REFnMxUO8fTChOh31eqSxva ijZ62AFrV7NVD5urfE5y =Cmkp -----END PGP SIGNATURE----- --Apple-Mail=_73A74A32-C08D-4C61-9FFE-30AC07A08AC7--