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).
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.
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.
Then, just use an ESP32-P4 – no radio
“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.
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
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.
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.
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.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
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.