kicad-developers team mailing list archive

[Heiko Rosemann <heiko.rosemann@xxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/2014 11:29 AM, Nick Østergaard wrote:
> 2014-04-05 11:09 GMT+02:00 Vesa Solonen <vesa.solonen@xxxxxxxx>:
>> 05/04/14 01:23, Heiko Rosemann kirjoitti:
>>> On 04/04/2014 10:45 PM, Carl Poirier wrote:
>>>> I think this is a very good idea. I will add this to our
>>>> upcoming KiCad library convention. Many transistors use
>>>> letters already.
>>> 
>>> I do not agree for footprints, because - at least if I
>>> understand the proposal correctly - it will lead to many many
>>> different footprints of the same housing, i.e. an SOT23-EBC, an
>>> SOT23-SGD (for FETs), an SOT23-CBE, an SOT23-A1-C-A2, an
>>> SOT23-A1-C1A2-C2 etc. pp. with all the same dimensional data
>>> but different pad names.
>> 
>> This is the current state, because of the limited data model. I
>> agree with you that it's not how it should be. Regarding diodes
>> one can get _any_ orientation single ones in SOT-23
>> 
>>> I came to kicad from Eagle some years ago and I still believe 
>>> distinguishing between symbol-package-device to be the best 
>>> solution for this problem.
>> 
>> Second that. The implementation inside Kicad is not there yet.
>> The symbol is somewhat hard linked to the footprint (because
>> symbol have to contain matching pin numbers) and even the alias
>> system can not solve the issue.
> 
> I never really started to use eagle beacuse of its wierd library. I
> do like that the symbols are seperate from the footprint in kicad.
> (Or at leat tries to)

I fully agree. Only the relation between symbol and footprint(s)
should be described in "device description data" as Vesa puts it, not
the footprint itself. And it should still be possible to live without
the "device description data", just by connecting the pins and pads by
hand.

>> Pin-pad-mapping is expected to contain all gate and pin swap 
>> permutations for devices that allow it, simple devices like 
>> bidirectional TVS zeners and resistors would just have x as a pin
>> name for interchangeable ones.
> 
> I have a hard time visualising this workflow. I like the idea of
> your DDD, but how or where is the pin-pad-mapping defined? Is this
> defined in a cvpcb-like step? I see that the pin-pad-mapping
> definition elliminates a bunch of the same symbols ans footprints
> with each of their all possible pin combinations.

I believe that should be defined in a third set of library files.

Let me sketch my ideal workflow:

For a schematic, I would like to have the choice between either
placing a symbol (i.e. "DIODE", option 1) or a device (i.e. "1N4007",
option 2).

For the first option, I'd envision a cvpcb-like step for choosing a
device for it (i.e. "1N4007", option 1a) or a footprint (i.e. "SOT23",
option 1b).

Choosing a footprint (option 1b) would mean I could (and would have
to!) connect A and C to any of the footprint's pins (1-2-3), giving
extra flexibility for some strange part, but I wouldn't want to do
that for more than a handful of parts, and I would like an option to
save the pin-mapping as a "device" file into my "device" library.

Choosing a device in this cvpcb-like step (option 1a) or already when
placing the symbol (option 2) would basically mean taking the
footprint information and this pin-mapping information (and maybe
optionally a spice model, a datasheet...) from a pre-existing "device"
file, for many devices probably including several pin-mapping and
footprint options (think of a microcontroller available in PDIP, SOIC,
PLCC, BGA, or any kind of device in TO220 package, which can be placed
vertically or horizontally)

Current kicad is coming close to this, "only" missing step is to
differ between pin names in the symbol and pad names in the footprint
and offer some linking between the two (more advanced than adding the
"preferred footprint" to the symbols).

The cvpcb-like step would need to include some very powerful filtering
options for this workflow to run nicely.

Let me stress that I'm not writing this as a "please someone implement
this" eMail, it's just a few thoughts about what I would consider most
helpful.

>>>> As for capacitors, why not also using C and A for cathode
>>>> and anode?
>>> 
>>> In my experience, the terminals of a capacitor are not called 
>>> cathode and anode.
>> 
>> Only polarised (electrolytic) ones will have cathode and anode,
>> but elsewhere that would be misleading.

OK, I'm no native English speaker, and I just felt the terminals of
polarised capacitors were called something like "plus" and "minus" as
with batteries, couldn't recall seeing the names "anode" and "cathode"
for them. But there's much I haven't seen in this great big world, so
don't let me fool you ;)

Best Regards,
Heiko
- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEUEARECAAYFAlM/3FYACgkQ/Vb5NagElAXt0ACYuGosKvSiKxeADJObaIaUVeJ+
9ACdGjKqgjPGPbOJl+DmkXE3L3lqYTg=
=P7bx
-----END PGP SIGNATURE-----