Mail Archives: geda-user/2015/10/19/16:52:58
Nicklas Karlsson wrote:
> I agree about the pin mapping "pinseq" and "pinnumber" should not be
> necessary and pins should be indentified by "pinlabel".
Unless I missed something important, the current "pinnumber" attribute
does already what you are asking for. I does not have to be numeric but
can contain almost arbitrary strings. E.g. My diode symbols have
"pinumber=anode" and "pinnumber=cathode". Pins of the MOSFET symbols have
pinnumbers "G", "D", "S". And bipolar transistor have "E", "C", "B".
This non-standard approach saved me from pnp-number related errors for
quite a number of projects now.
> Then is the
> question if there should be an attribute to select pin mapping or
> external storage.
In my current work-flow this selection is done by the choice of the
footprint in gschem. My library contains footprints for all pin to
function assignment I have met in the "wild". E.g.: TO92_ECB.fp, TO92_EBC,
TO92_BEC, TO92_ECB,... you get the idea. These footprints are listed in an
attribute "footprints=" in the symbol. When deciding for a particular
transistor model the designer is supposed to look up pinout in the data
sheet and choose the footprint accordingly.
The last step should not be necessary. There is no room for choice. A
particular model always comes with the same pinout. Of course, the
decision which footprint is the correct one has to be entered into the
system at some point. But it can be done once and for all as opposed to
every time the model is added to a schematic. This is the typical task for
a library. However, it is not quite convincing to add this information to
symbols or footprints. This approach does not scale at all.
IMHO, the missing part in the puzzle is the notion of a "package" which
delivers all information specific to a physical component. I deliberately
did not write "contain" but "deliver". The package may include footprints
viable for this component. Alternatively the package may refer to a
footprint library by giving filenames of a footprints known to work. Which
of the two is the most appropriate depends on circumstances. Therefore,
the choice between inclusion or reference is up to the designer of the
library of packages.
To add a symbol to the schematic the author chooses a package. Depending
on the contents of the package the author gets to pick between possible
values, footprints, slots, etc. If only certain combinations of value and
footprint are allowed, the package restricts the choice accordingly.
By default, the schematic references the package and stores the picks of
the author. On load, gschem would look up the package in the library. This
is very similar to the current symbols which are referenced by name. But
there would also be the option to "flatten" the package. That is,
explicitly put the symbol in the schematic and set the values of the
attributes (footprint, value, simulation model, ...).
Flattening the package would make changes harder. But it would allow for
easy sharing of self-contained project files. In a typical production
environment you would use referenced packages for active development and
save as a flattened version for documentation and communication.
> From the link below. I would say heuristic for most components is value
> and footprint. I say the BOM generator store this in a separate file, it
> may also remember decisions. Main reason is it would not be necessary to
> update schematic if manufacturer part number is changed.
In the referenced package scenario actual manufacturer part numbers in all
their beauty is stored in the library of packages. So it can be changed
any time without affecting the schematic. In addition, the package may
contain information on where to buy, specific notes, and possibly even the
amount currently in the warehouse.
Again, whether or not any of these possibilities is useful depends on
local circumstances. So it is up to the choice of the library author to
make use of them or to not care.
> My idea is to have a third repository of information, which contains the
> difference between a light and a heavy symbol. This extra database,
> which I'll call the component database or "partdb" (because
> "componentdb" just doesn't roll off the tongue), contains all the info
> needed to turn a light (generic) symbol into a heavy (specific) symbol.
> For example, if your schematic called for a 3.3uF 16v capacitor, the
> database would let you find all the manufacturers who make such a part,
> what the available packages are, and what PCB footprints they'd use.
> Based on some heuristics, a specific component would be chosen to be
> used, and the additional information added to the symbol and element.
This sounds a lot like the "package" scenario I described above. Except
that I deliberately did not imagine a (relational) data base but plain
files. In my humble experience data bases are easy to mess up in a way
that does not scale. And they tend to be a nightmare to share unless you
give up flexibility and make everyone rigidly adhere to a specific set-up
of tables and rules.
Contents of a data base can only be accessed via the specific database
language. By contrast, plain files are open to all of the glory text
manipulating tools several decades of computer science have come up with.
Versions of contents of a database does not come naturally. Plain files
are easily dealt with by your preferred versioning system.
---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211
Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de
GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get
- Raw text -