How to Choose a Microcontroller for Your IoT Project: A Practical Guide

Most microcontroller arguments happen backwards. Someone picks a chip they like, then spends three weeks discovering the battery can't power it, the radio can't reach the basement, or the vendor's SDK stopped getting updates two years ago. The fix is boring and effective: define the device's job first, then let the constraints eliminate candidates until one or two remain.

Here is how to run that process without falling into the usual traps.

Start With the Job, Not the Chip

Write one sentence describing what the device must do in the field. For example: "Read a soil moisture sensor every fifteen minutes, send the value over a long-range radio, and run for two years on a lithium cell." That sentence already rules out a lot. It kills Wi-Fi, it makes display support irrelevant, and it puts sleep current at the top of the priority list.

Before opening a single datasheet, answer these:

• How often does the device wake, and how long does each wake last?
• How much data goes out, and how far does it travel?
• Is power mains, battery, or harvested?
• How many units, and who maintains them?
• Does firmware need over-the-air updates?

A device plugged into a wall socket should not pay a premium for ultra-low-power silicon. A sensor sealed inside a wall should not ship without a way to update it.

Power Consumption Is a System Property

Sleep current in the datasheet is a starting point, not an answer. What matters is average current over your duty cycle: sleep current, plus wake-up time, plus the energy the radio burns getting connected, divided across the interval between transmissions. Wi-Fi association can dominate that budget. A BLE connection interval or a LoRa transmit burst is a very different shape of energy.

Then look outward from the chip. A 1 µA microcontroller is wasted if the sensor draws 4 mA continuously, if the voltage regulator has a high quiescent current, or if a pull-up resistor leaks across a switch you left enabled. Common culprits:

• Always-on sensors and their warm-up time.
• LDO regulators with poor light-load efficiency.
• LEDs, including the power indicator nobody removed.
• External flash left powered during sleep.
• Board-level leakage from debug circuitry.

Measure early. A shunt resistor with a scope, or a dedicated current profiler, will tell you more in an hour than a week of datasheet comparison. Prototype on a development board, but plan to measure your own PCB, because dev boards carry extra components that quietly ruin the numbers.

Connectivity: Choose the Radio Before the Chip

Often the radio decides the microcontroller. If your product needs Wi-Fi and Bluetooth, Espressif parts are the default starting point for good reason. For Bluetooth Low Energy, Nordic and similar low-power families dominate. Zigbee, Thread, and Matter designs usually lead to Silicon Labs or Texas Instruments. Long-range, low-data applications point toward LoRa modules, while wide-area coverage leans on cellular modules from Nordic, Quectel, or SIMCom.

Two things get overlooked here. First, antenna design and RF certification are real engineering costs, and a pre-certified module lets you inherit the module maker's approvals. Using a bare radio chip means you own the testing. Second, radios need headroom in your power budget and your enclosure. A metal case, a ground plane that's too small, or a hand on the antenna will change link range in ways the datasheet won't mention.

The right microcontroller is the one that makes the boring parts of your project boring.

Cost Means More Than the Unit Price

The chip is a small fraction of what you spend. Count the whole bill: external flash, crystals, RF matching components, decoupling, PCB layers, assembly complexity, and the time spent debugging a toolchain. A module costs more per unit but saves weeks on a first revision. A bare QFN saves cents at volume and costs you an assembly step and a yield risk.

Certification and firmware development usually dwarf component cost at low volumes. If you plan to build fifty units, optimise for your time. If you plan to build fifty thousand, optimise the board.

Ecosystem, Tooling, and Longevity

You will spend more hours in the SDK than reading the reference manual. Check whether the vendor ships working examples for sleep modes and radio stacks, whether Zephyr or FreeRTOS support exists, and whether the community answers questions in days or never. A popular part with a mediocre datasheet beats an elegant part with no examples.

Also check availability. A part that only one distributor stocks, or that has been marked not recommended for new designs, is a schedule risk. Ask what the vendor's roadmap looks like and whether a pin-compatible successor exists.

For prototyping, Arduino and MicroPython are perfectly reasonable. Commit to C or C++ (often on Zephyr or FreeRTOS) before you ship, because power management and radio control tend to need it.

An Afternoon Selection Method

1. Write the one-sentence requirement and a rough power budget.
2. Pick the radio, then shortlist three microcontroller families that support it.
3. Buy two development boards from different families.
4. Build the hardest path first: wake, measure, transmit, sleep, repeat.
5. Measure real average current on both boards.
6. Check stock, lead times, and SDK release history before deciding.

Red flags worth taking seriously: no changelog for the SDK, no sleep-mode examples in the vendor repository, a debug header you must solder by hand, or a single-source part with a long lead time.

Prototype, Measure, Then Commit

Buy the boards, run the benchmark, and keep one fallback part in the schematic footprint if the design allows it. Modules with the same pin pitch and supply range make that swap cheap. Document why you chose the part, including the numbers behind the decision, so the next engineer does not relitigate it.

Get the sleep current right before you add features, freeze the radio configuration early, and test on the hardware you intend to ship. Choosing a microcontroller is not about finding the best chip on the market. It is about finding the one whose weaknesses your project can live with.

Photo: Thomas1311 / Pixabay