On May 2, 2010, at 5:21 AM, Armin Faltl wrote: > >> I'd avoid data base solutions for footprints, symbols, simulation models and >> the like. > Appart from my attempt to come up with my own table layout, I try now to get > gparts working. > It's an independent tool like gattrib and you are free not to use it. > The idea of the tool is, to describe the relations between the entities you > mention. > You are also free to do searches among the thousands of little packets some > of them > with wrong lables as of now by hand.
But you don't have to struggle so much if your project symbols are organized. The mistake to avoid is using the library symbols directly. > >> * Unless there are excellent import/export functions, a data base is an >> additional obstacle to collaboration. These functions need to be written and >> maintained- >> > Inventing yet another cryptic file spec to describe the relations is even > more obstructive. By this reasoning, gparts should work with the project symbol files. We are already using this file spec, and it has already proven its value, comprehensibility, and flexibility over and over. The problem here is that few seem to recognize that it is perfectly sensible to see a .sym file as a container for a relation. >> * Only a very small subset of the operations available on file systems is >> present by default in data bases. Just to get the same level of user power >> as with files, a major effort of data base scripting is needed. >> > ??? >> * A data base can easily be corrupted on update of the data base driver. >> > A file backend driver on changes of the file format can mess up as well, esp. > if one tries > to reuse some parts of the parser. So can format converters of any kind. >> * Open source data base drivers like postgres or mysql may be quite mature. >> Compared to the stability of the unix file utils they still look shaky. And >> fast moving. >> > The implementations are evolving. The good thing is, there is an > ANSI/ISO-standard called SQL99 > and that is stable and more than sufficient to describe what we need. >> * A data base would add a major dependency to the already significant set. >> > True. For me still a lighter burden, than to implement the functionality of a > database engine. Except that we already have much more than you recognize. >> * The number of all objects in the library is fairly moderate. All symbols >> and footprints from the distribution plus all of gedasymbols are currently >> about 4300. This can easily be handled by a file system. >> > Even the millions of parts with their several packages each could be handled > by a proper > directory tree. It's the connections that are the problem and a database > expresses them > implicitly. (there is no such thing as a "symbolic half-link" that connects > to everything > that happens to have "the other half" ;-) > > As the name "gparts" suggests, the databases main objective is not to map > symbols to > footprints but to map vendor-parts to geda-aggregats. Why not express that mapping as a set of .sym files? > > Independent of this post of Kai-Martin I've thought about how to express the > relations > in the files we have now. Heavy symbols are restrictive and don't really do > the trick. > E.g. just now, I'm in the situation to work from a breed board towards a > series-board > and in this process may replace throughhole resistors with SMD. I will guess you let the defaults in gEDA take you down the usual low-productivity path: 1. You used a library resistor symbol by reference rather than making a project copy. 2. Then, of necessity, you attached footprint= attributes to each instance instead of your resistor symbol instead of placing a footprint= symbol in your project symbol. Your situation is very familiar to me, and is precisely why I use the project symbol collection approach for any large gEDA project. > It's clearly undesirable to replace the symbols in my schematic. Likewise > it's very > tedious to replace footprint attributes in the symbols and error prone as of > now. > And then I may not want to replace all the through-hole parts because I like > the > via-functionaltiy of their legs or because I can put more traces beneath one. Use attached attributes at the schematic level to override your project symbol's attributes. Or make another symbol, substitute. This is another thing that's easy, but clumsy with the existing GUI. > > What one needs is an abstract description of the pinout of a component. > This pinout can be embodied in several packages. This I think, is what the > device attribute is really for. This won't catch all cases, therefore a direct > connection from symbol to part should be possible. > Reading the article on transistors > (http://www.geda.seul.org/wiki/geda:transistor_guide) > the example of "the same transistor" being available as TO and SOT package, > the concept of freezing package pins to symbol connections breaks down > completely. > - I never understood the difference of pinnumber- and pinseq attributes in a > symbol. > As far as I can tell, the number is redundant to the seq and used for nothing. > It would be intelligable, if the number were used for the netlist and using > the same number for different seq's means, the physical pins denoted by seq > are electrically connected. This of course doesn't go well with the rendering > of symbols as of now. No, that's not how it works. The pinnumber is the physical pin on the footprint. It doesn't really need to be a number. Ideally, it should match the physical pin designation on the manufacturer's datasheet for the package (while pinlabel should match the functional pin designation). Except different manufacturers use different mappings... And then pinseq is, unfortunately, overloaded. 1. It serves to identify the pin for the slotting mechanism. 2. It orders net connections in the positional component-centric netlist formats, SPICE and Vipec. > Therefore, the whole business may be moved into a device-entity, that maps > the electrical connections of a part (that are represented in a symbol) to > the physical pins of its package. (I know this has been described before) Except that can already be described by the symbol file, so why have a redundant way to do this? I'm not sure what the correct approach is here. These days, too many users seem to want separate, labelled things like "databases", rather than seeing all the isomorphisms that make life in the technical world simpler, better connected, and easier to comprehend. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
