Re: gEDA-user: chip data directories in a library ( library packages )
On 05/24/2011 04:02 PM, DJ Delorie wrote: Mike Bushroembush...@gmail.com writes: As for names, data pack I like data pack. But the seed idea is growing on me too. Beats python eggs! They sound like a natural disaster in Florida... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
John Griessen wrote: But the seed idea is growing on me too. Beats python eggs! There is certainly a smell of coolness. But the entities don't act as seedlings. They are not self contained and they don't unfold into something bigger. Instead, many different of them are used as building blocks. They are precompiled sets of data the components of geda look into when they assemble a schematic, a layout, or a BOM. That's why I am still in favor of packet. As a bonus, this word keeps its pronunciation when translated to German (Paket), French (paquet), Polish (pakiet), Swedish (paket) and a number of other languages. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
But the seed idea is growing on me too. Beats python eggs! There is certainly a smell of coolness. But the entities don't act as seedlings. It was supposed to be a pun. Seed? Grow? :-P ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
I have not been following this closely, so let me make a guess at what the basics are, and in so doing through my little 2 kopecks worth in. If there were a combined, heavy library with both circuit element symbols and footprints contained within a single grouping for a single device, part number, group of related parts, so that from either gschem or pcb you could search for the root name of that part/device and be given a list of possible symbols to use in gschem (I know Atmel Atmega parts have differing numbers of pins based on DIP, TSOP, etc) and then the matching footprint (or footprints, if several package/mounting styles or sizes could still fit) would be stuffed into the element attributes. Or, if you were working directly in pcb, you would access the same library, search for the same root device name, and be given a list of all known footprints for it ( and possibly stuff the corresponding symbol in the element attributes incase you ever wanted to go backwards to gschem). This group, bundle, set of data might also include spice model data for the part (possibly once again linked to a package style). In either case, you could open up the linked data in either gschem or pcb to 'heavy up' the item you are working on to export the data to some other tool flow (does pcb to spice to verify the design make sense?) As for names, data pack would be similar industry standard data sheets. Technically, these would be data nodes or data branches or data clusters. You could even call them device seeds because they seed desired data into whatever tool path they have data for and you desire. Mike ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
Mike Bushroe mbush...@gmail.com writes: As for names, data pack I like data pack. But the seed idea is growing on me too. (sorry, couldn't resist ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On Sat, May 21, 2011 at 7:53 PM, John Griessen j...@ecosensory.com wrote: 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. I'd like to see that there is a many to many relationship. Example: You need a SO-8 footprint. With the footprint storage the relationships are a type of footprint backed by many footprints capable to fill the role. If it is directory and files there is a SO-8 directory with the x pcb footprint files that could be used to be a SO-8, like most, nominal, least, hand-solder, and etc. In a relational database plugin it could query for a footprint that provides SO-8 in the footprint table. This helps if you are say making a base schematic that may be made on many different types of boards, or purposes. When purposed it would get flattened and weighted with the particular process applied to it. Next example. For models in simulation. It is a mosfet, a 2n7002, there is a 2n7002 directory with a list of models for say guncap and spice. They also happen to be for different manufacture parts. In the package part it has a variety of parts that you may use, from lets say 4 vendors. The data store can let you simulate the circuit with each vendor, leading to confidence that your alternate parts are good. In lightening a resistor, I'd have the base parameters part of the symbol. Ohmic value, tolerance, power dissipation. This can then let the method of hevifying query a data store to help find your preferred parts. My thoughts on the interaction. Lets say that you draw out the topology of a circuit it has a micro controller and support parts. The uC is a medium weight part, it has the first variant chosen. The uC package is 33 pin or 64 pin part is not yet chosen, but the 33 pin symbol is the first variant, so it is displayed. A heavy part that is the connector that the board will use, every parameter is chosen when the connecter's symbol is placed. The rest of the parts are a bunch of light parts consisting of resistors, capacitors, and LEDs Now that the parts are placed and wired up. We then select the tool/wizzard/script that makes parts heavy, pretend were in the GUI mode and using the tool. So you click on the LED(s) that you want to assign parameters to. The tool knows that it is a LED, so it pulls up the dialog for making that part heavy. It has a interface into the datastore that we are using and I can start drilling down on the values. Kinda like digikey/mouser narrowing down parts. (To DJ's idea) this script might just be an interface to a CGI that is on a part vendors server. Now that the LEDs are taken care of, lets run the script that will make a schematic heavy to take care of the resistors and capacitors. In the schematic you specified the values and tolerances, so the script will take you preferred parts and assign them. The script might generate questions like you do not have a preferred resistor for value 100k at 10% tolerance, would you like to use the 5% tolerance you prefer? or automatically improve tolerances and just warn. Off to
Re: gEDA-user: chip data directories in a library ( library packages )
John Griessen wrote: I think the name package could create confusion with layout package used to implement a circuit, I proposed package because eagle uses this term for a very similar concept. Yes, package already has a distinct meaning in the context of electronics. I would not be happy with a variation of library. A lib is a collection of objects of the same kind -- traditionally books. What my proposal aims for, is by contrast a wrap of different classes of objects. The term container comes to mind. This clearly can contain about anything. Maybe, it is a bit too versatile. Worse, it usually means the containing structure, not its content. Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote: Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. Packet is a good one. If someone is confused they can be told library packet, or see it is in library context. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On 05/21/2011 11:35 PM, Steven Michalske wrote: So that wires that have the same meaning are still hooked up but new pins are unconnected, or old pins that no longer exist are now not connected. The other wish list ideas sound like where we are headed, but this last is probably beyond coder capabilities unless you know a good robodraw way to get it... John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On Sun, 22 May 2011 11:27:24 -0500 John Griessen j...@ecosensory.com wrote: On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote: Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. Packet is a good one. If someone is confused they can be told library packet, or see it is in library context. Package seems like the right word to me. I've run into at least a few instances where changing from one physical package type to another required a different symbol because the pinout is totally different. I recall one chip I dealt with where the signals physically stayed in place between PLCC and SOIC, but the pin numbering was rotated to move pin 1 from one corner to the center of an edge. Similar for some old DRAMs from back in the day, where certain ZIP packages had a totally different signal-pin mapping than DIP. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: chip data directories in a library ( library packages )
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
Re: gEDA-user: chip data directories in a library ( library packages )
I like the idea of creating a library group containing all info related to a manufactured part or part range. Library group? Or just a library? (not picking on the name, just wondering what you think the difference is, or why such a difference might be needed) Do we need to be able to group libraries? Or should we just merge them into a bigger library? 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. You think chips will be less confusing than package ? I think I'd rather make up a name than re-use a word so common in our field... But I'm not worried about names just yet :- 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. Yup. Don't confuse footprint with element, though. Elements should have all the appropriate metadata based on what actual part they represent in the design. How that metadata gets into them, we're still working on ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
