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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
