Starting a new microcontroller project can be pretty daunting. While you have at least a rough idea of where you want to end up, there are so many ways to get there that you can get locked into “analysis paralysis” and never get the project off the ground. Or arguably worse, you just throw whatever dev board you have in the junk bin and deal with the consequences.
While it’s hard to go wrong with relying on a familiar MCU and toolchain, [lcamtuf] argues in this recent guide to choosing microcontrollers that it’s actually not too much of a chore to make the right choice. Breaking the microcontroller universe down into three broad categories makes the job a little easier: simple process control, computationally intensive tasks, and IoT products. Figuring out where your project falls on that spectrum narrows your choices considerably.
For example, if you just need to read some sensors and run a few servos or solenoids, using something like a Raspberry Pi is probably overkill. On the other hand, a Pi or other SBC might be fine for something that you need wireless connectivity. We also appreciate that [lcamtuf] acknowledges that intangible considerations sometimes factor in, such as favoring a new-to-you MCU because you’ll get experience with technology you haven’t used before. It might not override technical considerations by itself, but you can’t ignore the need to stretch your wings once in a while.
There’s nothing earth-shattering here, but we enjoy think pieces like this. It’s a bit like [lcamtuf]’s recent piece on rethinking your jellybean op-amps.
The author recommends 8-bit mcu’s over 32-bit ones for basic tasks, but picks the fastest 8-bit and the absolute slowest 32-bit chips to put together, and completely ignores the normal M3/M4 tier. I’m scratching my head at that one.
The other claim is that the 8-bit ones are “easier”, but that really sounds more like they’re talking about Arduino… and you can easily use that on the 32-bit chips as well.
Author here. The overarching theme are three broad use cases. The first one is process control, and there… you can certainly use M3, M7, or even an SBC, but the point is, you generally don’t need to. M0 is typically enough. The reason I’m not including very dated and limited 8-bit chips in that category – ATtiny, low-end PICs, etc – is that these are rather limiting for that use, and aren’t dramatically cheaper anymore.
As for Arduino – there’s no mention of Arduino in the article, and it’s not something I intended to suggest.
ive been here, optimizing code and feature for limited microcontrollers. and when comes to production i scratch my head turn out : not always higher microcontrollers are more expensive than the lower one. so in short what ever my project I use most cheaper microcontroller. like blue pill has lower price than attiny85 even arduino uno clone. even esp is lower. so use the one cheaper is my good to go
Since I found out how many different STM32F106 clones are manufactured in China, I do not use anything cheap like a Blue Pill anymore. Atmel AVRs are routinely remarked with newer date codes in China. Because Atmel recommends to not use any chips older than 3 year (I think, maybe it’s 5), and they can’t sell the older chips otherwise. And how many different illegal ATMEGA328P clone designs are out there, I don’t even want to know.
Since about 10 years time, you simply don’t want to go for the cheapest anymore. Because the cheapest is never directly from the original manufacturer itself. It’s always a clone disguised as the real thing. Or maybe not even disguised as the real thing but properly marked differently, but coming with a substandard datasheet, which means you will have to get support from people who are overburdened with support calls and cannot give you the attention you require.
Go for the cheapest, but directly from a reputable manufacturer. Which is never the really cheapest, but for good reason.
Personally, I don’t mind clones as long as they perform to spec.
“Don’t use a chip that’s older than 3 years” is a very odd statement. What do they have a static discharge with timer designed to fry it after 3 years? (Facetious).
There are plenty of other options now for Dev boards that use genuine chips. Like STM32 G0 G4 F4 H5 H7 U5, etc. and as far as I know they haven’t been cloned yet, most of the cloned ones are STM32 F1 or other older MCUs.
I do wonder if ARM designstart could be part of the reason for which MCUs are cloned, basically they made M3 and I believe M0 cores available for free.
Anyway if you stick to newer and more complex MCUs you are less likely to get a fake. It also helps to use reliable Chinese vendors, preferably ones that design their own dev boards like “WeAct Studio”, random stores that sell common dev boards like the bluepill and whatever else they can find are usually best avoided other than for price.
For anything serious using chips from a reputable supplier is best though.
As someone who as written ASM and register level C for AVRs and for SAM 32bit processors…..
the 8 bit AVR processors are massively easier to work with. you can’t do as much with them in some senses, but if they will get the job done, and you need to be working at that low of a level, the time it saves on development can be worth it
Why do you think 8-bit AVRs are easier to work with than Cortex M0s (or M3s) at assembler level? I like both, but to me they’re fairly comparable.
AVR advantages: Number of registers; slightly simpler instruction formats; immediates can be be loaded with inline code; logic operations with immediates; division instructions; single instruction I/O access.
Cortex M0/M3 advantages: 32-bit registers; PC relative addressing; push/pop multiple; greater branch conditional range; some 3-operand registers; more address registers; [reg+reg] addressing; SP relative addressing.
Both of them have quite a lot of instructions and instruction formats.
I never programmed assembly for RISC processors. How do you optimize your ARM code for keeping the pipeline filled and make use of branch prediction, so that your code runs in a fully predictable time? I mean: one wrong instruction at the wrong time, might clear the pipeline and add multiple extra clock cycles to your code.
With those 8-bit RISC processors that basically have a CISC-like instruction set and are simply uncomplex, your code is predictable always.
That last is the reason why I go to PIC or Atmel for simple things. I can precisely predict timing for just about everything. Are you saying that I shouldn’t worry so much about ARM and that they are just as simple and predictable as a PIC16 or so? Not attacking you, just asking about your experience with ARM.
Mainly that it’s a lit simpler to fully understand the perfrerials, and setup / config for them is a lot more straight foward.
My experience is specifically comparing avr with samd21, so other 32bit systems might be more straight foward, but if I recall, just about every perfrerial I needed to set up took a good 2-3 times longer to figure out.
I’m sure if I spent several months fully understanding the details it would wash out, but I don’t do enough embedded dev work at that level to put that time in.
Take a look at the datasheets for say atmega328p vs samd21. Couple hundred pages vs closer to 700 pages if I recall.
If you need the performance of the more complex processor of course, then go for it.
If you’re working at a high level, say using existing libraries for everything, it gets things back to parity.
Well, this article fails in the basic steps, because it doesn’t mention the errata. First you select the uC which probably fits, the next step is check the errata if all of your peripheral/function would work properly!
And there comes the huge difference between 32 and 8 bit micros: 32 bit uCs have multiple times of bugs compared to 8 bit uCs, which have to handle/work around/check, so if you can fit your code in 8 bit uC then it will be the safest way.
For my purposes, 5 volt support is everything, and that means 8 bit, because there simply are no 32 bit microcontrollers with enough noise margin.
Why not just take an ESP and be done with it?
If you’re ever turning it into a product and you don’t need wifi/bluetooth then the radios will just be a liability by the time you have to get it certified.
Also xtensas are weird cores, there’s always an RTOS and you likely have to program them over serial. Having SWD always available on an ARM and already hooked up by default to a debug probe is quite handy.
ESP32 chips have impressive low power modes, but the transmit modes take a lot of power so there’s a weirdly wide range.
The SDK is surprisingly nice, just a little complicated.
You need to separate the hardware from the firmware. I doubt there is anything that forces the use of an RTOS, just like how you can program x86-64 bare metal too if you really wanted to. However espressif really pushes the use of an RTOS by making it the default for their sdk. They do have RISC-V core MCUs too though.
Then, just use an ESP32-P4 – no radio
3.3V? Ew!
maybe you need an ADC, or care about low power, or something physically smaller? ESPs niche is wireless, and thats just a tiny slice of possible projects
The ESP32 line is good but it isn’t a good option for everything. You could apply your statement to just about anything. Why not just use a pi pico W for everything? Why not a pi zero? Why not an Arduino?
If you are just doing basic stuff then your choice of MCU might not matter much but there are significant differences between different MCUs.
Even ESP32 has lots of different MCUs in its product lines.
“With a platform like ESP32 or RP2040, your future selection is limited” Huh? Have yo seen Espressif’s line up?
He totally ignores the IDE’s for the other platforms. Take Microchip’s IDE for instance. For as long as they have been around, their IDE are still antiquated.
The main thing he neglects to understand is the cost of stocking 5 different micros cuz you think its saving you money. It’s cheaper to buy 10k ESp32’s and use them in all your products even if it overkill than to stock 10k of this one 2k of that one, 2k of yet another and so on.
The only thing I would even consider using apart from Espressif, was Atmel, but since microchip bought it they ruin everything they touch.
The article is directed at hobbyists. We don’t tend to buy in units of 1,000. I personally buy MCU’S specifically for each project, in units of 4 or 5, although I sometimes buy a couple of extra for the parts bin. So choosing a different part for different projects is reasonable.
Is it though? There is considerable cognative load having to know multiple micros and franeworks/ide’s …
For simple IOT tasks i use whatever ESPhome supports, because from a framework point of view it is amazing.
For simple ‘control’ tasks I still like 8bit atmels chips, sadly now poisoned By microchip. Whats nice about the classic atmels is they are super simple. You can understanf these chips quite easily and don:t need much in the form of frameworks. i think what helped alot is the avr C library and the headers that is a clean (albeit classic) “Framewotk”.
For rrally powerful stuff, where the rp2040 and esp32 is not enough, or where the peripherial support is lacking, stm32, though the danger here is, the lineup is huge. But if you need a CEC peripherial, or something, other then bit banging …
Anyway, yes its nice having 20 different mcu’s, learning and using them is hard, which I think is more true for a Hobbyist.
And having to deal with all differebt toolsets makes it why pi and esp are so popular. Sure they may be over powered, but for a hobbyist budget it doesnt matter much.
It really isn’t that hard to switch between MCUs once you know the core concepts and can read data sheets and manuals and examples.
I don’t know man, as a hobbyist myself I have found out that optimising for cost always works well. I just select the cheapest part which has all the features I need
I can see that. I am always size constrained so I go for what fits.
The “your future selection is limited” is just a stupid utterance. Espressif is constantly coming out with new microcontrollers and broadening their selection, including the ESP32-H2 which is meant to be a coprocessor to add IEEE 802.15.4 and Bluetooth to one’s projects. Not to mention them expanding to microprocessors as well.
I agree with you, microchip was the kiss of death for atmel.
It’s going to be Arduino, ESP, or STM32.
Arduino isn’t a microcontroller. Also, you can use Arduino with both the ESP32 and STM32, so your comment doesn’t make sense from that perspective, either.
Ok. It’s an ATmega328, ESP, or STM32.
By “Arduino” we mean an original Arduino, such as Uno or Nano.
In the past it was a PIC or nothing.
Why won’t you simply rename yourself lcamtuf-a-day?
Dude is an ex-googler and former wikipedia sysop who used to be on a non-stop power trip. Now that it’s gone, he’s starving for attention and trying to stay relevant so he went into posting low-effort embedded engineering
articlesbait pretending to be a specialist and you’re falling for it.So how exactly is that different from most of the articles linked here? ;-)
Please, produce some high effort embedded engineering articles yourself so we can understand the difference.
Personally I would use the RP2350 unless I need low sleep current or bluetooth or wifi. Then probably an ESP32 or (reluctantly) a low power stm32. SDK quality, Documentation, Examples, modern Open Source on GitHub or similar and friendly community all matters.
Downloading zip files and installers off websites where you have to sign up and interacting with the community through ancient forums is always a bad sign.
Also check vscode or other modern standard IDEs’ integration.
I’d rather sodomize myself with a toilet brush than use VS Code. An IDE which doesn’t support (and won’t – becuase Electron) proper sub-pixel font rendering (ClearType) is a joke.
Unless you’re using an old screen with resolution <2k this makes no difference
Most PC monitors are still 1080P or less. Proper sub pixel font rendering is absolutely necessary.
Huh? It is just chromium. Do you have the same issue in Chrome or any other chromium based browser?
With that said the main reason I don’t use windows is because of the terrible and inconsistent font rendering. Especially once you get to multi platform software like IDEs and anything CAD related. Windows users seem to tolerate that sort of thing so it never gets fixed.
But whatever – Use Intellij or whatever you prefer – my same rule for “is this a microcontroller ecosystem I want to buy into” applies there too.
My largest gripe with stm32 is that almost all blue pills you get online are fake and stmcube ide does not want to program them.
Move beyond the blue pills then. There are plenty of other STM32 dev boards with better MCUs for similar prices. I have seen STM32 C0 G0 G4 F4 U5 H5 H7 all available at reasonable prices and those aren’t fake.
i didn’t find anything of value in this write up, not least because it specifically poo poos the correct choice for well over half the hobbyist projects i see (excluding the ones that need a command shell), which is the rp2040. author says it doesn’t have onboard flash, but it does have onboard flash. it only doesn’t have onchip flash.
use what you know and what you have and if you don’t have or know anything yet then it’s hard to beat the rp2040 boards. there’s still a place in my heart for pic12, but the rp2040 does almost everything, the price is great, and the support is much better than raspberry pi (which it certainly doesn’t ride on the coat tails of!). the thing you want isn’t the perfect set of features but rather one general microcontroller that you can get used to and then leverage that familiarity in dozens of projects. that’s the rp2040!
i mean a lot of people are loyal to stm32 or esp32 for the same sort of problem domain. that’s fine. never change! but man rp2040 doesn’t have the downsides we were used to!
of course if you’re mass-manufacturing then it’s not a hack and you’ll be looking at a totally different set of trade offs. at scale, you won’t be saying things like “$4/unit for the rp2040 sure is cheaper than $25/unit for stm32 value line discovery dev boards”
so here’s my version of this same article:
if know an mcu then use it else use rp2040. if not like rp2040 then you’re ahead of this article and you don’t need my help.
This. Every MPU is a collection trade-offs, the IDE being perhaps the biggest (and steepest hill to climb).
And, the RP2350 (Pico2 for a module) is a good follow on to the 2040. The B version has more I/O pins and the RP2354 (has on chip (er in package) flash.
The rp2040 is just the actual chip, the board is the pi pico. So if it doesn’t have on chip flash then if doesn’t have flash, sticking if on a dev board doesn’t count as the chip having flash.
If you are mass manufacturing why would you be buying mass quantities of dev boards? You would still only buy a few dev boards but buy lots of the chips, so scale doesn’t apply to dev boards. The rp2040 is not $4 per unit, that is the pi pico dev board.
So what downsides do other MCUs and MCU families have that the rp2040 doesn’t?
Calling the rp2040 the “correct” choice for over half of hobbyist projects is just incorrect since there is no such thing as the correct choice, it is all up to specific requirements and personal preference. It is a good choice for hobbyists but it is far from a universal, good for everything MCU.
i said all that.
anyways the thing rp2040 has is that its dev board is cheap and powerful and convenient to program. it’s not sporadically documented like the esp32 (which maybe has improved since i looked into it, who knows), or shipped millions of quantities with severe known defects (like the blue pill), nor expensive (like the stm32 value line discovery). and it never puts you on aliexpress clicking around looking at vaporous too-good-to-be-true pricing. the too-good-to-be-true price is available even on adafruit and sparkfun.
but yeah if you know another board then use it, by all means. preference and familiarity is #1. but the rp2040 is a universal good for everything mcu with only a few limitations. it doesn’t have the lowest power low power modes but it does have low power modes. it doesn’t have the absolute best peripheral io controllers but dang it has some great peripherals. it doesn’t have the easiest-to-use development board…oh wait actually i think it does. it doesn’t have the fastest arm core but it’s pretty fast! about the only thing i think might frustrate you is if you really wanted to drive 5V logic output.
The familiarity factor means the best microcontroller for the job, for you, might not be the same one that’s best for someone else. I’ve brought a dozen products to market with PIC16’s which I got started with in the mid-1990’s when there weren’t many choices. In spite of their many mickeymousities, I can whip up something fairly quickly because I’ve learned the gotchas and the nuances that don’t come through in the datasheets (at least not clearly), and I have plenty of my old code I can recycle, including my program-flow-control structure macros. I’ve used PIC16’s in multitasking systems where I’m switching tasks 10,000+ times per second with timer interrupts going for sampling audio firing at 78.125kHz, with no jitter caused by task switches. The price of the microcontroller in the systems I’ve designed PIC16’s into was a very small percentage of the overall product cost, and our production volumes have been small compared to commercial products; so the speed of developing bug-free code with a familiar platform was more important than shaving a few pennies or a dollar off the cost by moving to a different microcontroller. The last PIC16 project for work was last year, 2024. These projects had very minimal human interface; so there was no need for something that could do color graphic displays and other things that need the greatest processing power.
When many were saying 8-bit was dead, Electronic Design magazine published an article eight years ago about 11 myths about 8-bit microcontrollers. See https://www.electronicdesign.com/technologies/embedded/digital-ics/processors/microcontrollers/article/21802087/11-myths-about-8-bit-microcontrollers
(1) If you never used a microcontroller and need to choose one, choose one that others use too, so you can find lot’s of examples and lot’s of tools. This will get you started quickly, keeps you going as other people have most likely encountered the same issues as you will be encountering, so you can google for “support”.
Then you evolve from there, choose a higher or lower end model from the same family.
(2) If you already are familiar with microcontrollers you most likely choose the same microcontroller you used in previous projects, since you are already familiar with these so you know the ins/outs and possible pitfalls. You most likely are able to re-use some old code and quickly get you project of the ground.
(3) Then there is cost combined with availability, the most perfect microcontroller is useless if you can’t buy it or if your project budget doesn’t allow it. So in many cases, choose a possible supplier, list the available option sorted on cost, check the production status, check for required tools (programmer hardware and the desired compilers (some are free with limitations, some are hideously expensive). Chances are that you’ll end up at point (2) again and stick with what you’ve already got.
Very good advice..thank.
These days I just stick to the RP2040, or ESP32 if I need wifi. They both have configurable serial hardware and enough power to do most tasks.
I always start with a dev board because they are dirt cheap and save a lot of time. (Especially if I want ethernet, then I use the Wiznet W5500 evaluation board)
Life is too short to muck about with asm and 8 bit micros, unless you really need to.
There is a very simple selection criterion: take the one that can fulfill the desired tasks, offers the best price-performance ratio and has the lowest transaction costs for your projects.
On an industrial scale, this can mean taking the smallest suitable microprocessor, but for me at home it means taking an ESP32 for mobile tasks and a Raspberry Pi as a server. The Raspi because it’s there, the ESP because they solve every task quite well and are cheap, can be easily integrated into existing networks, the libraries are extremely extensive and I don’t have to familiarize myself with other systems, but can simply use my own libraries (incl. OTA-Update and web interface).
And that can be a different microprocessor for everyone, so please don’t start a stupid discussion like this but xyz is better. The ESP is only good for me(!).