kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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

> 
> Perhaps this is something already envisaged?
> It will be useful for people who use micro with an inordinate amount
> of peripherals multiplexed to the IO pins. It is much better to just
> include the intended peripheral in the pin name as opposed to trying
> to list all of the peripherals on that pin, or just the port name.
> This could be done in a project specific library.
> 
> Thanks for everyone's efforts in taking on the big changes, it'll make
> things so much better for KiCad and the S-Expression format is really
> nice to read so I'm sure it'll be very popular.
> 
> Best Regards,
> 
> Brian.
>