MCU Selection and Development Ecosystem

On this page

A data acquisition node requires four channels of 20 ksample/s, 16-bit data, with 100 ms of buffering, and transmission via serial or wireless. "Having an ADC, Wi-Fi, and sufficient clock speed" is not enough to select a chip: whether the ADC meets precision and throughput requirements, whether DMA can perform continuous transfers, whether SRAM is sufficient, and whether pins can be simultaneously accessed are what determine if it can complete the task.

Application BehaviorSample, control, communicateResources and TimingsPins, Memory, LatencyCandidate devicesDatasheets + SDK + MeasurementsVerify Tightest ConstraintsPeak load, sleep, recoverySelection is a set of constraints that must hold simultaneously, not just hitting a brand nameInterface existence does not mean pins can be multiplexed simultaneously; total SRAM does not mean all SRAM is available for DMA; clock speed does not guarantee deadline adherence.
Problem to SolveEntry Point in This ArticleEvidence to Leave Behind
Where to narrow the candidate poolHard constraints and product familiesExact part numbers, packages, module variants
Is performance and memory sufficient?Continuous acquisition examplesData rate, buffer size, worst-case processing time
How to evaluate low power consumption?A complete operating cycleWake-up, sampling, communication, and sleep budgets
Can the dev board USB be used for debugging?Build, Flash, DebugUSB routing in schematics and debug chain
How does the prototype enter the product?SDK and maintainabilityFixed versions, recovery, upgrades, and errata handling

List Hard Constraints That Must Be Satisfied Simultaneously First

First determine power supply range, temperature, interfaces, analog performance, real-time deadlines, program/data capacity, and upgrade methods; then look at price, size, and development convenience. A chip having two SPI controllers does not guarantee that the selected package provides the two sets of pins needed simultaneously; ADC inputs, crystal oscillators, debug ports, and boot configuration may also occupy the same pins.

Datasheets provide electrical guarantees and package information, reference manuals explain register and peripheral operation, errata sheets describe silicon version limitations, and SDK documentation explains software support boundaries. These four types of documentation cannot replace each other. Modules may also occupy on-chip GPIO connections to Flash/PSRAM, and dev boards may connect LEDs, USB bridges, or other devices; you must verify against the final actually available pins.

MCUs typically provide control functions around on-chip memory and peripherals; MPU platforms often require external memory, more complex boot processes, and OS support. When Linux, graphics, or large applications are needed, the system-level solution should be re-evaluated; do not simplify STM32MP as just a higher clock-speed version of STM32 MCU. ST STM32MP1 Products and Software Ecosystem

Family Quick Reference: For Forming Candidates, Not Giving Fixed Rankings

Family / PlatformCapabilities to InvestigateDifferences to Verify Further
STM32 MCUGeneral control, analog, timers, low power, wireless, etc. (different series)Even within the same family, there are different cores, memories, peripherals, and pin compatibility conditions
ESP32 SeriesDifferent SoCs with integrated wireless and rich digital peripheralsNot all models have Wi-Fi or BLE; USB and cores also differ
Nordic nRF SeriesLow-power wireless and its software stackSoC, protocol features, memory, and application/network core responsibilities vary by model
RP2040 / RP2350PIO, custom timing, and Pico SDKMemory configuration, PIO resources, and core choices cannot be copied across generations
AVR ATmega / ATtinySmall control and specific voltage/package needsOperating voltage and frequency combinations, debug interfaces, and specific peripherals depend on the model

For example, ESP32-S3 is a dual-core Xtensa LX7, not single-core; nRF52833 includes full-speed USB and cannot be written as "nRF52840 without USB". These facts only describe chip capabilities; whether the dev board exposes these functions still requires reading the schematic. Espressif ESP32-S3, Nordic nRF52833

