kicad-developers team mailing list archive
Mailing list archive
Re: Re: Libraries - files and components naming policy
> --- 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, this would 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 current library 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 the function 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. So in the atmega8 example above is
the normal body style the DIP package and the converted body style the
TSSOP package? I think users would find this very confusing. Also,
there is currently no way to assign a different footprint to the
conversion style. Personally, I think naming the component atmega8-dip
and atmega8-tssop is fairly descriptive. I would drop the pin count
from the name unless there was a dip40 and a dip32 of the atmega8. The
alternate body style concept is confusing. I would rather drop the
alternate body style support from the library and just create a separate
DeMorgan component library. If you never used Kicad before and was
looking for a DeMorgan representation of a component, the DeMorgan
library seems like the obvious place. It's not obvious that there are
DeMorgan body styles embedded in the 74xx component library.
> In this case, you would simply need a way to associate allowed packages with allowed variants, in order to keep the pin numbers correct on the board.
> This doesn't solve the problem per se, but I think it does push it down closer to where it belongs -- I ought to be able to change the package in the schematic without pulling in an entirely new component.
> Yahoo! Groups Links