Hi all, While making some changes to gmk_sym, I began looking into the symbol library and came up with a few comments that may have been brough up for discussion in the past (I was unable to find such thread in the archives):
Symbols like 74 series, etc, should either have no footprint assigned or should all have the same type footprint (i.e. all should be DIP packages), if a default is desired. As the library stands right now, some devices have thru-hole packages, others have SMT footprints. It would be nice if they were consistent. Even better, symbols should not have a footprint at all if multiple footprint types exist for that device (as is the case with 74xxx gates, which comes in DIP and a couple of flavors of SMT packages). I think that the only instance in which a device should include footprint is if the package type is specified as part of the device name (i.e. mc68vz328pv -> TQFP144, mc68vz325vf -> MAPBGA144). In the example above, an mc68vx328pv and vf cannot share symbols because of their package differences and pin assignments, and hence, it is appropriate to specify a footprint within the symbol. Which brings me to a proposition: I am thinking of writing a tool that annotates package types onto a schematic according to a user-provided stuffing file. For example, a user provides a file that looks like this: dip14: device=7400 dip20: device=74373 so20: device=74373 refdes=U2 c1608: device=CAPACITOR value=0.1u sot23: refdes=Q1 to220: value=7805 class=discrete The utility parses this user file and the schematic and stuffs the package specified according to the rules given for that package. This method allows stuffing of packages based on any of the attributes attached to that device and its symbol (with attributes attached at the schematic level overriding the default symbol attributes). Once this tool is complete, all applicable library parts could be purged of their footprint for consistency. (I have a similar gripe about PCB. It should have no knowledge of anything but footprints. However, it currently knows about a 22v10, 8Mhz crystals, etc. It doesn't need to know this. All it needs to know is that U1 (perhaps a 22V10, but who cares!) has a 24DIP300 footprint, a U2 has a 28DIP600 footprint, Q1 has an SOT23 footprint, etc. But I digress...) The tool would be run as the last step prior to taking the board to layout. Symbol creators would no longer have to worry about making different flavors of symbols just to satisfy the footprint requirement since the footprint would be annotated as a post schematic process. (This is not really applicable to large devices whose pin numbers change according to what package is used, in which case different symbols would have to be created, with the package type specified in the device name) Note: the utility could be used to stuff any attribute, not just the footprint attribute, based on other attributes. (i.e. a cost attribute could be stuffed baeed on the device attribute for bill-of-materials generation.) Well... I've rambled long enough... what say you all? Roberto
