Bill Gatliff <[email protected]> wrote: > At the risk of going OT, I'll add that as I get better at following the > above strategy--- which is particularly helpful with more complex parts > like microcontrollers--- I get really frustrated at gschem's strong > association between pin numbers on the symbol, and pin numbers on the > footprint. That's just... wrong. It would be nice if there was an > additional "layer of abstraction" somewhere between the symbol and > footprint, such that actual pin assignments weren't made until the > footprint (and slot, if necessary) were specified. Until that point, it > doesn't really matter anyway.
That's exactly how I've implemented it in uEDA. > As a "mostly software" guy, I think about schematic capture the way I > think about C code: Ditto! > The solution might be to get rid of physical pin numbers in symbols > entirely, and replace them with "virtual pin numbers" that map to > physical pin numbers in some intermediate processing step. For example, > a 7400 symbol might have pin "numbers" A, B, and Y, and then our DIP16 > footprint would have pin "numbers" A.1, B.1, and Y.1, A.2, B.2, Y.2, > etc. Wow, just like in uEDA, except that you chose '.' as the separator character and I chose ':' in uEDA for that purpose. > A.1 1 > B.1 2 > Y.1 3 > A.2 4 > B.2 5 > Y.2 6 > GND 7 > ... > VCC 14 Even your proposed table format is *exactly* the pinout mapping file format used by uEDA except for the slot separator character. Is someone reimplementing uEDA here? How about the other way around? Anyone feel like porting the gschem GUI to operate on the uschem file format? That's the only remaining piece that's missing from the uEDA solution. cvs -d [email protected]:/fs1/IFCTF-cvs co ueda The documentation is still incomplete though. MS _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
