Stephan Boettcher wrote: > Option 3.) I'd make a symbol for each function the chip supports, > and instantiate a subset of those that I need, carefully annotating > overlaps in pin usage, so that no pin is used twice accidentally. This > is required work for using such a chip anyway.
Note, that gnetlist cares about the sequence of symbols in the *.sch file. That is the order you included them in gschem matters. In particular, gnetlist reads the footprint attribute only from the first of a set of symbols with the same refdes. This affects the value attribute, too. The result is missing footprints in the layout and/or "unknown" value in the layout. You can prevent this by either: a) attach footprint and value attributes to each and every symbol of a set. Downside: Redundant information. Conflicting values may slip unnoticed. b) Write a patch to fix this bug Downside: The developers may not like your approach. In this case your schematics will only process cleanly with your locally patched version of gnetlist. Bad for sharing. c) Rearrange the order of symbols in the file with a text editor. Downside: laborious. d) write a script to move the symbol that contains footprint attributes to the top of the file. Downside: Yet another component in the work-flow. I did b) last year, got dismissed, and default to option c) for schematics I'd like to share. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
