On Dec 27, 2009, at 8:22 PM, Dave N6NZ wrote: > > On Dec 27, 2009, at 6:00 PM, DJ Delorie wrote: > >> >>> Actually.... this is starting to sound like embedding a gattrib grid >>> on a sheet some place. >> >> Can gattrib map pins to nets already? > > Well, not that I know of. But having a grid display of row-organized data > that captures "interesting stuff" about instances is gattrib-ish. So I was > just imagining a gschem "symbol" that behaved similarly to the gattrib tool. > Editing attributes and editing infrastructure pin assignments seemed like a > similar workflow. > > -dave > Yes, I'm responding to myself -- another thought just occurred to me. Good schematic systems have the ability to keep the attributes (and I'm going to throw slot/pin mapping into that generalization) in separate files that are separately rev'ed. This is something that I could use right here and now with gEDA, even though my designs are tiny. I'm in the habit of doing certain boards as through-hole to get an easy to hack prototype, and come back later with an SMT version of the board. So I'd like to have one set of schematics, and be able to join it to a set of thru-hole attributes and mappings, or be able to join the same schematics to a set of SMT attributes and mappings. The SMT package usually has different pin numbers from the thru-hole package.
In one very good system that I used, the process worked something like this: 1. Bring up a particular revision of a particular schematic file. This revision of the schematics could have multiple attribute files it could join with. Each of those attribute files could be separately rev'ed. 2. Join a particular rev of a particular attribute file. 3. Work 4. Save rev of attribute file if all you changed was attributes or... 4b. Fork a new attribute file base rev. 4c. If you changed schematics, save or fork schematics, and also the base rev of an attribute file that was automatically forked when you changed the schematics. So.... for slot/pin mapping, I'm pretty sure I'd like to have a similar mechanism. This kind of argues for a file on the side instead of embedding the data in the drawing file. OK, so I'm being inconsistent :) -dave > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
