[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
Thanks for all the hints on working with the current tools.
Still my current concern is how I get gparts working with PostgreSQL and
I found
these BUGS:
*) configure doesn't react in a sensible way to a missing MySQL
installation.
It records "no" version and then make happily tries to compile the
mysql-backend.
*) If more than one backend is supported, the system must decide somewhere,
which database to use. Therefore I had a look into gparts-database.h and
line 34 is
typedef struct _GPartsDatabase GPartsDatabase;
but there is no "struct _GPartsDatabase" in the entire source code. -
does this compile?
I think at least when the compiler tries to resolve a function call
containing "GPartsDatabase"
the bomb should blow up.
Is there a special support for databases in glib/GDK/GTK?
If not, why (the fucking bloody hell) is 'database' (declared in
gparts-login-ctrl.c#416)
initialized with g_object_new() - remember, it's a pointer to a
structure, that's type is not defined?
Tbh, the code is difficult to comprehend for me, since it's "ravioli
code" and/or "objectfuscated C"
and has near 0 comments and no paper describing the overall internal design.
Some comments on the why DB at all follow:
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.
If it's a mistake to use it, the problem is with the library...
* 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.
John, while I value you knowledge, rest assured, I understand the
attributes to describe a relation.
.sym files as of now (and hopefully never) don't have the relations I
want (because the symbol
is the wrong place to store this).
Except that we already have much more than you recognize.
C let you shoot in your knee - with C++ you can even reuse the bullet.
In a way your
sacred files have the same property - a database has mechanism, that prevent
at least inconsitencies - do you recognize this?
Why not express that mapping as a set of .sym files?
Because enumeration of the values of one attribute with otherwise
redundant structures
is exactly what I want to avoid. There is nothing that tells the engine
that symbol
foo-hu.sym is in any way related to foo-ha.sym - they by chance have
some common
properties. This is not a relation.
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.
Think this is the 1st time I see explicitly stated, that an attribute in
the schematic can override
the value in the symbol. Thanks (docu-writes start bashing me as well
now or fix this ;-)
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...
So the physical pin designation by the datasheet is say "V_CC", while
the functional pin designation
would be "V_CC" ? Those manufactures must be idiots like me - I never
had any trouble reading
their datasheets. And now you tell me, ideally a DIP-14-footprint has a
pin named V_CC, because
that is what gets related to the pinnumber in the symbol...
And then pinseq is, unfortunately, overloaded.
1. It serves to identify the pin for the slotting mechanism.
Just to confirm my understanding by exampl - for a quad-NAND-gate I
would have then:
nand_a.sym, nand_b.sym, nand_c.sym, nand_d.sym and nand_pwr.sym
that I can individually place in the schematic. They get mapped to 1
footprint by the
pinseq-attribute AND the "pcb ignores trailing lowercase-chars in
refdes"-quirx.
This imo supports, that a 7400 should be expressed with a device-entity,
that has
symbols attached, not the other way round. You ask below, why not
express this
in symbol-files: because the symbol->footprint thing lacks (a) layer(s)
of abstraction.
Btw. what happens, if I assign different footprints to nand_a.sym and
nand_b.sym
in the schematic?
What happens, if I don't use nand_c.sym at all, because I need only 3 gates?
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.
I can live with a file "7400.dev" containing
...
symbol=nand_a,nand_b,nand_c,nand_d
pinmap=nand_a:3,4,5;nand_b:6,7,8;... <-- should the symbols use 1,2,3 each
...
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user