Some MCU symbols are very large because of long pin names about kicad-symbols

[bobc]

I created footprints for many of the missing ST packages - QFN-20, QFN-28, BGA-64, 100 (x3) 132, 169, 176, 216, 240 but I didn't get around to pushing them yet. I can do that over the weekend.

I generated them via a script, so it is relatively easy to add new ones. The full list is

Package_DFN_QFN:QFN-20-3x3mm_Pitch0.5mm
Package_DFN_QFN:QFN-28-4x4mm_Pitch0.5mm

Package_BGA:BGA-64_5.0x5.0mm_Layout8x8_P0.5mm
Package_BGA:BGA-100_10.0x10.0mm_Layout10x10_P0.8mm
Package_BGA:BGA-100_7.0x7.0mm_Layout12x12_P0.5mm
Package_BGA:BGA-100_8.0x8.0mm_Layout10x10_P0.8mm
Package_BGA:BGA-100_9.0x9.0mm_Layout10x10_P0.8mm
Package_BGA:BGA-132_7.0x7.0mm_Layout12x12_P0.5mm
Package_BGA:BGA-144_10.0x10.0mm_Layout12x12_P0.8mm
Package_BGA:BGA-144_7.0x7.0mm_Layout12x12_P0.5mm
Package_BGA:BGA-169_7.0x7.0mm_Layout13x13_P0.5mm
Package_BGA:BGA-176_10.0x10.0mm_Layout15x15_P0.65mm
Package_BGA:BGA-216_13.0x13.0mm_Layout15x15_P0.8mm
Package_BGA:BGA-240_14.0x14.0mm_Layout17x17_P0.8mm

[ObKo]

Script that was used to generate stm32 library: https://github.com/KiCad/kicad-library-utils/tree/master/schlib/autogen/stm32

You can try to modify it to shorten MCU pin names for stm32 library.

[Ratfink]

I'm about to start working on this, but I can't find the XML files for obsolete devices mentioned in the README for the stm32 autogen script. Seeing as how the obsolete microcontrollers mentioned there aren't available from distributors anymore and are barely even mentioned on ST's website, should I just let their symbols disappear from the library?

[bobc]

I spent some time working on updating the STM32 scripts, there are several issues that can be improved.

With regard to "obsolete" parts, some F050 parts were renamed to different names (but exactly the same part). I think the missing F313 parts either never went into production or were introduced with different config. I would suggest to copy the obsolete/missing parts to the "obsolete" folder.

[Ratfink]

What's the policy on specifying footprints for parts that have exactly one footprint, but that footprint isn't in the library? A lot of the STM32 chips fall under that category, with weird packages that aren't in the library yet. I already have footprint filters for all the packages, but I don't know if it's frowned upon to specify a footprint name that doesn't exist yet.

[poeschlr]

@bobc you are a hero.

[Ratfink]

Wow, thanks! However, I believe there are quite a few more missing footprints than that. I parsed all ST's package names from the PDFs and have the full list with the ones I believe are missing commented out. Still, you're right, a BGA script should have no problem making WLCSP footprints, and the couple of QFN footprints where we don't have the right size of EP should be easy to add too. I can work on those if you want.

[bobc]

Ah, I didn't look at the CSP packages, there are quite a few of those. I also didn't distinguish the LF-, TF-, UF-BGA variants. I think the only difference is the package height, which I think only affects the 3D model. That can be easily fixed in the YAML.

I used the kicad-footprint-generator framework, I added Package_BGA script to it because there wasn't one already. I will need to rebase my repo before creating a PR for that.

Anyway, trying to work around Travis errors usually leads to other problems, so I think you should go ahead and put in the default footprint names you think are right, and we can get the footprints to correspond later. @poeschlr is that a good plan?

[poeschlr]

Yes adding footprints later would work. But keep a list of missing footprints and their specification in either this issue or even better in a new issue over at the footprint repo. (Mark the new issue with help wanted. That way it is documented such that it is not forgotten.)

[poeschlr]

We can simplify the pin names but we should not change pin positions as it would break existing projects. (Needs to wait till we start with v6 development)

[Elijahg]

Sort of a cross-post to here but I really don't think shortening MCU pin names is a good idea. I agree the symbols are pretty big with all the descriptions but it's really useful to be able to see the pin functions at a glance.

Having a large symbol has little consequence versus getting the mapping wrong through reading the wrong pin in the datasheet, which can ruin a board.

[poeschlr]

The rule must work for every processor. Some STM MCUs in the lib already take up a full A4 page on their own. Yes it might be possible for smaller MCUs that have only one or two functions per pin. But we do not want to have differing rules for them. (Just creates a lot of ambiguity in the rule set. And if we set the line at two functions per pin another person will come why not 3, or 4, ....)

I would disagree with you on the "it makes it less likely to make a mistake front". Having a symbol that fills a full page makes it impossible to see the big picture. In the end you will just move that symbol into a sub sheet with hierarchical pins to hide its complexity. Resulting in one more place where an error can occour.