What is your preferred MCU brand/family to work with?

[Karel]

And why do you have that preference? Because of the features? Tools? Price? Availability?

[nctnico]

I like NXP's LPC ARM microcontrollers. Excellent documentation so it is easy to write software and the peripherals are the same across many different devices so I don't need to rewrite drivers or do deep checks if a peripheral I used before works differently. Also firmware can be loaded through a decent, well featured serial port bootloader or an internal flash ROM API. Everything has been setup / designed to be able to get something working quickly without nasty surprises. Before landing on the NXP LPC series, I have evaluated quite a few ARM based microcontrollers (even built prototype boards for some) but for me the NXP LPC series stood out the most in the end. I have been using these for decades already.

[brucehoult]

WCH. Price, features, standard ISA, standard open-source tools, community, documented programming and debugging protocol and the official USB interface is under $5.

One of many manufacturers (both Arm and RISC-V) with clones of STM peripherals, making that a kind of de facto standard vs TI, NXP, Microchip etc.

NB pro programmer, hobbyist player with hardware.

[fchk]

I worked for a Chinese company a decade ago, and the experience of that (TL431 with strange behaviour, 3.3V voltage regulators outputting exactly 1.8V, empty chips, recycled ceramic caps with high leakage, ...) has told me to keep a maximum distance to Chinese stuff.

I've used Microchip a lot: good choice of peripherials, good long-term availability, 5V IO voltage available, simple designs, ease of use.
Also others just as needed. I'm not a fanboy, just trying to accomplisch jobs.

[brucehoult]

I worked for a Chinese company a decade ago

I wonder how many companies there are in China. It is 100% certain that some of them are dodgy.

But I've had nothing but good experiences with Sipeed, WCH, GigaDevice, Espressif, Milk-V, SpacemiT, Aliexpress, DealExtreme, Pecron, JA Solar, MuseLab, OrangePi, StarFive, TP-Link, Lenovo and their respective products. And no doubt others that don't spring to mind right now.

[Andy Chee]

I worked for a Chinese company a decade ago

I wonder how many companies there are in China. It is 100% certain that some of them are dodgy.

But I've had nothing but good experiences with [this list]. And no doubt others that don't spring to mind right now.

Now that you mention good experiences, what are your bad experiences (Chinese and non-Chinese) with microcontrollers.

[westfw]

what are your bad experiences (Chinese and non-Chinese) with microcontrollers.

I was not very happy with the ... churn ... that TI introduced in their ARM microcontroller lines after acquiring Luminary Micro.
Maybe it was just gratuitous renaming, but I still have trouble keeping track.  "MPSM*" now?  I would have thought a company the size of TI would have a more Microchip-like policy toward legacy chips (ie keep them documented and orderable for a long time...)

[oPossum]

Microchip 8, 16 and 32 bit PIC family and TI MSP430. Great long term support. The latest tools retain support for all the older parts and the latest programmer/debugger works with most.

[Psi]

I'm pretty generic,
I like
- ATMega/ATTiny for simple stuff.
- STM32F0 if I need a bit of power, 32bit, DMA or fast floating point
- STM32F4 if I need serious horsepower.
I've not had any need to try a F7 or H7, but they do look nice.

I also do some stuff with ESP32 for WIFI, but it's mostly just flashing ESPHome and setting up yaml configs, so that probably doesn't count.

[cfbsoftware]

STM32 - because their range of low-cost Nucleo boards makes it very easy for us to support them with our Astrobe development tools. Particularly useful are the "Mbed-enabled" features:

• Drag-and-Drop Programming: You can compile code online and drag the resulting binary file straight onto the board's virtual drive to flash the microcontroller.
• No Extra Hardware: The USB connection also provides a Virtual COM port for serial communication without separate adapter cables
• On-Board Debugger: An integrated ST-LINK/V2-1 debugger handles programming and appears as a USB mass storage drive on your computer.

Also, most Nucleo-64 and Nucleo-144 boards feature official Arduino Uno V3 connectivity headers. This makes it easy for us to test each one with a standard set of peripherals.

[brucehoult]

