kicad-developers team mailing list archive

["Patrick" <pmaupin@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Wayne Stambaugh <stambaughw@...> wrote:
>
> Patrick wrote:
> > 
> > --- In kicad-devel@xxxxxxxxxxxxxxx, "Mateusz" <komorkiewicz@> wrote:
> >> It is also true, that in some cases (eg. ATMEGA8) the pinout of same devices is totally different depending on the package (DIP vs TSSOP).
> >>
> >> So we have to modify the component naming policy, the problem is, thiswould lead us to very long and distracting names (like atmega8-tssop32, atmega8-dip20).
> >>
> > 
> > I believe this could be handled with the part "variants" in the currentlibrary scheme. I think JP's original use for this was De Morgan gate equivalents, but pins can appear and disappear according to the variant, so you could have all the different variants in the same library entry, with thefunction mapped to a certain pin location, and the actual pin number physically present at that location changing depending on the chosen variant.
> 
> The DeMorgan conversion variant method has some serious drawbacks. As
> of now, it only supports two body styles the normal and the conversion.
> There is no support for assigning a different name to the normal body
> style and the converted body style.

The current implementation has some problems. Fair enough. I guess my main point was that, from a user-interface perspective, if I've done a design and then need to change a package, (a) it should not require hunting down adifferent .lib file for the same part (or should be very easy to do from the "edit component" menu, and (b) when I do find the different part, it should just drop into the schematic without me having to move wires around to hook up to a different .lib footprint -- the only thing that should be different between the two footprints is the variant name and the pin number to location mapping.

This seems like exactly the sort of problem the variant system was designedto solve, which led me to the possibly erroneous conclusion that using it (and fixing any shortcomings like variant naming and number of allowed variants) might be the way to go. I thought that a new library file format wasgoing to fall out of this work. If that is the case, it might not be thathard to address the number of variants/name of variants issues.

Or it might be, as you suggest, that the right thing to do is to strip the variant system completely or at least rework it into something completely different.

Regards,
Pat