I’m generating a footprint for the raspberry pi compute module which has 200 pins - 16 18 of which are NC. I’m hoping to submit this to the official repo.
Is it acceptable to have a part which has all of the NC on, and nothing else?
KLC S4.5 Pins not connected on the footprint may be omitted from the symbol
And my clarification for it: https://github.com/KiCad/kicad-website/pull/377
1 Like
I applaude guidelines such as the KLC but there will always be disagreements between different people.
In my opinion each and every pin of a physical package should be lisited in the schematic, even if they are NC pins or when there are 100 GND and power supply pins.
[rant]
If for nothing else, then at least for repair jobs I want to be able to find a pin in the schematic from the physical locaton on the PCB footprint.
But maybe I’m old fashioned. With 3 layer deep BGA’s a lot of pins are not even accessible from the outside.
But library symbols such as “MCU_Microchip_ATmega:ATmega1284P-AU” have multiple GND pins stacked on top of each other in the schematic symbol, which I do not like at all.
Things like this have probably been discussed multiple times in the making of the KLC. Maybe I should re-read the KLC section on the KiCad site…
In the mean time it’s trivally easy in KiCad to take a libary symbol and modify it a bit.
All the AVR processors also have secondary pin functions omitted and I want at least to be able to see the most common pin functions such as RxD / TxD timers and I2C pins. But because editing is so easy it’s all pretty trivial, and I accept to maintain my own libraries for such parts.
[/rant]
1 Like
This is not to declutter the schematic. It is to remove responsibility from the circuit designer. (And move it to the library team) With pins stacked the designer has no choice but to connect them as they should be connected.
I would however wish for a better way to define such pins instead of stacking. Ideally there would be a way to see form the schematic which pins the single connection point represents. (A tooltip for example)
And yes i doubt paper printouts will ever be able to nicely show such a thing. But to be honest paper printouts are limited anyways so no need to limit the functionality of the rest of the software just to make them more readable.
Great, thanks. Can’t believe I missed that after reading the KLC so many times!
Another question, which library would be most appropriate for the compute module? I was thinking that the MCU_Module would be the most fitting, but then again the CM3 isn’t really an MCU…
I think this is something best discussed as an issue over at github or as part of your pull request.
1 Like
Got it, thanks for your help. 
pin stacking will be addressed with the new schematic file format (v6) as well as alternative pin names
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.