3 ms·
I really like the STM32 ecosystem, but you have hit the nail on the head - there's too many variants. You really don't need 200 variations of a basic M0+ part,
by Sanzig 1y ago
I really like the STM32 ecosystem, but you have hit the nail on the head - there's too many variants. You really don't need 200 variations of a basic M0+ part, and having all those SKUs hurts availability because you're playing roulette when it comes to what will actually be in stock when your CM goes to order parts.
- azonenberg 1y agoI did not like that part of it. Personally I've standardized on just three STM32 parts: * L031 for throwaway-cheap stuff where I'm never going to do field firmware updates (so no need to burn flash on a proper bootloader) and just need to toggle some GPIOs or something * L431 for most "small" stuff; I use these heavily on my large/complex designs as PMICs to control power rail and reset sequencing. They come in packages ranging from QFN-32 to 100-ball 0.5mm BGA which gives a nice range of IO densities. * H735 for the main processor in a complex design (the kinds of thing most people would throw embedded Linux at). I frequently pair these with an FPGA to do the heavy datapath lifting while the H735 runs the control plane of the system.
- HeyLaughingBoy 1y ago+1 This is the approach I took at my last job: we standardized on a small handful of CPUs selected for a certain level of complexity. Before this, choosing a CPU was an agonizing task that took days and didn't add a lot of value. The only time it actually mattered was the one time we got an order of several 100,000 units. In that case, you want to get the BOM cost as low as you can. Trying to get the same thing implemented at my current job. I'm seeing the same behavior where a team takes forever to choose a processor, and a "good enough" choice would have taken a couple of hours.