Due to their low price and amazing capabilities, microcontrollers (MCU) find their way into almost every application, from huge systems-on-chip (SoC) devices in automobiles to tiny 8-bit devices in sensors. Once you’ve found a microcontroller family that meets your needs, you’ll probably stick with it for as long as possible to make the most of the knowledge acquired on the processor, development environment, and debug tools. However, one day an application need will arise that demands something different. Here we provide an approach for rapidly and successfully evaluating today’s modern microcontroller offering!

Need a Microcontroller?

When it comes to microcontrollers, we’re not short of options. And that’s not surprising. With the global market estimated to grow to more than $20 billion by 2027, there is bound to be plenty of competition. For those searching for microcontrollers, this is seen as positive. It encourages suppliers to innovate their products, providing a rich palette of devices with diverse capabilities, functions, and features. However, with a burgeoning bag of options available, how do you go about selecting the optimal microcontroller for your application?

It’s easy to get caught up in bit widths, megahertz, and memory sizes, but these parameters alone make it challenging to compare different products. Furthermore, many applications have a specific characteristic that defines them: long battery life, high integration, flawless security, or functional safety. It’s worth taking the time to review your overall needs before starting on the search for your ideal microcontroller.

Clearly Define Your Application Needs

The first step is to consider the use cases for the product you’re trying to build. This covers things like:
 

  • The human-machine interface (HMI): do you want mechanical pushbuttons or capacitive touch (Figure 1); monochrome or color display; polyphonic sound, or perhaps just a simple buzzer?
  • Power consumption: should the device operate for years on a CR2023 cell, or will it use a wall wart power supply?
  • Interfaces: do you need to be compatible with existing protocols (USB, Ethernet, Modbus, CAN, I2C, and SPI)?
  • Inputs and outputs: do you need analog, and, if so, what accuracy is required? How many digital signals are needed? Are timers and counters required?
  • Real-time capability: brushless motor control and digital power supplies demand response times measured in nanoseconds, especially under short-circuit conditions. This may require dedicated peripherals on your microcontroller.
  • Size: will your printed-circuit board (PCB) be limited in size, restricting the size and type of IC package used?
  • Manufacturability: are you able to solder the packages on offer, especially during prototyping?
  • Security: Is a secure programming environment required for handling cryptographic secrets?
Microcontroller support for touch (Schurter)
Figure 1: Microcontrollers often provide on-chip support for touch interfaces, but may also place challenging timing demands on your application (Source: Schurter).
The next step is to review this list to consider what absolutely has to be inside the microcontroller and what could potentially be off-chip. If your product is space-limited, you’re going to want a highly integrated device. However, suppose you have room on your board and high expectations of the analog signal path. In that case, you’ll probably be happy to consider an external analog-to-digital or digital-to-analog converter (ADC/DAC).

The price of the microcontroller obviously plays a role in the decision-making process. However, this will need to be weighed against the cost of external devices to implement features not available on the microcontroller. Furthermore, development time costs may outweigh any part savings if it becomes too complicated to implement a feature already integrated into an alternative vendor’s part.

How Many Bits and MHz? Which Microcontroller Core?

A decade or more ago, the number of bits and the precise core probably made a difference to an embedded microcontroller application, primarily to its price. However, with the proliferation of 32-bit Arm devices, low-end Cortex-M0 devices are as cheap as some 8-bit microcontrollers (Figure 2). And, although transistors are getting smaller, the cells used to implemented the flash memory do not shrink very well. Thus, it is the size of the non-volatile flash memory that often determines the price of the chip, not the size and complexity of the processor and its peripherals.

Microcontroller, dev boards
Figure 2: Today’s 32-bit microcontrollers can be as low in cost as some 8-bit alternatives.

One method to determine if a microcontroller can handle your planned application is to create a simple project that executes critical code sections. After compiling, download it to the microcontroller and use the debugger to see how much flash and SRAM memory it requires. By additionally toggling a GPIO pin during execution, and monitoring this output with an oscilloscope or logic analyzer, the execution time for sections of code can be determined.

