On Wednesday 19 December 2007 09:52:49 Levente wrote:
> Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
>
> [...]
>
> >> The symbol files should be as light as possible, and we should make them
> >> heavy by adding information coming from the database.
> >
> > Totally agree. Could we implement this by asking the backend to take
> > care of where the symbols come from, and merge them with the database
> > info before presenting them to gschem? Or is this the wrong way? Is it
> > better to place a symbol, then invoke a special "select part" command?
> > My worry is that the latter option would make it easier to end up with a
> > resistor which thinks it's an op-amp.
>
> I've started to implement things in the first way, but I think it is a good
> idea to have it with the later. For example when you just want to make a
> sketch schematic input, without any knowledge of what the exact part would
> be. Like you place a resistor, but you don't know its value, type, etc...
> Later, you can go round, and choose the exact parts from the database.
For anything more trivial than a resistor, these light symbols are going to
have to come from the database too, are they not?
How would this work for users who already have existing flat-file symbol
libraries they want to use alongside the database system?
How would this work for someone drawing a schematic of part of an ASIC for
simulation? (Totally different attributes etc. to those required of
the "expected workflow" you seem to be thinking of).
> Light symbols on the schematic (ones without attribute contents) should be
> marked with some warning colour.
>
> Thanks to gEDA developers that symbols are not embedded in the schematic by
> default.
I still haven't been convinced by these arguments, especially since _nothing_
you've described can't be implemented with symbols which are embedded by
default. (So there. :P )
My vision of how the database could work is as follows:
- Each symbol (or part) has to be uniquely identified by a string, and each
database/website/directory gets queried in reverse order of being added to
the library. This is as currently.
For databases, this could just be a concatenation of the database name and
some sort of unique identifier number. The unique identifier string would
be stored in the schematic file where the "symbol name" currently is.
This provides a way to store exactly which part was selected by the user
in a backwards-compatible manner.
- For searching for symbols, the user is presented with a GUI which allows
them to construct queries consisting of pairs of attribute names and values
in a list.
(list 'regexp '("device" "*MOS*") 'and '("manufacturer" "IRF")
'or '("manufacturer "Philips"))
Regular expressions? Glob syntax? Anything else needed?
These queries are presented to the backends in order, and each returns a
list of matching identifiers.
- The current "in use" list becomes an "active" list, to which users
can add symbols at runtime either by placing a component or from the query
results view.
The user could specify a default active list in the rc file for
commonly-used basic components.
(define clib:default-active-list '("resistor-1.sym"
"capacitor-1.sym"
"levente-opamp-lw"))
- In order to select alternative parts from the database (e.g. go from a
generic op-amp to a specific Analog Devices low-noise rail-to-rail 5V amp) a
"compatible" mechanism is used.
The user selects the component to be replaced, and invokes the "Choose
alternative..." command. The user is given the opportunity to construct a
query as if choosing a component normally, except that the backends only
return parts which are compatible with the component's current identifier.
If the user selects a part, the component to be updated will get replaced
with the new symbol from the backend.
"Old-fashioned" backends such as flat-files probably couldn't support
the "compatible" mechanism, but it is possible to imagine that databases
could provide lists of compatible parts for the basic symbols such as
resistors, capacitors and diodes from the default libraries.
One tricky problem will be how to update attributes. Database overrides
all? Or some other method?
What have I missed?
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user