kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/15/2010 08:35 AM, Wayne Stambaugh wrote:
> On 12/15/2010 8:49 AM, Dick Hollenbeck wrote:
>> 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.)
> Brian,
>
> Good catch.  I hadn't actually thought about that.
>
>> 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.
> My preference would be solution 2.  If we change our minds as to what defines a
> valid part, we only need to change that in the library code.  If we implement
> it as a new part file element, we would have to change it in every part file.
> It also creates additional syntax for the part file.  One of my primary goals
> was to keep the part syntax as clean and readable as possible so I will be
> reluctant to add anything that can be solved in code.  It should be easy enough
> to have the librarian only display valid parts for inclusion into a schematic.
>
> Wayne

Right, I should have given my 4th solution a number 4).  Definitely 2) is needed, and
the good news is 2) and 4) are not mutually exclusive.  You could not implement 4)
without 2).


For 2):

During parsing, and in the Inherits() method, we can set bits in a "contains" bitmap int.


class PART {

int contains;    // completeness bits

Parse( PARSER )
{
    if( tok is extends )
        Inherit()  // binary copy from base, *copy base's "contains" veratim*
                    // along with inherited fields

    // go on to parse other stuff.  Each time we see a major categorical
    // item, OR in a bit into "contains".

    // Then anding contains with some completeness mask at the end of parsing tells
    // what's there.

}

}



Wayne,  I was looking forward to your answer to Brian about his pin rename suggestion.



Dick



>> 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
>>>
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>