Before wasting time learning a development environment you’ve never used before, you may want to compare potential microcontroller options using the EEMBC CoreMark benchmarks. CoreMark is a set piece of application code that provides comparable performance measurements of the microcontroller’s processor. Because configuration settings can make a difference, results are recorded with both the location of the code (flash or SRAM), the version of the compiler used and options passed, and other relevant information (Figure 3). Benchmarks aren’t perfect, but they do help to form a shortlist. 

CoreMark scores for microcontrollers
Figure 3: The CoreMark results from EEMBC provide a good starting point for comparing the relative performance of microcontrollers from different vendors. (Source: EEMBC)

How Much Microcontroller Memory?

Memory consumption is entirely application-dependent. Ideally, any existing code should be compiled to determine how much program memory will be required. SRAM needs are more difficult to determine as stack usage can only be determined at runtime. Thankfully, today’s software development environments make it quick and easy to determine. It is also worth examining the microcontroller family to see if, later on, a pin-compatible variant with less flash and SRAM could be used, especially if there are cost pressures.

Today’s consumers expect to be able to upgrade the software of their products. Most devices provide a protected area for a bootloader. No matter what happens, this will always be available, providing a method to flash firmware into the device. If the last old version of the firmware needs to be retained as a fallback, should the firmware upgrade go wrong, then this may require double the amount of flash memory to accommodate up to two versions of your code.

Finally, flash memory does wear out each time it is written. Flash memory for code, or program memory, can usually support tens of thousands of write cycles. If it is only used for code, this is fine, but should it be used for storing data or configuration information, wear needs to be considered. If data is stored in non-volatile memory, any available internal EEPROM or an external EEPROM should be used (Figure 4). 

Microchip EEPROM 25CSM04
Figure 4: When storing critical non-volatile data, it’s worth considering an external EEPROM when the microcontroller’s internal EEPROM is limited. (Source: Microchip)

How Much Power Will My MCU Consume?

If your application must deliver excellent battery life, it is essential to spend a lot of time examining the power consumption and power-saving modes each microcontroller offers. Power consumption depends on many factors, and each manufacturer has developed clever low-power modes that save energy but also impact the functionality of the microcontroller. For example, waking from a ‘sleep mode’ may use a low-frequency oscillator until the main oscillator has stabilized. This slows code execution which, in the grand scheme of things, may result in more power being consumed than planned. Selecting the wrong device at this stage could result in a 10% or more reduction in actual battery life (based upon bitter experience!)

Again, testing the basics of your application on an actual board is the best approach. However, this is easier said than done. Many demo boards and development kits make it challenging to isolate the microcontroller from the surrounding peripherals and chips. The best approach is to build a simple breakout board with just the microcontroller, decoupling capacitors, and, if needed, a crystal. With power consumption lying in the nanoamp range but jumping to micro- and milliamps levels when active, finding a measurement device that is accurate at the low end with a wide dynamic range is challenging. Specializing in this space is Qoitech with their Otii Arc. Their power measurement tool can also simulate the discharge of batteries, which can be very helpful (Figure 5).

Otii Arc
Figure 5: The Otii Arc from Qoitech provides the dynamic range needed to accurately measure microcontroller power consumption.

It should also not be forgotten what impact temperature, clock frequency, and supply voltage have on current consumption. The higher the temperature and clock frequency, the greater the current consumption. However, supply voltage has a power-of-two impact on current consumption. When running at the lowest allowable voltage, power supply stability must be carefully considered. Allowing the voltage to drop too low can result in the microcontroller entering a brown-out state.

