Reconsider the dual footprint MCU

[Magpie-81]

Version Number

1.0.1

Bugfix or Enhancement

Enhancement

Description

Removing the QFN-32 package for the STM32F031K6U6 option would help to clean up the layout around the MCU. I understand that the recent supply chain disruptions made us more aware that it's nice to have options, but i would think it's not too hard to recompile the photon firmware for another chip in the same LQFP-48 package, like the next step up in the line (STM32F051C6) or find another fitting chip for that footprint. Having both footprints overlap requires you to be specific when ordering paste stencils as well, as you don't want the QFN pads covered in paste when you place the bigger QFP package on top, or you run quite a high risk that the solder might bridge and create shortcircuits under the package. Or the QFP package starts to float away uncontrolled and needs manual rework after reflow.

Suggested Solution

Reconsider removing the QFN-32 footprint.

[warasilapm]

Alternatively, go full QFN to gain more board space for additional features proposed in other tickets. Just a thought! You could easily go either way.

[Magpie-81]

I guess the QFP has advantages as well, it's easier to solder and check the quality after reflow or do rework, and it offers more pins for more features. Pricing for both of them seems to be roughly the same, so there is no real winner here. Availability isn't great for both versions, at least when looking at distributor stocks that are listed on octopart.

[sphawes]

Thanks for the thought @Magpie-81! Here's some of my thoughts on this:

• It certainly would free up a bit of space to switch entirely to the QFN. Part of the reason I like having the QFP is that it's much easier to solder for hobbyists than a QFN can be.
• I think the flexibility of having the two footprint options is worth it, even knowing that it could clear up some board real estate. We've purchased a stencil for each MCU option, and given that they're less than $20 USD apiece, it's a pretty inexpensive insurance policy.
• I'm sure that we could also just compile Photon for a different MCU, but in the situation of a stock-out and our manufacturing line being halted with nothing to assemble, I'd much rather have a drop-in binary compatible replacement chip that lets production continue without having to source, test, and recompile for a different part.

[warasilapm]

@sphawes So is this a won't fix? Just clearing out some old GitHub notifications here and I noticed this is still open.