X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Injected-Via-Gmane: http://gmane.org/ To: geda-user AT delorie DOT com From: Kai-Martin Knaak Subject: Re: [geda-user] Pin mapping (separate symbols from mappings) Date: Mon, 19 Oct 2015 22:52:32 +0200 Organization: Institut =?ISO-8859-1?Q?f=FCr?= Quantenoptik Lines: 165 Message-ID: References: <20151018204010 DOT 9cce6a231dcc296256e187bd AT gmail DOT com> <201510181843 DOT t9IIhmWo025346 AT envy DOT delorie DOT com> <20151018233004 DOT 78db1f9df1b1e68325c8639e AT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Complaints-To: usenet AT ger DOT gmane DOT org X-Gmane-NNTP-Posting-Host: 130.75.102.197 User-Agent: KNode/4.14.10 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t9JKqnvg015443 Reply-To: geda-user AT delorie DOT com 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