STM32 - because their range of low-cost Nucleo boards makes it very easy for us to support them with our Astrobe development tools. Particularly useful are the "Mbed-enabled" features:

Mbed is dead, Jim.

[uer166]

STM32G0 for general purposes.
STM32G4 for SMPS/mixed signal stuff.
STM32H5 for more application/RAM/Ethernet. heavy stuff that needs max processing power.
STM32U5 for low power/GUI/handheld devices (my favorite one out of all).
STM32L0 for low cost 1 layer layouts since it comes in SOIC packages.

I do not like STM32H7, it has concessions when it comes to complexity of buses and caches and clocking that are a pain in the ass, I am eagerly awaiting Cortex-M55 chips from ST that will make the Cortex-M7 obsolete in my eyes.

Out of all chips mentioned only the G4 and H5 and H7 have I had experience with large scale production volumes, the rest in <100 units.

[XIVN1987]

WCH CH32V:

1. It is based on RISC-V, and its interrupt handling and debug support are better than those of other RISC-V MCUs (closer to Cortex-M).

2. They also release some interesting products that other MCU vendors would not make, such as the CH32V305FB, which supports 480 Mbps USB 2.0 with only 20 pins; the CH32H417, which supports 5 Gbps USB 3.0; and the CH32V407, which integrates an Ethernet interface with a built-in 100M PHY and supports RVV.

[Geoff-AU]

Atmel 8-bit Mega/Tiny or ESP32 usually, because of the inherent laziness the Arduino ecosystem allows for rapid prototyping of things before I lose interest in the idea.

TI MSP430. Great long term support. The latest tools retain support for all the older parts and the latest programmer/debugger works with most.

MSP430 is a joy to work with, very nice micro.  I did find the latest toolchain sucked in 700 bytes of standard library just to flash an LED though, so I used an older toolchain.

I did not enjoy my last experience with STM32, various parts of "random weird" with I/O 5V tolerance, and their stupid HAL... I'm reluctant to risk trying them again.  I suppose once you understand all the gotchas you can use them but... nah.  (Not that Atmel was blameless, but nowhere near as bad as ST).

[dietert1]

My current project has a STM32H743. Yes, it´s a complicated beast with thousands of pages of documention, yet quite powerful. I added an external switcher for the 1.2 V core supply and it stays pretty cool. It implements http and telnet servers, using a LAN8720 phy. Its timers (including 32-bit timer 2) run at 200 MHz, so 5 nsec input capture resolution.
While the first MCU i worked with was an Intel 8085, my first Cortex M processors were Freescale parts. STM32H7xx seems to be 40 nm technology. I also have a STM32N6 board. That part is 16 nm technology.
Today i happened to watch a Veritasium video on EUV lithography technology. Interesting times!

Regards, Dieter

[Psi]

I should try some of the STM32 that are not F series.
I tend to stick with what I know but it means missing out on the newer stuff.

[hans]

My preferred MCU series is very cliche , STM32..
Mainly because under the hood the peripherals are virtually copy-paste. From STM32L0 to STM32F7/H7, some are refreshed at one point, but it doesn't happen often. New parts have a new core, bus/memory design, and analog peripherals. That's about it. I've had cases where I hopped a prototype project between STM32H7, F7 and then L4 in a matter of hours. However, this was not with ST's Cube software stack.. I found that to be a bit frustrating to use (it blows up code size a lot, taking kilobytes for basic clock/gpio setup, and on small L0 parts, I can't even link in all HAL sources for a debug build). Presently I mostly work with L431, F723/H725 and U545..


Before STM32 I was a big fan of Microchip parts, particular PIC24/dsPIC33. But they didn't have C++ support for a while. I tried to use their C++ compiler the other day, but I wasn't very successful. They said to me I should hop over to their VSCode IDE to use C++, but since I only have a PICKIT3, I'm not sure I'd bother.
I also occasionally use AVRs now.. its perhaps a bit ironic because I haven't used them a ton. But I do see why people back in the day preferred them over 8-bit PICs (and 16-bit because C++)..

[JPortici]

after all these years, it's still dsPIC. Fast core, low latency, nice set of peripherals, excellent docs. (wish they'd made new parts with USB.)

[negativ3]

