How to Select Right MCU for Each Application ?

This very question stems from the need to cater application requirement as perfect as possible. When it comes to selecting a MCU based on parameters, almost all the manufacturers do provide parametric search engines / filters on their websites to choose the MCU from. However, most of the times the results from these filters are so much pointed that either you get a right choice or end up scratching your heads. In either case, these don’t help in just picking an MCU due to many other factors involved in selection. Let us see some of the critical consideration factors for choosing a microcontroller for an application…

This very question stems from the need to cater application requirement as perfect as possible. We don’t see a major difference between different families of the same class despite being from different vendors. Only because one company is more familier and may have practiced on XYZ company microcontrollers, MCUs manufactured by XYZ would be preferred over the others.

However, it must be noted that almost all the MCU manufacturers have competitive specifications and product-line in each segment, which means although there won’t be pin-to-pin matches you will easily find replacements for certain MCU from each of these manufacturers. And therefore, familiarity, convenience, prior relations, etc. would suggest which MCU to be selected for first filtering.

When it comes to selecting a MCU based on parameters, almost all the manufacturers do provide parametric search engines / filters on their websites to choose the MCU from. However, most of the times the results from these filters are so much pointed that either you get a right choice or end up scratching your heads. In either case, these don’t help in just picking an MCU due to many other factors involved in selection. Let us see some of the critical consideration factors for selecting of MCU for an application.

Basic MCU Family:

First step usually is to figure out which family or category of MCU to select from; such as 8 bit, 16 bit or 32 and above ? Within that category, are we needing any specific features or not ? And since, almost all the MCUs have basic requirements these days such as GPIOs, USARTS, high current driving pins, I2C, SPI, etc. these points are either moot or are lower in priority (as all the MCUs from certain vendor in certain family will have those features).

Electrical Characteristics:

These are often considered as a non-significant parameters by us for a simple reason that – for a given MCU supplier and selected family, electrical characteristics are almost the same for every type of part; and thus changing from one part to another may not affect electrical parameters. Memory size and other storage options are important though; such as Flash memory size, option for boot loader and size of boot section if available, SRAM, EEPROM, additional bank of memory, etc. and these are easier to select.

However, when choosing memory sizes (of all kind), we give a thought to scalability (if it is planned) such that tomorrow we may update the program which would need additional memory so installed MCU should have this margin already built-in. This margin although has to be around 15% ~ 20%, MCU sizes usually come in different slots such as 4KB / 8KB / 16KB and so on. Therefore, we go with closest possible option and when in doubt, go with one slot higher option.

Packaging & Cost

Packaging:

As far as the package type is considered, most of the MCUs are offered in multiple packaging options except those in higher range where DIP options are not given. We at Knewron usually prefer to go with SMT option due to two main reasons; small form factor and better electrical characteristics (such as EMI, power consumption, heating profile, etc.). There are only a few exceptions to choose DIP types where we are sure that removal of MCU is going to be frequent. A few such examples are prototypes, development boards, education kits and in some cases test setups.

Cost:

Cost considerations come in different forms: development cost and manufacturing cost. For low volume cost as in our case, development cost is paramount; however, in certain high volume cases it is justifiable to have additional costs of tools and learning curves.

There is another point which many a times makes some sense during buying activity. Say for example, we need mega168 and mega328 MCUs for our certain product and quantity needed is 500 each. Now you would get mega168 at lower price than mega328 for obvious reasons. However, when we are buying in bulk, we get some leverage for quantity; and by virtue of that leverage, we may get a deal where instead of buying both the items 500 each at two different costs, we buy 1000 pieces of only one type at certain cost. Vendor may offer to match total target price for such a deal. And thus sometimes we end up in installing mega328 in place of mega168 because from cost perspective we got them in same price and thus mega328 wins over mega168. In lower volume applications this may not be the case and hence above example is not always applicable.

Maintenance & Cost of Ownership:

Many a times, each type of MCU (family) comes up with specific programming methods, programmers needs and IDEs, tools, etc. This means changing from one family to other family of MCU not only changes MCU cost but & parameters but also additional maintenance and overhead cost, and in some cases total ownership costs too. This part is usually taken very seriously during choice of MCU in our firm. We usually do not prefer to use too many different types of MCUs in our products only to tightly match the application requirements. This would leave us too many tools of development and maintenance which unnecessarily blocks lots of money. Instead we carefully have chosen a few powerful devices and also a few low profile devices which we choose from. This helps in keeping our labs tidy and avoids shuffling from one tool to other.

Project Timelines & Tribal Knowledge:

Project deadlines always have higher influence on selection of MCU. Whenever we are having very short timelines; it doesn’t make sense to investigate and go for newly introduced MCUs or even changing between the families from what we are familier with. Although these can be learned, the time, learning curve and investment is not justifiable. More often than not personal preferences would play important role here. Once a firm has a solid knowledge base and expertise with certain MCUs; the efficiency offered by this overrules many other considerations. Many people call this as a “Tribal Knowledge” which is like common practice followed by a firm (or an individual) for many days or years.

During design time the inertia behind using known MCUs first makes the choice very simple; and if the time & budget permits one can explore additional options for incorporating in design. And to cope up with any such complexities, we usually have MCUs and parameters pre-assessed, pre-qualified and categorized in advance. This is more like preparation before cooking – better and smarter the preparation, faster will be the cooking. With this pre-selected pool of MCUs, our choice of a MCU for any given application is much simpler and faster.