[gta02-core] KiCad wish list

[Werner Almesberger]

Rene Harder wrote:
> How can you do this with Kicad, I was looking for this function quite
> some time but could not find a way to do it.

I made a little example:
http://svn.openmoko.org/developers/werner/gta02-core/foo/

That's basically an NPN transistor. (Just kidding about the triple
inversion.)

> > However, then you'd get a function-specific footprint (e.g., a
> > SOT-323 for BJTs with pads labeled B, C, E), which isn't so nice.
> >   
> Why do you think that's not nice, I prefer labels with B, C, E, because
> then I know the function immediately without checking the data sheet.

Oh, I like the labels, particularly in the schematics. What I
don't like are function-specific footprints. I don't really
want an SOT-323 for this NPN, one for another NPN, then one for
PNP, one for the Jabber, another for the Wocky, and so on.

What this would basically do is push the problem we currently
have at the schematics level down to the footprint level, but
without really resolving it.

> Remember our problem with the dtc123 transistor, there are many vendors
> with different pin numbers and footprint but the pin labels were almost
> the same.

Yup, but we have three places where we can solve this:

- the symbol, as we do now
- the footprint
- or by introducing a mapping layer

The problem is that you don't only want to make the association,
but you also need to be able to verify it. If it's "hidden" in
the footprint definition, you need to check schematics, data
sheet, and the footprint to be sure things are right. If at least
the footprint is generic, you don't need to look up that one.

Besides, footprints are harder to check than schematics drawings,
because it's generally harder to associate those pads with a
function. You can do so reasonably well if working in pcbnew
interactively, because it will identify things for you, or even
point you to the right spot in the schematics, but extracting
this information from a printout is hard.

I kinda like the idea of a mapping layer. That could feed the
"generic" pin number back to eeschema, so the correct number
would be displayed, yet you could still use a generic symbol,
with symbolic names.

> Well that's exactly what the device layer should do (or does in eagle).
> You have a symbol with function specific names, and footprints with
> vendor specific numbers the device layer links function of the symbol to
> vendor specific pin number. For each device you can add a vendor
> specific description and and a package specific suffix.

Okay, minus the vendor specific footprints, I like that.

If someone feels like proposing it to the KiCad list, or even
implementing it, that would be nice. I think what you need are:

- a new "magic" field in the symbol that identifies the name of
  the mapping file

- a mechanism that, whenever KiCad wants to know the pin number,
  goes to look it up by the pin name in the mapping file. The
  field could then also be placed in the schematic to show that
  a mapping is being used and what it is.

- some way to edit mapping files (not sure if "just make a text
  file with vi" would be welcome)

Not trivial, but shouldn't be too hard either. It's nothing we
need for gta02-core at the moment, but it could make life easier
in the future.

- Werner