Re: gEDA-user: Fwd: Parts DB API: the story so far

[John Doty <jpd@xxxxxxxxxxxxx>]

On Dec 20, 2007, at 10:49 AM, John Griessen wrote:

> John Doty wrote:
>> On Dec 20, 2007, at 7:07 AM, Steve Meier wrote:
>
>>> I have expressed concerns that the data isn't flat and thus isn't
>>> suitable for flat files.
>>
>> The maps within a relational database *are* flat, and may be
>> expressed as flat files. I have seen such an implementation. So, I
>> think this is a false dichotomy.
>
> Flat files might be bad to try and use on a chip design,
> or large board, but then you could choose not to write them.
> I think the flat files can be a path to results, then be made
> optional when a good working database is hooked in, and giving  
> results.
>
> Trying to make the database optional even after developing its use
> sounds hard.  Is there opposition to a database?  No database ever  
> would
> be limiting...

Show me how it's used. Here's the flow I envision:

1. In gschem, I choose a component graphic from the library. It gets  
automagically copied into my project symbol pool, with a name of my  
choosing. So let's suppose I grab a resistor-1 and name it LVDS- 
term.sym.

Why is this better than embedding? Because I get exactly one private  
copy. Not one per instance or one per page, but one per project. This  
means that Hs and edits actually do the right thing: they make  
project-wide changes.

2. Now I place one, do Hs, put in part=LVDS-term (or maybe the copy  
already gave me that default), add in footprint=0603 and value=100.  
Those will do for now.

3. The symbol browser should give me a shortcut to my project symbol  
pool, so I can add more terminators as needed.

4. Maybe I have separate project symbols for other kinds of  
resistors, or maybe I just override the attributes at schematic  
level. In one design I did with Viewlogic this way, every nonpolar  
cap used the bypass_cap symbol, but the minority that weren't bypass  
caps had their attributes overridden at schematic level.

Okay, now I've entered the schematic: the project moves to BOM  
management. What I want here is a "parts" file with the following  
characteristics:

Easily editable as text, including things like global search and  
replace.

Readable by a human being. No graphical parameters.

Keyed by the "part" attribute.

Definitive: anything here overrides the schematic.

So suppose we've decided to use 0402 parts for LVDS termination. The  
LVDS-term entry in the parts file gets footprint=0402, overriding the  
symbol and schematics.

Note that I might switch parts files during the project: the  
prototype might use one, the flight model another, completely  
different. I suppose this likely to happen in mass production also  
(quick parts versus cheap parts). A schematic page copied from one  
project to another might use a different parts file, but be  
electrically the same.

gschem and gnetlist would look in here for attributes. Think of this  
as a "source file" for the BOM.

Now, I have absolutely no problem with a database tool for filling in  
the blanks and updating this file. I don't, however, see how that  
should work, or where the data will come from, and I doubt we'll have  
such a thing soon. So, the ability to manage attributes as text  
separate from graphics should not be hostage to the database idea.

>
> John Griessen
>
>
> -- 
> Ecosensory   Austin TX
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

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