kicad-developers team mailing list archive

["Paul \"LeoNerd\" Evans" <leonerd@xxxxxxxxxxxxxx>]

On Wed, 30 Mar 2016 12:22:48 +0100
"Paul \"LeoNerd\" Evans" <leonerd@xxxxxxxxxxxxxx> wrote:

> <for ease of replies; continued in part 2...>

and now on to the more generic "where KiCad could be improved" part of
this problem...

-----

As a further consideration, this leads into the area of KiCad that I
dislike, and that's the way that schematic symbols and part footprints
are so intertwined like this. Nowhere is it more apparent how annoying
it is, than in the area of transistors.

Suppose I'm just sketching out a circuit, and I decide I need some
bipolar NPN transistor. I haven't decided yet exactly what part I'm
going to use, so I certainly don't know its pinout yet. It'll be some
sort of small-signal NPN perhaps. I don't want to commit to a
particular pinout, I just want to place "an NPN transistor" in the
schematic. Later once I've played around with maybe half a dozen of
them on my breadboard I might finally decide on some specific part,
maybe a BC549, so now's the time I commit to the shape. I want to
notate that at the time I run cvpcb *and not earlier*. Once I've
associated footprints, only now does any consideration of which
schematic pin (B/C/E) is which physical pin (1/2/3). Depending on exact
parts, these logical-to-physical associations could be done any of six
different ways.

The problem is that KiCad doesn't let us arrange schematics and
footprint parts in a nice generic way. In KiCad we're forced to either:

  A) make six different NPN transistor schematic symbols

  B) make six different e.g. TO-92 transistor footprint parts

This isn't very nice.

Taking a look at e.g. what Eagle does here, they have a 3-way split:

  *) A single schematic symbol of simply "NPN transistor", with pins
     named B, C, E.

  *) A single PCB footprint of simply "TO-92", with pins numbered 1, 2,
     3.

  *) A "component" which associates a schematic ("NPN transistor") with
     a footprint ("TO-92") and provides the pin mapping E=1 B=2 C=3

This is great, because adding new kinds of NPN transistor means never
having to draw that schematic symbol again - you just associate it with
new footprints (or maybe the same footprint with different pin
mappings). Adding new TO-92-shaped components means never having to
redraw that footprint - you just associate it with new symbols (maybe
some 2-pin current sources that come in TO-92 cases with one pin
unused). Overall, it minimises the amount of work needed to add new
parts.

I would love KiCad to have something similar like this. I find it very
disheartening to have to copy an existing schematic symbol or footprint
part when all I want to do is change the pin mappings between them.

How I think it could be done, is to somehow start to break the enforced
requirement that schematic and part pin names must match. One idea is
that a footprint part could in fact just name another part and provide
some pin renamings. For example, under this hypothetical scheme, I
could define a footprint part for a BC549, which is simply

  (component Transistors:BC549
    (module Housings:TO-92)
    (pin-mappings (map 1 E) (map 2 B) (map 3 C))
  )

and then nobody has to *copy* the TO-92 footprint, because it's only
referenced by name. Someone then draws an NPN transistor schematic
symbol whose pins are given the obvious B, C and E names; someone draws
the TO-92 footprint whose pins are numbered 1, 2 and 3. Then when I
select "Transistors:BC549" in cvpcb it now knows how to associate those
virtual pin names into physical pin numbers.

The upshot of this model is that it doesn't break anything currently -
existing 1:1 mappings that go directly from schematics to parts
continue to work unaffected. But now it means people can place "a
transistor" or "a diode" or whatever generic parts, and only later at
cvpcb time do they have to know what pinout details apply to the
selected component.

Who's with me here?

-- 
Paul "LeoNerd" Evans

leonerd@xxxxxxxxxxxxxx
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS

Attachment: pgptn7l8YylzB.pgp
Description: OpenPGP digital signature