Selecting the MCU is an important activity when starting a new project. Underspecify the MCU, and performance suffers; over-specify it, and the budget suffers. In either case, suffering is unwanted and unnecessary. It’s prevented by taking a thoughtful and thorough approach to MCU selection.

This FAQ begins with a review of the baseline performance numbers of an MCU, including MHz, bits, and bytes. It then looks at general system-level needs that impact MCU selection, considers high-performance applications and Internet of Things (IoT) applications, and moves on to factors related to the development environment and time to market. It closes with a brief look at supply chain considerations.

MCU selection begins with numbers like MHz, bits, and bytes. Deciding if the project needs an 8-, 16-, or 32-bit MCU is probably the best starting place; next is the operating frequency. In both cases, higher numbers provide more performance and cost more. There are many discussions about the tradeoffs for these specifications, like “MCU Bits and Bytes: sizes, types, and uses,” so this FAQ will move on to the choice of memory size.

Flash and RAM are important considerations when selecting an MCU. Of course, it’s not wise to overbuy, but running out of program or variable space can be disastrous. Getting to the end of a project and finding out that there’s not enough memory is regrettable and avoidable. The conservative approach is often to start with a part with more memory than is expected to be needed and then move to a part in the same family with less memory, if appropriate, as the project nears completion. While it’s always possible to develop a reasonably accurate estimate of the needed memory size based on the software architecture, communications, other peripherals, and product features, the nemesis of feature creep can impact even the best a priori estimates. It can also be wise to leave some room for added features in subsequent versions of the system. It can reduce time to market in the longer term.

Where to start?

When determining the amount of memory and processing power needed, one place to start is with the software architecture and general system requirements. The amount of computing power is a primary factor. Each task should be detailed, including how much processing power it will need and how long it will run. Will any algorithms need floating point mathematics, and will they benefit from a dedicated accelerator? What about any control loops? Will they be real-time or less time critical? What sensor inputs need to be handled? What’s the expected frequency of interrupts? Are their special needs such as functional safety or security? Will over-the-air updates be needed? The more detailed this analysis, the better the estimate of the amount of memory and processing power the design will need.

In addition to the general application requirements, it’s necessary to consider the need for communications interfaces and input/output (I/O) requirements. Communications interfaces like Ethernet or USB can require special consideration to define the needed performance specifically. I2C, UARTs, and SPI interfaces must also be included in the analysis. The number of digital and analog I/Os and other interfaces, such as pulse width modulators, are important. While the general application considerations significantly impact the computing power and memory needs, the number and variety of interfaces and I/Os can significantly impact the number of pins needed in the package (Figure 1).

What makes a high-performance MCU?

High-performance MCUs tend to be 32-bit devices with high operating frequencies. But there’s more to consider (Figure 2):

• Can the application be partitioned to benefit from a multi-core architecture? For example, in some real-time systems, one core handles the time-sensitive functions while the other handles more routine needs.
• Some MCUs have integrated programmable logic sections that support highly parallel and compute intense activities like image recognition or machine learning.
• Highly integrated and fast connectivity. Does the MCU support CAN and CAN FD? How about high-speed USB, Ethernet, or time sensitive networking? Connectivity extends to TCP/IP, TLS/SSL security, and support for wireless networking.
• Human-machine interfaces (HMIs) can be important considerations. Touch controllers, LCD drivers, and graphics accelerators to support high-definition graphical user interfaces (GUIs) are some of the possible needs.
• Security considerations beginning with secure booting are growing in complexity and importance. Are the security solutions scalable? Is there a complete ecosystem of software, hardware, and development tools? What about secure key provisioning and cryptographic capabilities?

ULP the IoT and MCUs

High performance doesn’t necessarily mean high power; it can also refer to ultra-low power (ULP) MCUs for advanced IoT devices. It takes an advanced MCU design to get down to the range of 40 μA/MHz and shutdown currents of tens of nanoamps. Like computing power, the definition of ULP is application-dependent. The balance between active and sleep modes is important. In most instances, MCU data sheets are good at describing the deep-sleep operation. But the conditions used can vary from vendor to vendor. To address the need for vendor-to-vendor comparisons, EEMBC developed its ULPMark-CoreProfile (ULPMark-CP) benchmark, where the MCU wakes up once per second, performs a small amount of work (the active cycle), then goes back to sleep.

The ULPMark-CP implicitly considers the energy used to enter and exit sleep mode and the energy consumed in active mode over a 1-second cycle (Figure 3). Like any benchmark, it’s only a starting point for comparisons. Each application is unique. For example, reducing the operating frequency of the MCU can reduce the active current. But it will take longer to perform a given task, counterbalancing, at least to some extent, the reduction in active current. That effect varies between MCUs and between applications. The actual performance can differ from the benchmark predictions.

It’s not just about the MCU

It’s primarily about the MCU, but there are other things to consider. For example, is there an evaluation platform available? What about a hardware development kit? Software development tools can be crucial to supporting fast time to market and optimal system performance.

Does the integrated development environment (IDE) include all the tools needed to speed time to market? A basic IDE includes a source code editor, build automation tools, and a debugger. Is that enough? More comprehensive IDEs can include a compiler, interpreter, or both.

And there’s the broader software development environment, such as a version control tool or tools for developing GUIs and other HMIs, as well as communications interfaces. Does the development team benefit from an IDE that integrates easily into an object-oriented software development environment? If the development team is geographically dispersed, is a web- or cloud-based IDE available?

The availability of drivers, peripherals, real-time operating system kernels, support for audio and voice processing, support for machine learning, computational accelerators, cloud connectivity, and special functions like motor control, functional safety, and wireless networking are all factors to consider.

Supply chain considerations

Last but certainly not least, in today’s business environment, designers need to be alert to possible supply chain issues when specifying all electronic components, including MCUs. Factors to consider include:

• Selection of “mainstream” MCUs can be helpful. Devices that are “exotic” or too specialized can suffer supply chain issues more quickly.
• The same applies to package selection; some package styles are more readily available than others.
• The ability to have dual sources is always a good approach. Does the MCU maker have multiple front-end and back-end sources, and are they geographically dispersed? If a single point of disruption exists, the supply chain risk rises.
• When possible, designing, or at least having the ability to design, daughter cards or motherboards using different MCUs to perform identical functions can provide a hedge against disruptions.

Summary

Specifying an MCU is a critical part of system development. The MCU needs to support all current performance requirements, and it’s often useful to leave some “excess capacity” to accommodate for feature creep and added features in next-generation designs. The number of I/Os and other interfaces is important when deciding on the package for the MCU. Choosing an MCU also needs to consider the availability of peripherals, accelerators, and, for IoT devices, the ability to support ULP operation. Finally, available development tools and supply chain considerations must be factored into the decision.

References

10 Steps to Selecting a Microcontroller, ARM
32-bit microcontrollers, Microchip
EEMBC ULPMark, EEMBC
MCU Basic Structure/Operation, Renesas
Strategies for Choosing the Appropriate Microcontroller when Developing Ultra Low Power Systems, Analog Devices
Top 10 Embedded Software Development Tools, Sam Solutions