Choosing the wrong microcontroller can lock you into months of rework, destroy your margins, or leave you stranded when the manufacturer moves on.
After reviewing hundreds of hardware designs, I keep seeing the same 7 MCUs show up in new commercial products where they have no business being.
I just released a new video that covers all seven and tells you exactly what to use instead.
7 Microcontrollers You Should NEVER Use in a Product
If you prefer you can read the full article here.
Here's a quick summary of what I talk about in this video:
MCU #1 - ESP8266 still shows up in new designs constantly, even though the ESP32 exists and costs nearly the same.
The problem is it's a single-core chip with limited GPIO, only a basic 10-bit ADC, and an aging SDK that isn't seeing meaningful new development.
All of Espressif's real momentum is on the ESP32 family now, so starting a brand-new product on the 8266 rarely makes sense.
If you're considering the ESP8266 for a new design, use the ESP32-C3 instead.
MCU #2 - PIC16 has a huge legacy in the industry, and tons of engineers learned on it in school or early in their careers.
But it's an 8-bit architecture that's been outclassed for most new product designs, with limited RAM and Flash, and a cost advantage over 32-bit parts that has essentially disappeared.
A PIC16 and an ARM Cortex-M0+ part often cost about the same now, but the Cortex-M0+ gives you dramatically more processing power, memory, and peripheral options.
For cost-sensitive applications, look at the STM32C0 or TI's MSPM0 instead.
MCU #3 - Ultra-Cheap No-Name MCUs can be found for under $0.10, but what you'll actually get is machine-translated datasheets, limited or nonexistent English SDK support, a tiny community, and almost no reference designs.
When something goes wrong, and it almost always does, you need documentation and community support you can actually rely on.
For most cost-sensitive applications, you're still better off with the STM32C0 or MSPM0, because they're cheap and come with mature documentation and large communities.
MCU #4 - STM8 still has a following, especially in Europe and in cost-sensitive industrial applications.
ST has made it clear that their future is the STM32, and while the compiler for the STM8 is now free, the architecture itself is proprietary and not ARM-based, so your skills and your code don't transfer to anything else.
So if you outgrow the STM8, you're rewriting everything from scratch, but if you start on an STM32C0, you can scale up to the G0, G4, or beyond with minimal rework.
MCU #5 - MSP430 has a loyal following, especially among engineers who learned it through TI's university programs.
TI has introduced the MSPM0 family and published detailed migration guides encouraging MSP430 engineers to move to it.
Unless the 430 has a very specific advantage for your application, I'd start by looking at the M0 first.
The one area where the 430 still has a genuine edge is FRAM, which gives you non-volatile storage with virtually unlimited write endurance and very low power during writes, so if your product involves energy harvesting or constant data logging, that's a legitimate reason to stick with MSP430.
MCU #6 - ATmega328P powers some of the classic Arduino models, but it's underpowered for the price, has no wireless, and limited peripherals.
The classic Arduino workflow abstracts away everything happening at the hardware level, which is great for learning but terrible for production.
When you need to optimize power consumption, debug a timing issue, or write a custom bootloader, that abstraction fights you instead of helping you.
If you need wireless, go with the ESP32-C3, and if you don't, the STM32C0 or RP2040 are cheaper or similarly priced with far more capability.
MCU #7 - Overpriced High-End MCU is when product creators reach for something like a top-tier STM32H7 because they need a display, networking, a complex user interface, or heavy data processing.
But when you're paying 8 to 15 dollars for an MCU and then adding external RAM, external Flash, and a display controller, you've likely exceeded the silicon cost of a microprocessor that handles all of that natively.
If your design needs external RAM, a display larger than a small OLED, or you're running an RTOS that's getting complex enough to basically be an OS anyway, it's time to evaluate whether a microprocessor is the smarter path.
Options like the Allwinner T113 or ST's STM32MP1 give you Linux, display support, networking, and massive software ecosystems at a chip cost that can compete with a loaded high-end MCU setup.
The mistake isn't choosing a bad microcontroller, it's choosing one that makes sense for a prototype but sabotages the product you actually want to build.
Talk soon,
John
P.S. If you need help choosing the right microcontroller for your specific product and navigating these decisions, you can get expert help from me and other engineers inside the Hardware Academy.