MCU (also named as microcontroller or microcontroller unit) is a small computer (SoC) on a single integrated circuit containing a processor core, memory, and programmable input/output peripherals. Nowadays, the firmware that runs on a microcontroller has become more important than the physical electrical connections and pins. Failing to recognize firmware in the decision-making process can result in cost overruns, delayed product launches, or even the complete failure for a project.

Here are five criterions to examine in order to select the right microcontroller.

Criterion #1 – Hardware vs software costs

Manufacturing teams often focus heavily on BOM (Bill of Material) cost minimization. We’ve all heard about the penny squeezers who push on their vendors to save them $0.002 or that refuse to use a higher-quality capacitor with lower leakage because it costs $0.0001 more. Electrical engineers selecting a microcontroller will often be placed under the exact same pressures to use a $3.32 microcontroller instead of the $3.48 microcontroller that is better suited for the application from a software standpoint.

Selecting a smaller or less expensive microcontroller might save $70k during production, but at what cost to developing and maintaining the software that runs it? Selecting a cheaper microcontroller that doesn’t provide a wireless stack, file system, or some other complex system interaction could cost twice that much in software over the product's full lifespan. Teams need to look at the manufacturing costs as just a single data point in the total cost for the system, and balance all those costs. The microcontroller selection may be more expensive per piece in some cases yet still decrease the overall project costs.

Criterion #2 – Production driver availability

Development teams need to look at the software drivers available for their candidate microcontrollers very carefully. Over the years I have seen example code distributed and described by sales staff as production-intent, yet it looked like spaghetti code a middle-school student would crank out. Free examples and free software don’t mean that the software has any guarantee for quality or fitness for a specific purpose. On the flip side, I have seen sample code distributed that was beautiful, elegant, and production ready right from day one. Getting stuck with the former code though will result in more pain, costs, and schedule delays, so be diligent in reviewing the available code before making a decision. Remember, we are trying to select the best microcontroller and software for the product, not just the best microcontroller.

Criterion #3 – RTOS integration

A quick Google search will reveal that there are more than one hundred different real-time operating systems (RTOSes), a few dozen microcontroller vendors, and more than 62,000 different microcontrollers available to developers. Not every RTOS will support every microcontroller and vice-versa. Building or porting an RTOS probably isn’t something that a development team should be doing. The opportunities for errors, delivery slippage, and cost overruns are too great. Plus, as a society we already have more than 100 RTOSes and don’t need another one. Instead, start by identifying a few RTOSes that can be used to meet the software application needs. Then determine which microcontrollers are supported natively and with minimal effort by that RTOS.

Criterion #4 – Middleware integration

Development teams need to consider the entire software stack required to get a system up and running. This consideration includes the drivers and RTOS that we just mentioned as well as any middleware or third party application code that will be needed. Integrating software components that weren’t meant to work with each other can be messy, bug ridden, and take far more time to integrate than an optimistic engineer may think. Developers need to examine how closely the RTOS and drivers provided for the microcontroller can play with third party components. Rarely is there ever a perfect match but the closer a team can get to selecting a fully integrated solution, which many silicon vendors are starting to try to provide, the faster the software can be developed and save costs.

Criterion #5 – Tool-chain integration

Microcontroller tools have become more and more sophisticated with every passing year. Developers used to just get a driver and example code dump and then were forced to modify the code for their own application. In today’s development environment, though, drivers, RTOSes, middleware, and even application code are being packaged together in sophisticated toolchain management software that allows communization, customization, and even testing to be performed with ease. Selecting a microcontroller that supports integrated firmware with a tool in this manner can save costs throughout the development cycle. This support allows a developer to focus on the application rather than just attempting to get software components to work with each other. Make sure that you examine the toolchain and its capabilities along with the other criterion.

Conclusion

Selecting a microcontroller simply from an electrical engineering standpoint doesn’t work anymore. Embedded systems complexity is no longer in the hardware anymore; it's in the software. Successful development teams will be looking for microcontrollers based on the tools and software quality that is provided. The product development goal is to get a product to market, not spend months or years developing code from scratch or integrating unrelated components endlessly. So the next time you need to select a microcontroller, start with the software and work your way back to the hardware. You’ll find the overall development experience will be much easier and the costs and schedules easier to control.