kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #07550
Re: sorting pins in .lib files
On 23/02/2012 23:11, Wayne Stambaugh wrote:
> On 2/23/2012 4:18 PM, Dick Hollenbeck wrote:
>> On 02/23/2012 03:01 PM, Laurent GONZALEZ wrote:
>>> hi there,
>>>
>>> I am a very new user to kicad, and at my first try something bugged me.
>>>
>>> When creating a big component (mine is TQFP100), I find it very useful
>>> to tap directly into the .lib file to tune labels, pin position, etc ...
>>>
>>> Unfortunately, when a hand modified component is re-imported into the
>>> library editor, and saved, most of previous efforts to sort pins are
>>> void, which makes the .lib file difficult to read back.
>>>
>>> After having a look into the code (thanks doxygen), I think that the
>>> DoCompare method for pins is worth to be modified, in particular
>>> regarding how m_number members are compared.
>>>
>>> My guess is that m_number must be sorted alphabetically until numeric
>>> digit are encountered. Then, a numeric part must be compared as a
>>> number. The goal is to sort correctly A9, A10, B9, B10 on a BGA chip.
>>>
>>> Of course, I would be happy to propose a patch, if other share my
>>> opinion about this improvement.
>>
>> Of course, a person could want the pins sorted by spatial location, or not want them
>> sorted at all, keeping order of entry.
>>
>> So this could use some discussion.
>
> I don't have any strong feelings about the sort order one way or
> another. However, IMO sorting does make it easier to read for a human.
> Take a look at LIB_PIN::DoCompare(). Note that the m_number member is
> a long integer that is treated as four ASCII characters but the
> comparison is by integer value. This is one of the things I've always
> wanted to do away with in the library pin object. I just never got
> around to it.
>
Yes, that's exactly that weird comparison of string using integer that
bugged me. It is endian dependent and counter intuitive because it makes
30 < 21 < 12 on LE machines (most of ours are, aren't they?). Do we want
to relax the constraint on the 4 char size ?
I propose to start with getting rid of that mess, and see later whether
we want to introduce more flexible scheme, maybe that would give
priority to pin name, or location in the drawing.
Follow ups
References