Selecting an MCU

A micro controller is primarily a computing device that provides internal data and program memory and a high level of input and output (I/O) peripheral options. Using such processing technology helps to optimize the number of external peripherals that may be required for a particular system, project or application. Moreover, this also allows enhancing the scope for external interfacing to switches, motors and additional input / output devices.


There exists no cut and dried rule to decide if a particular microcontroller unit (MCU) befits for a given project or application requirement. Since the success or failure of your project hinges on how well you are selecting an MCU, this decision needs an evaluation approach that takes into account several key aspects. To begin with, one is required to assign a proper objective to MCU selection process – whether it is optimizing BOM, enhancing application / project reliability or a need for rigorous performance for R&D engineering activity. Ideally an MCU that delivers better performance, reliability, compatibility and conformance to standards and other requirements should be given priority. Lastly, one should also look at what kind of ecosystem exists for a particular MCU such as availability of development tools, manufacturer support etc. Also as MCUs continue to add new capabilities, it is becoming all the more difficult to decide which MCU fairly meets all key requirements for a project or an application. When choosing an MCU, a balanced approach keeping in mind the following aspects will prove useful.


Energy Consumption

The energy consumption of a processor depends on many factors such as the target technology (lithography size, process flavor, threshold voltages), the library of standard cells used to implement the core and the execution activity imposed on the processor during power simulation. From 90 nm and below as technology is shrinking, the static power consumption represents a significant part of the total consumption and has become more and more comparable to the dynamic power consumption. So both Static and dynamic power consumptions should be checked while selecting a MCU. If the application is battery operated then this criteria must be kept in mind.



Millions of instructions per second (MIPS) indicates the speed of a microcontroller. Higher the frequencies of operation of microcontroller, higher are the area and power dissipation. A microcontroller selected should have the best trade-off between frequency and area / power.



The MCU area depends a lot on the configuration considered. As a result, in order to compare the area of two MCUs, their configurations have to be purely the same.  Areas of MCUs are specified either in terms of number of (equivalent) gates or by giving a silicon area in mm2. For the same core area we get different gate counts depending on the gate selected from a specific library. Thus gate count is uncertain. Silicon area on other hand depends on many parameters: the lithography size and the process, the standard cells library used, the PVT conditions, the synthesis constraints (frequency, I/O delays, max cap, rest of SoC constraints, etc…), and if the result is pre or post place and route. Taking into account all these parameters, it seems impossible to compare area figures from different providers measured in exactly the same conditions. As a conclusion, a system designer should consider an MCU with lower nm technology, offering higher gate counts and logic.


Computing Power/Code Density

While evaluating the code density or the processing power benchmark plays an important role. Different synthetic benchmarks corresponding to different execution characteristics are available, for instance, Dhrystone: integer performance; LINPACK: vectorizable computations; and Whetstone: floating point intensive applications. To improve the limited capabilities of synthetic benchmarks, standardized sets of real application programs have been collected into six application-program benchmark suites specific to the area of the embedded market. The categories are Automotive and Industrial Control, Consumer Devices, Office Automation, Networking, Security, and Telecommunications. All the programs are available as standard C source code for being portable. In summary, select your benchmark carefully according to your application domain.



The “architecture” of a microcontroller refers to the philosophy of the internal implementation. It includes details like how many registers, whether code can execute out of data memory, whether the peripherals are treated like memory, registers, or something else, whether there is a stack and how it works, and so on. Below are the architectures that should be considered while selecting an MCU.

1)CISC, 2)RISC, 3)Harvard Architecture, 4)Von Neuman Architecture, 5)Accumulator based, 6)Load/Store

A RISC processor can handle simple math functions much faster, but a CISC processor will handle complicated functions faster because it can do them all at once instead of the several processing commands that a RISC processor would have to take to complete the same function.



The number of free pins decide how many different devices you can connect to the microcontroller. There are two basic pin types: digital input/output (I/O) and analog input/output (I/O). Other pin types include peripherals input/output (I/O) like UART, SPI I2C etc. and also Power & ground (GND). A microcontroller selected should have equivalent or adequate pin count, required for Embedded System.


Built-in Peripherals and Resources

The CPU is only a small part of the MCU needs and choosing your product based on which peripherals and resources you want is probably a way one should go for. Various built in peripherals and resources like ADC/DAC, UART/USART, Ethernet, CAN, USB, SPI, I2C, Timers, watchdog system, floating point arithmetic units, multiply-accumulate (MAC) etc. are now available in microcontrollers. According to the requirements, one should choose the right mix of them.



Memory devices include random access memory (RAM), read-only memory (ROM). A microcontroller with larger RAM and reprogrammable ROM is desired.

RAM: The selected microcontroller for an Embedded System should have enough internal RAM required for data memory. Some algorithms require substantial RAM to be implemented in a straightforward manner, and it may be worthwhile looking for a micro with a lot of RAM

ROM: The abilities to retain data after removing power and rapidly reprogram products have driven the move to flash. The size of Flash memory depends on the size of object file generated by the assembler/compiler. The size of Flash program memory is an important factor when the user has decided to use internal program memory. The user must have to keep in mind to keep few % (dependent on application nature) of free space in program memory for future requirements.


OS Requirements

Moving up to applications that require an OS, real-time or otherwise, in some ways reduces the complexity of the decision. You automatically disqualify a large portion of the available chips. Going with a generic OS like Linux or Android might very well move your decision tree into cost versus performance. The amount of expertise required at this level is likely to add a lot more engineering and less preference into the design choice than is possible in lower-end applications.


Languages Known

The most general division is between assembly and high level language programming. Assembly language is often used where code minimization or speed maximization is critical. High level language programming (often C) requires the use of a compiler to translate the more readable and structured program constructs produced by an engineer into microcontroller readable form C programs allow reusability, and advantages in debugging your system. Consider choosing a microcontroller with a large user community and existing free libraries.


Development and Debug Tools

Whether you program bare metal or are using an RTOS, you will be more than likely to use an IDE. A wide variety of options exist. These include: Simulators, ROM Emulators, Development Boards and Emulators.

The selection of a suitable development tool will be related to the available budget. Low complexity systems can be developed using low cost development boards and assemblers; more complex tasks require an emulator of some form.


Cost, Product Availability and Supplier

Cost is a major factor when targeting low budget applications. Select a microcontroller which is easily available and comparatively cheap, sufficing all specifications.


Third Party Support

One of the most important, but least recognized factors in selecting a microcontroller is the third party support available. Number of open source developers, experts, entrepreneurs, hobbyists keeps their work and product ideas on internet, which help many developers to start work in right direction and complete their design on the right schedule.



Very short deadlines make allocation of time to learning a new architecture more difficult, or even impossible, to justify. In that case, you’ll need to look at a part you’ve used before, or something similar.



It is very easy to make a processor assessment that leads to a wrong conclusion, because at each step of the evaluation, there are many possibilities to compare data that were not measured under the same conditions. In conclusion, selecting the right MCU for your project is not an easy decision, as MCUs have become more complex devices since on-chip resources are getting added. Also as the trend is towards more on-chip integration of off-chip resources to reduce system costs, the decision will become increasingly complex with time. This application note is not intended to make the choice for the designer, but to serve as a thought-provoking guideline as to all the possible selection criteria that should be considered in this important decision process.

About The Author


No Comments