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