How to choose a microcontroller: 12 questions to answer before selecting an MCU

A product team can shortlist hundreds of microcontrollers by core, clock speed or price and still choose the wrong device.

The failure usually comes from a requirement that was not treated as a selection criterion. The part has enough flash today but no room for secure updates. It exposes the right interface but not on pins compatible with the chosen package. The low-power figure assumes that the required peripheral is disabled. The device is available, but the programming tool is not suitable for production.

Answering the following questions before committing the schematic creates a selection record that engineering, purchasing and manufacturing can all use.

1. What must happen in real time?

List the functions with firm deadlines: control loops, capture events, communications responses, PWM updates, safety monitoring and wake-up behaviour.

Do not convert these directly into a clock-frequency target. Processor architecture, memory access, accelerators, interrupt latency and software design all affect execution time.

Create representative workloads and measure them on candidate hardware where timing matters. Leave margin for fault handling, diagnostics and future software rather than sizing the MCU around a demonstration build.

2. How much memory will the finished product need?

Separate programme flash, SRAM, retained memory, non-volatile settings and external storage.

The first firmware image is a poor sizing reference. Production code will add diagnostics, logging, security, communications and update support. Debug builds may need more memory than release builds, while field updates may require space for two images or a recovery loader.

Record both today's measured use and a justified growth allowance. If code must execute from external memory, include the performance, security and PCB consequences.

3. Which peripherals are mandatory?

Count actual instances, channels and capabilities rather than ticking interface names.

Two SPI ports may be insufficient if one lacks DMA or the required clock rate. An ADC may have enough channels but inadequate input range, sampling behaviour or effective resolution. Timers vary in capture, complementary-output, dead-time and encoder support.

Build a peripheral matrix covering:

• communications instances and modes;
• timer channels and pin locations;
• analogue inputs, references and comparators;
• DMA requests;
• encryption or security blocks;
• display, camera or audio functions;
• external memory interfaces;
• debug and programming access.

Check the exact part number. Features can differ within a family.

4. Can the pinout work in the intended package?

A peripheral shown in the block diagram may compete with another function on the same pins.

Use the manufacturer's pin-planning tool early. Allocate clocks, debug, boot configuration, programming, analogue inputs and communication buses before drawing the final schematic.

Leave spare GPIO where the product is likely to change. Confirm the electrical behaviour of every pin during reset and boot, particularly where an unexpected output could enable a power stage or actuator.

The smallest package is not always the smallest system. A larger package may avoid external multiplexers, improve routing and create a migration path.

5. What power modes must remain functional?

Average current depends on the complete duty cycle, not the lowest number on the datasheet.

Define time spent active, sleeping and waking. Identify which RAM, timers, communications peripherals and clocks must remain available in each state. Include regulator quiescent current, external pull resistors and sensor power.

Wake-up time matters because a deep mode that saves more current can require more energy and time to resume. Measure the whole board with representative firmware rather than relying on an isolated MCU figure.

6. What operating environment is required?

Select the temperature grade from the actual product requirement. Check whether speed, analogue performance or flash operation changes across the range.

Also consider supply variation, electrical noise, vibration, humidity and the required product qualifications. Automotive, medical, industrial and aerospace programmes may need particular quality documentation or long-term change control.

The orderable suffix matters. A commercial-grade sample should not be allowed to stand in for an industrial-grade production part without an explicit engineering decision.

7. What security functions are genuinely needed?

Security is an architecture, not a checkbox labelled crypto.

Define the threat model and identify the required secure boot, debug control, key storage, isolation, random-number generation and update authentication. Confirm how devices are provisioned in manufacturing and recovered in service.

Hardware capability without a maintained software implementation may deliver little protection. Check the manufacturer's security documentation, vulnerability process and software update policy.

Avoid features the organisation cannot operate securely. A complex key hierarchy with no controlled provisioning process creates risk rather than removing it.

8. Which software ecosystem will the team depend on?

Evaluate the compiler, debugger, configuration tools, device drivers, RTOS support, middleware and examples.

Run a small but representative exercise. Configure the clocks, bring up the required interface, build from source and debug an error. This reveals more than a polished demonstration.

Check licence terms and whether the build is reproducible without an online service. Record the tool versions used for release and confirm that the team can archive installers, packages and source dependencies.

If critical drivers are supplied only as binaries, understand the long-term maintenance consequence.

9. How will the MCU be programmed and tested in production?

Define programming voltage, interface, connector or test-point access, fixture requirements and expected cycle time.

Decide when unique identities, calibration values and security credentials are written. Establish how programming is verified and how failed units are recovered or quarantined.

Security settings can permanently restrict access. The production sequence must therefore be documented and tested before volume manufacture.

Ask whether the selected package can be inspected and reworked by the intended manufacturer. A technically capable MCU in an unnecessarily demanding package may increase yield risk.

10. Is there a credible migration path?

Pin-compatible devices can provide more flash, RAM or performance without a new PCB, but compatibility must be verified rather than assumed.

Check power pins, boot behaviour, peripheral mapping, package tolerances and software differences across the proposed family. A shared footprint may still require different decoupling, clocks or power rails.

Record at least one higher-capability option and one commercially acceptable alternative. This is not full second sourcing, but it prevents the original selection becoming an architectural dead end.

11. What is the supply and lifecycle position?

Check the manufacturer's lifecycle status, longevity programme and notification policy. Review availability through authorised channels and identify whether demand is concentrated in one package or grade.

The lowest current price is not necessarily the lowest lifetime cost. A well-supported device with a stable toolchain and several pin-compatible variants may justify a higher unit price.

Avoid approving a part solely because a distributor currently holds stock. Inventory is temporary. The design decision needs evidence about continuing production and an alternative plan.

12. What evidence will approve the selection?

Finish with a short selection record. It should state the requirement, shortlisted devices, reasons for rejection, assumptions, measured results and remaining risks.

Before schematic release, verify:

• memory use with margin;
• worst-case execution and interrupt behaviour;
• pin allocation in the exact package;
• power in representative operating modes;
• programming and debug access;
• thermal and environmental grade;
• software licence and maintenance position;
• lifecycle status and authorised supply route.

This record makes later substitution and redesign work much easier because the team can distinguish essential requirements from preferences inherited from the original part.

Selection is an engineering process

Manufacturer selection tools and distributor filters are valuable ways to reduce a large portfolio. They cannot define the product requirement or judge the cost of software and lifecycle dependence.

The most suitable MCU is the one that meets the complete requirement with defensible margin and can be programmed, secured, manufactured and supported throughout the intended product life.

Technical sources

• STMicroelectronics, STM32 MCU basics, including architecture, memory, power, peripheral, package and cost selection factors.
• STMicroelectronics, STM32 MCU product selector.
• NXP, Processors and microcontrollers product guidance.