kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

Hi,
I stumbled about a similar things with double-diodes. I see why it is done,
and this is one acceptable solution to the problem at hand.

But it is hard to navigate.

I have a long-term suggestion (that I am happy to help implement), and a
short-term suggestion to get things out of the door quickly for a stable
release, but helps users to not be confused and gives us a chance to
improve things later.

Longer term (after the next stable release), it makes sense to re-evaluate
data-structures. It would probably be best to simplify the proliferation of
symbols by separating symbol from pin assignments+possible footprints.

So associate the schematic symbol with a number of variant footprints,
which essentially adds a sub-relation, something like

  symbol (generic FET for instance)  ->  (multiple variants of assignment
to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)

(I think this is how it is mostly done in other tools as it helps to have
simple symbol _and_ a way to associate to a number of footprints). So each
symbol can have a number of separate logical to pin-assignment.

Main advantage for the user is, that they can see a tree view: they choose
a symbol, then the sub-variant that applies to their case (pin-assignment).
There or in pcbnew they then finally choose the package.

Anyway, details need to be hashed out and require some discussion. And
certainly not something to change now in preparation for a good next
release.

In the meantime, while that is not in place yet, how about this:

   - we store one optional additional field in a schematic symbol, think of
it as a 'tag' that ties symbols together into one family. In Adams'
example, that could be for instance "Q_PMOS". All the symbols are still
separate, but they have this 'unifying' field that associates things across
symbols. For the younger audience: think of it as a hashtag :).

   - The component chooser (which I have largely contributed in its current
form) can use this additional information to present these components under
one sub-tree. So the tag has no semantic meaning right now, it is only used
to better display things.

That way we have
  1) A much more 'logical' way to present these components to a user
without making their heads explode.
  2) Almost no implementation overhead for an upcoming release (and
importantly: very slim chance to introduce new bugs while stabilizing). No
data structure is fundamentally changed, but we just add another optional
field (most components never set this).
  3) a chance in the future to automatically adapt schematics to a possibly
new long-term data structure later.

If this sounds like an acceptable solution, I am happy to work on it.

-h

On 4 June 2015 at 20:23, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:

> Hi folks,
>
> I was using KiCad to make a board today (yeah, the novelty of actually
> *using* it!), and I noticed that there's been some changes in schematic
> symbols--and I'm wondering if it was on purpose.
>
> I was adding a pmos to my schematic, and I noticed there are:
>
> Q_PMOS_DGS
> Q_PMOS_DSG
> Q_PMOS_GDS
> Q_PMOS_GSD
> Q_PMOS_SDG
> Q_PMOS_SGD
>
> and the change is basically to change the pin numbers.
>
> Years ago, I thought it was that the schematic was a "logical"
> representation of your circuit, and the assignment of footprints to
> schematic symbols was where you chose parts, especially for things like
> fets.
>
> Is this a transitory thing, or is this the way we've chosen to set up the
> official kicad libraries?
>
> This isn't criticism, more something I was a little confused by and
> decided I'd check on.
>
> Thanks!
>
> Adam Wolf
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>