kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/15/2010 06: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.

Brian,

This is a good observation, about the readiness of a part.  (Don't mean to butt in,
since you asked Wayne.)

Three possible solutions to keeping a part off limits for instantiation:

1) Mark the part as not ready for prime time using Sweet.

2) The part parser is dancing through all these part body expressions.  Rather than
the user saying in syntax that the part is not ready for primetime, it may be possible
for the parser to reach such a conclusion and then reflect this in a class PART::state
field, indicating that it is syntactically correct, but incompletely specified.

3) We may also be able to do this based on library "category".   Categories within a
library are directory like partitions, and although I had originally thought that they
would apply to all libraries except the parts list, in the last two days I have been
wondering if we may be able to or should have them there also, as a tabbed
spreadsheet.  (The UI paradigm of the parts list is going to be a challenge, it has to
be useable.)

Remember, the only parts that can be instantiated are those in the parts list.  So
this brings up a fourth option, which is to say that only prime-time ready parts (i.e.
instantiable parts) can go into the parts list.  That may be the best option of all. 
My least favorite is 1).

But the conversation extends then not merely to instantiation, but also to extension. 
For extension, the derived part may live in the parts list, and all base parts have to
be available for extension, regardless of their library of origin and regardless of
their completeness.  So any picklist UI has to show all of them.

Dick


> 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"))
> )
>
> 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.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>