Basic “marketing” technical data from microcontroller manufacturers can also be misleading. Microchip’s low-power microcontrollers offer “9 nA sleep currents.” However, attaining such a low current draw may demand some compromise. As an example, the PIC24FJ256GA412 does not retain the SRAM contents in its 60 nA Deep Sleep mode. Although critical application context data can be stored in two registers (DSGPR0/1), this still means that waking up will require a lot of execution time, and therefore power, to get the microcontroller back into a usable state. Thus, the power profile of the entire application must be carefully reviewed to see if such a low-power mode is useful.

Finally, the EEMBC also provides a family of Ultra Low Power benchmarks named ULPMark. Again, when starting to research devices, this can be worth reviewing to see where best to start (Figure 6). 

ULPMark benchmark results comparing the low-power capability of popular MCUs.
Figure 6: EEMBC also provides ULPMark benchmark results comparing the low-power capability of popular microcontrollers.

Which Peripherals?

For reasons that made sense many years ago, or because certain bus protocols were registered trademarks of other vendors, digital peripherals can be a little confusing. Most modern microcontrollers will feature one or more UART, I2C, and SPI interfaces. However, I2C may be called a Two Wire Interface (TWI) as one example of potential deviation. And, regardless of its naming, it may not support I2C’s higher clock frequencies, 10-bit addressing mode, or may not be suitable for use in SMBus or PMBus applications. The same risk of functionality variation applies to UARTs and SPI too. As before, it’s best to test rather than to assume the desired functionality is available.

Peripherals can also be very demanding on the processor, especially if an interrupt is generated upon reception of every byte. If lots of data transfers are planned, it is worth finding a microcontroller with a Direct Memory Access, or DMA, controller. These can be linked to a peripheral’s interrupt to transfer a fixed quantity of data directly to/from SRAM from/to a peripheral. Only once a substantial block of data has been handled is the processor interrupted so that it can undertake any processing required. The processor can also be placed into low-power mode on some microcontrollers while the DMA autonomously passes data back and forth.

Some microcontrollers have highly specialized real-time control peripherals. The TMPM375FSDMG from Toshiba is dedicated to vector control of brushless motors. It features a mathematical Vector Engine, three-phase pulse-width modulator (PWM) block, and ADC that operate almost autonomously. The processor only needs to jump in occasionally to handle changes in speed or in the event of an error.

On-chip analog peripherals, such as ADCs, have to be implemented in the same technology as the rest of the chip. This is not always the ideal technology, meaning that ADCs, DACs, and comparators may not be as ‘good’ as off-chip alternatives. The number of available bits in ADCs and DACs, along with the sampling/update rate, may also be limited. In such cases, a compromise must be made between the desired performance and other factors, such as board space, design complexity, and cost.

Microcontroller Design Support

This is a broad topic, ranging from development tools and boards to software libraries and support from third-party vendors. Most microcontroller vendors also offer development environments and compilers. If not, they will likely be supported by either IAR or Segger or other tool vendors. The microcontroller vendor or third parties will similarly offer hardware debuggers. A basic feeling for the development environment can be acquired by testing an evaluation or development board as these often have an onboard, feature-limited debugger integrated. Compilers are usually available for free, with restrictions such as no access to optimizers or code-size limitations. Many safety-relevant applications place high demands on documentation, so fully licensed compilers and tools are required for traceability purposes.

In recent decades, microcontroller vendors have realized that software libraries are essential to support embedded software developers. At a minimum, some libraries should be available that allow the vast majority of peripherals to be initialized and used. In many cases, full software stacks, such as USB and TCP/IP, are available. For more demanding applications, real-time operating systems are also ported to the key processor architectures, such as freeRTOS.

Another valuable gauge of potential future development challenges is to review the errata for the chosen microcontroller. Should the list appear surprisingly long, and some of the issues have no known workaround, it is probably a device you want to avoid. It is also worthwhile scouring forums for feedback from other users and to understand how responsive and helpful the vendor is when answering questions.
 

Questions or Comments?

Do you have technical questions or comments about his article? Email the author at stuart.cording@elektor.com or the Elektor team at editor@elektor.com.