Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")

[John Doty <jpd@xxxxxxxxx>]

On May 6, 2010, at 6:17 AM, Armin Faltl wrote:

> 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?

So polite.

> 
> 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...

It's not a mistake to use it, it's a mistake to use it in an inefficient way ("directly" by reference to the symbols, although unfortunately that's how the GUI encourages you to work).

> 
>>>> * 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

What you want seems to have little to do with what gEDA can give you. You seem to be focused on some private notion of how you want to travel. Give up that notion, learn to use the toolkit instead of fighting it, and you'll find it can get you to useful destinations quickly and efficiently.

> (because the symbol
> is the wrong place to store this).

Depends on the information and the flow. For one of my projects I do some trivial postprocessing of the BOM with an AWK script to get part numbers from specs using a simple TSV "database". But the complexities of a general-purpose DBMS need not be imported into the relatively simple problems we have.

> 
>> 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?

Note that what's "inconsistent" depends on the objective. DJ, for example, likes to use the slotting mechanism as a general-purpose pin number remapping mechanism. But to some it's "inconsistent" to have slot=6 on a 4 slot part. Part of the power of gEDA is that it *doesn't* enforce such things on the user.

> 
>> 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.

No, but it does relate the graphics to the attributes. And since the attribute mechanism has no limits, it can express such higher level relations.

> 
>>> 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 ;-)

Perhaps to those of us with EDA experience this is too obvious. It is implicit in in the examples, and in the way the attribute editors work. It's probably in the docs somewhere.

>>> 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",

No, the pin designation on the *package* datasheet (for example http://www.xilinx.com/support/documentation/package_specs/fg484.pdf) is something like "B17". Thats what belongs in pinnumber. Now, for some particular device that might be Vcc. That belongs in pinlabel.

> 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...

No, you didn't read what I read. Package and device datasheets are different things.

>> 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

No.

> 
> that I can individually place in the schematic.

Start with 7400-1.sym from the library. Edit as needed to represent your quad NAND. Place an instance. Change its slot attribute as needed to get the right slot out of the four defined. There's even a special Edit->Slot... command in gschem for this purpose.

7400-1 has implicit power pins. If you don't want that, remove the net= attributes when you customize it, and use Kai-Martin's 74_pwr.sym from gedasymbols.org for explicit power connections.

> They get mapped to 1 footprint by the
> pinseq-attribute

No. Pinseq identifies pins for pinnumber remapping for the different slots. Symbols get mapped onto one footprint in gnetlist by having the same refdes attribute.

> AND the "pcb ignores trailing lowercase-chars in refdes"-quirx.

There's an additional mapping that happens in pcb.

> 
> 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.

You don't even understand how it works. And there's a fine line between abstraction and obfuscation that we should not cross. One advantage of the current approach is that it can be used in pretty simple, concrete ways for simple projects.

> 
> Btw. what happens, if I assign different footprints to nand_a.sym and nand_b.sym
> in the schematic?

Ignoring your misconception, there is a real problem here. A well-known bug causes gnetlist silently to use the footprint from the first instance of a given refdes it encounters, or to use "unknown" if that first instance has no footprint. The fix is controversial: I see the problem as one of factoring in gnetlist, but others just want to patch over it.

If you use pcb's trailing letter trick, it may notice footprint conflicts since in that case the merge into a single component happens in pcb. But I don't know: I don't use pcb.

> What happens, if I don't use nand_c.sym at all, because I need only 3 gates?

If you don't use a slot, its pins don't get connected to anything. "gnetlist -g drc2" has its flaws, but it can find this kind of problem. Of course, that may not be an error.

>> 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

Look at the documentation of the slotdef attribute.

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