> On Jun 5, 2015, at 10:01 AM, Henner Zeller <h.zel...@acm.org> wrote: > > 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.
That all seems way too complicated. Footprint pins should be numbered in the standard way. Since a footprint can be used for many many completely unrelated devices, there is no point in making the pin function part of the footprint. I mean, an SOIC-8 can be used for op-amps and SPI DACs, and nobody proposes an op-amp SOIC-8 footprint and an SPI DAC footprint, right? So why have a dozen different variants on the TO-220 with the attempt to support different voltage regulators and MOSFETs and BJTs and what-not? It’s crazy. The schematic symbols already have the capability of giving a pin both a name and a number. So if you want to have your transistor’s pins named E, G and C, you can do that, and just make sure that you map the pin function to the footprint number. Yeah, I realize that too many people want to place a generic NPN on the schematic, but how hard is it to create an MMBT2222 (where part name implies both function and footprint), anyway? I realize that there’s an argument that goes, “Well, the library will be super big if we want to support all of the possible transistors out there.” And that argument is silly. Does anyone use a generic op-amp symbol instead of placing a TL072ACD (there it is again, symbol name calling out footprint!) on the schematic? No, of course not. So why is that OK for transistors? harrumph. back to work! -a _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