Teensy for HP and toolchain, ATMega, STM32 or ESP32 depending on complexity and baked in bt/wifi needs.
Toe dipping into FPGA.

[paulca]

STM32 for most things.  Some things I set up in MX.  Somethings I set up in PlatformIO.   F411 as the all rounder.  H750 for the DSP audio board.

Arduino occasionally if 5V and slow is ok.  The Arduino Mega for example is very useful for testing small boards with 5V.   

ESP32 or even an aged 8266 is I want Wifi.  I found the move from Adruino Framework to IDF a bit rough, but I was trying to use BTAudio with it and struggled just with the learning curve. 

[NorthGuy]

I like Microchip. They have very good periphery, everything is connected (or rather connectable), pins can be remapped practically without limitations. Processes may be automated. This gives you an opportunity to be creative.

[Doctorandus_P]

I very much liked the old atmega's. First uC I worked with as a PIC16F84 and that was horrible ASM only, and a bad instruction set and architecture so I quickly lost interest after a few blinking led programs. The ATmega's had a C compiler and that was very nice. It was in those early days that you build your own (better) programmer by connecting a breadboard with a few resistors to an LPT port. I also very much appreciate the directness and simplicity of the old 8-bitters. And because the uC runs on anything between 2 and 5V, you connect it directly to a battery without having to use a voltage regulator.

Later atmel made the "attiny's" and those are annoying. You had to trow away all the libraries you wrote for the atmega's and then rewrite them all. I bought a bunch of attiny2313 chips, but never used them for that reason.

I've dabbling a toe in STM32 for 10+ years now but I can't get the hang of it. Working with eclipse is (barely) acceptable now computers have become fast enough to  handle the horrible bloat. But the way that ST set up the rest is quite bad. There is a 60+ page thread on this forum for that.

An important part for me is CSMA/CA on a UART/RS485 network. The uart checks the line for idle, then enables the RS485 transceiver and starts sending immediately. This delay should be as short as possible to reduce the chance for collisions. With an ATmega, the delay is one or two cpu cycles (I.e. nothing). With STM32 this can take 20 (or more?) cpu cycles.

[uer166]

With an ATmega, the delay is one or two cpu cycles (I.e. nothing). With STM32 this can take 20 (or more?) cpu cycles.

And yet 2 cycles at 16MHz is same as 20 cycles at 160MHz, where the latter is achievable by a lot of STM32 parts; Unless you're talking about UART peripheral clock here, not CPU cycles.

[westfw]

Later atmel made the "attiny's" and those are annoying. You had to trow away all the libraries you wrote for the atmega's and then rewrite them all. I bought a bunch of attiny2313 chips

Huh?  There are the ultra-tinys (attiny4-attiny10, etc) that are brain dead (only half as many registers, etc), but most of the tiny series (including the 2313) are nearly identical to the atmegas, lacking (essentially) only the multiplier.

[Driftless Engineering]

Oh I like this topic! I'd really like to hear everyone's preferences when it comes to development environments as well. I just started playing around with CMSIS in VS Code targeting NXP MCX to break away from Eclipse-based IDEs; I've never really liked them.

As for Microcontroller families:

I started with TI's MSP430. That makes me biased, but they always felt comfy to work with (using Keil and IAR). I felt like the documentation had everything I needed without having a lot extra to sift through. I tried one or two of TI's M4 chips as well. I liked the chips. I didn't like Code Composer Studio. I'd rate it 8/10, would Keil again.

A lot of the older folks where I work really like PICs, and they've become my go-to just because of familiarity. I like the configurability. I like the long-term support. I hate narrowing down what pin can get connected to what function. 7/10, people give me funny looks because it doesn't say ARM.

The younger people I work with prefer STM32. When I tried it, the configurator made a whole bunch of comments all over the place and that really annoyed me. It deserves another shot, but honestly I avoid it unless someone else is doing the firmware and that's what they want to use. 5/10, the codebase is a mess and I'm in denial that it's my fault.

I did one (several-year-long) project with a Silicon Labs chip. It was probably just the module I used (the BLE113), but I felt like it was too abstracted to be able to do what I really wanted it to. 2/10, they're just not that into me.