Dave N6NZ wrote: > I believe this style leads to the most readable schematics, and scales > up well to larger designs. >
Agreed. At least until you do like me, and forget to put down the power symbol once (or twice). :) 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. For example, I once merely changed the footprint= parameter in a MOSFET symbol, from to92 to sot23, and found out the Hard Way that doesn't work. I think it should. As a "mostly software" guy, I think about schematic capture the way I think about C code: it's a specification for signal/data/control flow only, and the underlying details about how the physical machine implements that specification take place later. When you tie physical pin numbers into the symbol, however, you lose the advantage that a schematic capture exercise is supposed to provide you in the first place: the ability to think at a level above the hardware. 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. When the user specified the footprint=DIP16 and slot=2, then an intermediate step could "bind" the pins from the symbol to the pins on the footprint automatically. (And once that binding took place, gschem could report the physical pin numbers on the schematic as an option). Later on, if I swapped the 7400LS/DIP16 package out for a LittleLogic/SOT5, that footprint would also have A.1/B.1/Y.1 pin numbers, so gaf would know how to re-bind the virtual pins from the symbol to the right places. Ok, if you have been paying attention so far, you'd probably be getting ready to say that all the above isn't really the right solution to the problem either. But if you've followed me this far--- and I thank you for doing so!--- then you'll get where I'm going next and why. :) Packages like SOT5 and DIP16 are used everywhere, not just for LittleLogic and 7400. So just going to a "virtual pin naming convention" that's 7400-specific, like I just described, doesn't really solve any problems--- it just moves them around a bit. What is REALLY needed is for footprints to use physical pin numbers as they do today, and then use a table (probably carried with the symbol) that does the ABY->pin mapping on a per-footprint basis. Something like this: footprint=DIP14 vpin ppin A.1 1 B.1 2 Y.1 3 A.2 4 B.2 5 Y.2 6 GND 7 ... VCC 14 footprint=SOT6 vpin ppin A.1 1 B.1 2 Y.1 4 GND 3 VCC 5 The above would likely be highly-redundant, at least for 7400-series parts, so maybe they could be placed in a "footprinttable=7400.fpm" file, or something. When there were exceptions, then the table provided with the symbol would overrule. A side-effect of the above is that it lets you have exactly one NAND symbol, regardless of the footprint of the device the user ultimately chooses. It also lets you have only one DIP16 footprint for all users of that footprint. And one ATtiny44 in-circuit-programming connector symbol that works with all the different footprints that microcontroller comes in, even though the pin assignments are different--- because the tools can sort out where the wires should go once you indicate the footprint to use. And MOSFETS... and so on. I think the above solution is pretty compelling, and it isn't a big step away from what we have today. It's just an additional layer of abstraction above/replacing the slotdef= parameter. I'm hardly the guy to talk about how hard it would be to implement, but it doesn't seem THAT hard... :) b.g. -- Bill Gatliff [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
