[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Oct 9, 2010, at 3:25 AM, Armin Faltl wrote:

> 
> 
> Edward Hennessy wrote:
>> On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote:
>>  
>>> To express the many-to-many relation between parts and symbols it uses
>>> a table called "device". This is fed by the infamous device attribute
>>> in the symbol libraries. There's nothing wrong in the theory of DB-design
>>> with it, but the indiscriminate use of this attribute in the symbol-libs
>>> waters the use of this design down to uselessness.
>>>    
>> 
>> I'm investigating another mechanism to create a part 'class' with some
>> existing data in the part library. Using the device attribute for this
>> causes problems. I am pondering the first portion of the symbol filename.
>> So, 'resistor-1.sym' is part of the 'resistor' class. Any other
>> suggestions?
>>  
> Thank you for still working on this hard topic at all.
> 
> Do I understand you correct: you want to limit the range of symbols, that are possible
> to connect to a given part, based on a part classification?

Correct. Parts and symbols have a many-to-many relationship. I'd like to have a human
intelligible name assigned to the relationship. This name will be used as a key. I know this
value will be a string, but where does it come from?

> I don't recall all the details of the DB layout, but i fear, the only solution is to manually
> enter meaningful device values in the symbol libraries.

This way would require modification of the symbol library, which I was hoping to avoid
by using the first part of the filename. However, symbols need to be modified anyway,
to insert macros. For example, a resistor would need to have the attribute:
VALUE=$(Resistance). The part manager will substitute the $(Resistance) with the
field from the database.

> I'm not aware, that the device attribute is used for anything in the current workflow,
> thus the quality of the entries.

It looks like it has meaning for simulation:

http://www.brorson.com/gEDA/SPICE/x115.html

Currently, if the part manager needs to populate this attribute, then it needs to be
changed to: DEVICE=$(DeviceName), and can no longer contain a key.

> If one sets out to map devices to a part classification, I'd suggest ':'-notation like
> "diode:schottky" or "transistor:power:igbt". Therefore it is questionable, to
> completely preset this value in the symbol library at all - maybe just the 1st element.
> This would require a strict rule: something that does not have the same symbol
> mustn't have the same top category: MOSFET != transistor or the top categories
> would need to be 'transistor:mosfet' and 'transistor:bipolar' - I'm getting confused...


For transistors, an important part of the key is the polarity. The symbols for an NPN
and PNP are different. Extending the convention a bit:

transistor:bipolar:npn 

Transistors present another problem: pin configuration. Transistors may require an
additional convention, like listing the pin functions in order. For example an NXP
PDTC114EE would use:

transistor:bipolar:npn:bec

So, the base is on pin 1, the emitter is on pin 2, and the collector is on pin 3.

Internally, the part manager treats this data as a string and does not interpret
the data. So, changing the convention does not change the object code. However, 
data files would need to follow the same convention to be imported into the same
part library.

Cheers,
Ed



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user