On 05/21/2011 08:09 AM, Kai-Martin Knaak wrote:
The notion of packages can be seen as a means to isolate dependencies. Pins in symbols must match pins in footprints. Simulation models are specific to components. Packages provide a way to keep comments, notes and all kinds of meta data attached.
I like the idea of creating a library group containing all info related to a manufactured part or part range. I think the name package could create confusion with layout package used to implement a circuit, some of which have different numbers of pins, so what do you all think of this name for a library group: In the context of a library call them chip data directories, or chips for short. The chip data directories could also be compressed a standard way for ease of distribution. Some library elements don't match the word "chip" perfectly, such as resistor capacitor terminal block, etc, but people can figure from the context what was meant. On 05/21/2011 08:37 AM, DJ Delorie wrote: > I don't think we've come to a consensus on how to ease the > heavyification step yet, though, which may require a great deal of > coding and redesign. The data dir in a library concept seems to make heavification easier. I'd always want to be able to heavify the symbol or footprint first, then use a script to make them all consistent, not have to do symbol then footprint in that order only. Names keep coming up as I think about relating symbols and footprints and adding heavy data to them. If symbols are not necessarily files, I'm used to the file name being the symbol name or footprint name -- it just seems "normal". If a symbols or footprint was just a text section in a larger file, I'd be OK with that, and it would need tags like symbolname="some-kinda-name" or footprintname=some-kinda-name". We could easily agree to shorten that down to tags like: symbol="some-kinda-sym-name", footprint=some-kinda-fp" without even needing filenames with suffixes .sym .fp. On 05/21/2011 06:45 PM, DJ Delorie wrote: > But what I was thinking was, for example, having NAND2.sym be a > generic 2-in NAND gate, SO14.fp be a generic soic-14, and the metadata > would be SN74LVC00ANSR.part. The metadata would have symbol=NAND2, > footprint=SO14, pinmap=[(A,B),Y]=([(1,2),3],...), etc. I like that. I've been thinking in the past-way-of-doing-it-box and I've decided there's not much reason to want to add metadata to a footprint if you have a connection between footprint and metadata made by them being in a data dir container. Doesn't matter what container. John Griessen _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
