kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 15 December 2010 14:41, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> On 12/15/2010 7:19 AM, Brian Sidebotham wrote:
>> On 14 December 2010 22:49, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>>> I made some ,inor changes to clarify inherited vs base part and changed
>>> LPID names reflect local naming convention as suggested by Dick.
>>>
>>> Wayne
>>>
>>> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote:
>>>> I know all of you've been on the edge of your seats waiting for the the new
>>>> part file format since Dick announced his plans to start working on the
>>>> distributed library.  So without further ado, attached is the preliminary copy
>>>> of the library part file specification.  Please take a look at it and make sure
>>>> I didn't forget anything.  I have tried to accommodate all of the previous
>>>> library discussions as best I could.  If I missed something, it wasn't
>>>> intentional so please let me know so I can revise the specification.
>>>>
>>>> Initially, I would like keep the discussion focused on what is missing and how
>>>> it should be implemented.  Please keep the discussion on semantics like "I
>>>> would rather use thickness instead of line_width" until after we've hammered
>>>> out all of the technical issues.
>>>>
>>>> Once we have a consensus, I will convert the document into a more formal format
>>>> similar to the current file specification documents and commit it to the
>>>> documentation repo since that is were the rest of Kicad's documentation resides.
>>>>
>>>> I know it's been a long time coming so thank you for your patience.
>>>>
>>>> Wayne
>>
>> Hi Wayne,
>>
>> I just got a look through the doc. I have a few questions/observations for you:
>>
>> (1) If I browsed a library for a part which contains all of the parts
>> information below the line:
>> # This is an example of a dual input NAND gate A of a 7400.
>> in the document, does this mean that I would see all of the parts for
>> selection? i.e. dual_input_nand_a, dual_input_nand_b,
>> dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a,
>> dual_input_nand_demorgan_b, dual_input_nand_demorgan_c,
>> dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR
>>
>> I would have thought there would need to be a way in the syntax of
>> showing what was a selectable/finished part and what was merely a
>> "symbol" or partial part which should not be allowed to be entered
>> into the schematic directly.
>>
>> Ah, actually, I see you might be using the value field for this
>> purpose. Only values are selectable parts perhaps?
>>
>> (2) I could see a pin rename function being handy. At the moment it is
>> possible to delete a pin and then add a new pin in, but this would
>> mean re-defining all of the other pin properties.
>>
>> (pin_rename NUMBER NAME)
>>
>> Another method might be to have overriding of pin attributes. For example:
>>
>> (part “dual_input_nand_a”
>>   (reference “U”)
>>   (pin input line (at -600 100 180)
>>     (name “” (font (size 60 60)) (visible yes))
>>     (number “1” (font (size 60 60)) (visible yes))
>>     (visible yes))
>> )
>>
>> (part “dual_input_nand_b” inherits “dual_in_nand_a/rev1”
>>   (pin_del 7)
>>   (pin_del 14)
>>   (pin_renum 1 4)
>>   (pin_renum 2 5)
>>   (pin_renum 3 6)
>>   (pin (number "4") (name "D"))
>>   (pin (number "5") (name "E"))
>>   (pin (number "6") (name "F"))
>> )
>
> Brian,
>
> Pin renaming makes sense to me.  I would like to keep the item_action concept
> for consistency.  In other words:
>
> (pin (number "4") (name "D"))
>
> becomes
>
> (pin_rename "4" "D")
>
> If you don't have any objections, I'll update the specification.
>
> Wayne

Hi Wayne,

Yes I think that is the best and neatest method, I'm sure it'll be useful.

Many Thanks,

Brian.