RP2040 has eight PIO state machines; PIO can implement many custom interfaces using limited instructions, clocks, FIFOs, and pin resources, but cannot simulate arbitrary rates and arbitrary physical layer protocols. RP2350 is already another generation of product with different cores and resource configurations; RP2040 parameters cannot be treated as all Pico platform parameters. RP2040 Specifications, RP2350 Datasheet

Similarly, "supports 5 V supply" does not mean all pins can accept 5 V under any supply condition; ADC resolution does not equal effective precision. Compare devices under the same purchasing conditions, workloads and measurement boundaries to make price and power figures meaningful.

Continuous Acquisition: Calculate Bytes and Time Clearly First

If the initial four-channel acquisition saves 16 bits per sample, the data rate is 4 × 20000 × 2 = 160,000 B/s. Retaining 100 ms requires 16,000 B, and double buffering requires 32,000 B; this does not yet account for protocol stacks, stacks, queues, static variables, and runtime temporary areas. If the raw ADC is 12-bit but DMA saves in 16-bit units, you cannot estimate actual memory usage by 1.5 bytes.

Example Budget ItemCalculationResult
Raw Traffic4 channels × 20 ksample/s × 2 B160 kB/s
Two 100 ms Buffers160000 × 0.1 × 232000 B, i.e., 31.25 KiB
UART 8N1 Transmitting Only Raw Data160000 × 10 bitAt least 1.6 Mbaud, excluding protocol overhead
Interval Between Samples Per Channel1 / 2000050 μs
Cycle Budget Per Group at 80 MHz80 MHz × 50 μs4000 cycles, still need to leave room for other tasks

DMA can reduce the CPU overhead of per-sample transfers, but it cannot make the data rate exceed the capabilities of memory and the bus. You must also confirm whether the target SRAM can be accessed by the corresponding DMA, buffer alignment, and consistency maintenance when caches are involved; "total 256 KiB SRAM" does not guarantee that all 256 KiB are suitable for any DMA.

Low average CPU usage does not guarantee real-time performance. Wireless stacks, interrupt masking, Flash erasing, bus contention, or higher-priority tasks can create the longest blocking times. Check critical paths using the maximum acceptable response latency, then determine if hardware triggers, DMA, independent peripherals, or task isolation are needed. When multiple channels share one ADC multiplexer, verify the total conversion rate and inter-channel time differences; do not assume simultaneous sampling.

Fast average writes, why buffer overflow?

Default 100 ms fills exactly 16 kB. Longer stalls leave the curve capped while loss rises, so staying within capacity does not imply lossless capture. Recovery drains at net 240 kB/s because acquisition continues.

Preparing the visual
Fast average writes, why buffer overflow?

Acquisition continues during a stall; the buffer must cover that area. Faster recovery cannot restore already lost data.

Flash Budget Must Include Upgrade and Data Partitioning

Assume the application image is 700 KiB, using two slots each holding a complete image, Bootloader is 64 KiB, settings and metadata are 64 KiB, totaling 1528 KiB. 2 MiB storage leaves only 520 KiB remaining, and in reality, it is also constrained by erase block alignment, image headers, signatures, swap strategies, and reserved areas. "Program is less than 1 MiB, so 1 MiB Flash is sufficient" does not hold for this upgrade scheme.

External XIP Flash or PSRAM is not a transparent expansion of on-chip memory. Cache misses, fetch restrictions during erase/write, DMA reachability, and power-down behavior all need to be confirmed per platform. Whether real-time interrupts must be placed in internal RAM, and which code can still run during upgrades, should be decided at the architecture stage.

Low Power: Compare a Complete Cycle

Assume sampling and sending once per second, with an active phase of 10 mA lasting 10 ms, and the remaining 990 ms at 5 μA; the average current is approximately 104.95 μA. Dividing a 220 mAh battery simply gives about 2096 hours; this is an ideal budget, excluding capacity variations, self-discharge, regulator losses, or actual wireless retransmissions.

