Choosing a microcontroller

RP2040, ESP32, AVR, CH32V003, STM32...? When it comes to hobby projects, there's plenty of choice and just as much zealotry.

If you’re a regular reader, you might recall that I sometimes quip about hobbyists choosing single-board computers (SBCs) for projects where a much simpler and less expensive control scheme would do.

Soldering an MCU. Photo by author.

It’s not that I’m a purist; hardware and software choices matter less than the end result. That said, some choices just beget pain: if all you want to do is toggle some I/O ports, then a fully-fledged Linux system on a Raspberry Pi adds latency and scheduling jitter while offering little in return. And that’s before we consider all-too-common failure modes, such as a rogue background service filling up the SD card with temporary files or logs over the course of several months.

In today’s article, I’d like to offer something better than quips: let’s have a quick look at the choices you have for embedded control, breaking it down into three major use cases for programmable chips.

Case #1: process control

By far the most common hobby task is simple automation — that is, taking data from sensors or input surfaces, and then operating motors, small displays, or relays according to a straightforward plan.

Your project probably fits the bill if all of the following is true:

1. The algorithm is simple enough that no more than circa 16 kB of RAM is needed for mutable variables or call stack.

2. You don’t need to perform more than perhaps 50,000 floating-point operations or 32-bit multiplications and divisions per second.

3. There is no I/O that needs to happen at rates faster than about 10 MHz.

For a long time, these tasks have been the domain of 8-bit microcontrollers — first descended from the CPU architectures of the 1970s, but later supplanted by more modern designs, such as the AVR family developed by Atmel and now maintained by Microchip. The family includes the well-known ATmega chips, but also the more capable and cheaper AVR Dx series that relatively few hobbyists seem to be aware of.

Modern 8-bit MCUs are orders of magnitude faster than the 8-bit microcomputers of the old, but they prioritize hassle-free simplicity over raw speed. The chips support wide ranges of supply voltages, are packed with useful peripherals (ADCs, DACs, op-amps, core-independent configurable logic), and tend to have ultra-low-power sleep modes; but above all, they have uncomplicated internal architectures to yield predictable and consistent execution speeds without having to worry about bus contention, branch predictors, cache misses, or memory wait states.

In recent years, there’s been a proliferation of stripped-down, low-end 32-bit chips meant for the same uses; this includes the ST Microelectronics STM32L0 line and the Chinese CH32V003. These devices are typically based on ARM Cortex-M0 or RISC-V cores running at speeds below 50 MHz and sporting less than 32 kB of SRAM. Although “32 bits” might sound more modern, the technology offers no real advantage in this niche. There are hidden trade-offs, too: for example, CH32V003 has no integer multiplication circuitry. The devices exist simply because such chips are cheaper to make for any company that isn’t Microchip and doesn’t have an in-house 8-bit design team.

Case #2: serious compute

The limitations of budget platforms are evident by the time you’re processing high volumes of data. The scenarios where an 8-bit chip doesn’t cut it include performing object detection in a camera feed, decompressing a video stream, or playing Doom.

The compute category is the realm of higher-end chips with floating-point units, direct memory access (DMA) controllers, hundreds of kilobytes of fast built-in RAM, and clocks all the way to around 500 MHz. Top-of-the-line products are typically based on the ARM Cortex-M7 architecture, although some manufacturers opt for bundling multiple lower-end (e.g., Cortex-M3) cores on a single chip. The ICs might feature specialized circuitry for high-speed USB or Ethernet, along with hardware-accelerated media codecs or crypto routines.

The usual hobbyist-friendly choices include the ST Microelectronics STM32H7 series, along with Microchip’s SAM S70 / PIC32CZ. A number of other companies — including NXP, Infineon, and Renesas — also sell products in this range, but their offerings tend to be less accessible owing to subpar documentation and the scarcity of reference code. Last but not least, there’s the RP2040 / RP2350 line that rides on the coattails of Raspberry Pi SBCs; they’re nice chips, although a bit more of a hassle to use due to not having any onboard flash. (Their latest RP2354 product addresses that.)

High-end 32-bit chips are more finicky than their 8-bit counterparts, but the learning curve isn’t as steep as commonly believed; you can have a look at a “hello world” setup for a Cortex-M7 chip (ATSAMS70J21). Similarly to AVR MCUs, there is a well-developed open-source toolchain for these devices, although it needs to be pieced together from several loose parts.

Case #3: “the interwebs”

At some point, self-contained MCUs no longer cut it; this is usually not because insufficient compute performance, but because you need fast wireless connectivity, a beefy 3D graphics coprocessor, and several gigabytes of fast RAM. In other words, we’re talking about the specs needed to load all the trackers and ads on yahoo.com.

This is the rightful domain of single-board computers. These devices usually feature ARM Cortex-A processors and are running a fully-fledged operating system. As noted earlier, I/O latencies tend to be high and unpredictable, and the price of an SBC tends to be many times higher than that of a self-contained MCU; power efficiency is usually terrible, too. Still, it can be the best way to get things done. The added perk is familiarity: it’s just a Linux system you can SSH into.

The most popular hobby SBCs are the Raspberry Pi line, but there’s a huge number of competitors and clones to choose from. The most important specs are essentially the same as for desktop computers: CPU performance, RAM size, and GPU.

Linux systems aside, there’s also a “neither-here-nor-there” subcategory of RF microcontrollers that support wi-fi. Traditionally, because the protocol is fairly complex and computationally intensive, it was common to implement wi-fi as a separate module; that said, several module manufacturers figured out that they can spare some CPU cycles and give users the ability to run code directly on the wi-fi chip. The best-known example is the ESP32 series from Espressif; the price of this solution is hard to beat, so the platform is the go-to choice for simple IoT products paired to apps on mobile phones. If you have a “smart” coffee maker or litter box, there’s a good chance you’ll find an Espressif chip inside.

Tallying the costs

It’s tempting to look for the cheapest MCUs the market, but it’s also wise to remember that your time is not free. If you’re manufacturing cheap trinkets by the thousands, it might be a good plan to migrate to an MCU that costs $0.10 less than the chip you’re accustomed to. On the flip side, for hobby projects or small-scale products, the savings are probably not be worth the pain.

If you’re looking at a new platform, one question to ponder is whether learning the architecture will open more doors down the line. With a platform like ESP32 or RP2040, your future selection is limited; with ST Microelectronics or Microchip, you get an extensive range of chips with varied features and at different price points — all behind a common toolchain and a set of similar APIs. On the flip side, if you need dirt-cheap wi-fi, then a hundred products without built-in connectivity won’t do you any good.

👉 For more articles about microcontrollers, including projects featuring 8-bit and 32-bit chips, click here.

---

I write well-researched, original articles about geek culture, electronic circuit design, algorithms, and more. This day and age, it’s increasingly difficult to reach willing readers via social media and search. If you like the content, please subscribe!