Therefore, you cannot directly claim that BLE connection work also draws only a few microamps based on the datasheet's deepest sleep current. You must add crystal startup, sensor warm-up, connection maintenance, broadcast/retransmission, and storage writes; dev board power LEDs, debuggers, and USB bridges may also overshadow the MCU's own sleep current. Measurement boundaries should be defined down to the whole board input or a specific power rail, and verify whether the selected sleep mode retains necessary wake-up sources.

Build, Flash, and Debug Cannot Be Written as a Single "USB Support"

Source Code / ConfigSDK, Board, Linker ScriptCompile and LinkELF, Map, ImageTarget MemoryBoot ROM / BootloaderFlashDebug SessionSymbols + GDB + Debug ServiceProbe / On-Chip USB-JTAGBuild, Flash, and Debug are three connected but different capabilitiesUSB-UART or UF2 drag-and-drop can handle downloading, but do not automatically provide breakpoints, single-stepping, registers, and memory debugging.

The compiler turns source code into object files, and the linker combines startup files, libraries, and memory layouts to generate ELF and map files. Addresses and debug symbols in the ELF are used to locate runtime states, while the download image is written to target memory by the Boot ROM, Bootloader, or debug probe. The Bootloader handles booting and possible upgrade processes; it is not itself a breakpoint debugger.

USB-UART usually provides a serial port and download channel; UF2 drag-and-drop provides an image transfer experience; neither automatically equals single-step debugging. ESP32-S3's USB Serial/JTAG is a fixed-function hardware feature that can be used for serial console and debugging, which is different from the purpose of a generic USB OTG peripheral; specific dev board connectors may connect to a USB bridge or the chip's native USB, so you must check the board diagram. ESP-IDF USB Serial/JTAG Documentation

When selecting a dev board, confirm separately: recoverable download entry, available probe/debug interface, reset and boot pins, target voltage adaptation, and whether critical peripherals are exposed. A chip having a certain ROM download method does not mean any board can enter that mode from existing interfaces.

Software Ecosystem Determines Reproducibility and Maintainability

Arduino is a framework and tool ecosystem, not bound to AVR; using higher-level APIs does not prevent learning registers. Differences in HAL/LL, vendor SDKs, Zephyr, etc., lie in driver abstraction, scheduling, board-level configuration, and maintenance methods; they cannot be summarized as "Brand A can only do prototypes, while Brand B is suitable for products."

For example, Zephyr uses Devicetree to describe hardware structure and connections, and combines it with Kconfig to select software features; having chip support does not mean a custom board has completed board-level porting, nor does it mean all peripheral driver functions are complete. Zephyr Board Porting Guide

A minimally reproducible project should save exact chip/board versions, SDK and compiler versions, configuration, linker layout, and build commands, and retain map files. Key drivers need to check support status and errata handling; upgrades need to consider power-down recovery and image verification; debug locks and security configurations need to retain authorized repair paths. These tasks directly affect whether subsequent versions can be delivered stably.

The learning path can unfold layer by layer around the same small system: first use official examples to complete GPIO and logging, then add timer-triggered sampling and buffered transfers, and finally verify low power, error recovery, and upgrades. Tracing a complete peripheral path against the manual builds more transferable understanding than constantly switching brands for "advanced" features.

Recalculate Resource Budget

from math import isclose
rate = 4*20000*2
assert rate == 160000
assert rate*0.1*2 == 32000
assert rate*10 == 1600000
assert 80_000_000/20000 == 4000
used_kib = 700*2+64+64
assert used_kib == 1528
assert 2048-used_kib == 520
average_ma = (10*10+0.005*990)/1000
assert isclose(average_ma, 0.10495)
assert 2096 < 220/average_ma < 2097
print('Traffic, buffer, cycle, upgrade partition, and average current budget passed')

This article verifies budgets for assumed requirements; it has not measured specific MCU performance or power consumption, nor does it treat the examples as procurement conclusions.

Continue Reading