The way developers select a microcontroller for their embedded systems is dramatically changing. Traditionally developers have focused on the hardware first and thought about the software second. Selecting a microcontroller in this manner, will result in failure today. There are several new steps that developers need to follow if they are going to be successful in selecting the right microcontroller for their application. These steps are quite different from the ones I wrote about at EDN.com in “10 Steps to Selecting a Microcontroller”. Let’s look at each step in detail.

Step #1 – Create a software component list

The first step any development team should take when starting to select a microcontroller is to create a software components list. Software is the major driving factor and differentiator in products today and that is where developers need to start. Examining the software components that are required can give a developer a feel for

• how much software is required
• how the software will interact
• what they need to look for microcontroller capability wise
• whether they can get away with a bare-metal solution or whether an RTOS is necessary
• software complexity
• where potential integration issues could arise

Since software is the major factor, we want to identify what we need software wise and then work out way towards determining the hardware that will support the software needs.

Step #2 – Identify matching embedded software platforms

With a software component list in place, a developer needs to start examining available software frameworks that are available on the market that meet the component list needs. For example, from the software list, a developer can determine whether they should be looking at a Linux based solution or whether they need to use an RTOS. Once this is determined, they can start examining the quickest path to success.

For developers who are using microcontrollers, the most obvious place to first look for software platforms is with the microcontroller vendors. For example a developer might look to the Renesas Synergy Platform, the ST Micro STM32CubeMx and HAL frameworks or whatever their preferred microcontroller vendor may be. I always recommend to my clients that they examine at least three different vendors and compare their software offerings. I even suggest that developers look beyond the silicon vendors and look at software component providers such SEGGER or HCC Embedded or even Electric Imp.

Software frameworks that are already integrated and work together out of the box can dramatically improve time to market and decrease the time developers spend debugging their systems. Long debugging sessions are guaranteed when developers try to either do it all on their own or try to integrate stacks from different sources that were never designed to work with each other in the first place.

Step #3 – Examine the ecosystems

Not every embedded software platform is created equal. Each platform has its strengths, weaknesses and a target market that is being served. At this stage it’s important to start looking at the ecosystem that surrounds the software and determine if it is:

• well supported
• has a vibrant community around it
• is supported by multiple toolchains
• contains analysis software such as static and dynamic analyzers
• is being improved
• has a proven track record
• meets budgetary and quality requirements

After examining these factors, developers will be able to determine which platform seems to best match their software needs.

Step #4 – Select the software platform

At some point, trade studies and comparisons need to end and a decision needs to be made. Once the evaluation stage is underway the decision can always be changed but we need to start somewhere. Select the software platform that seems to best meet the needs and then move on to the next step.

Step #5 – Make a list of required hardware interfaces

Create or use an existing hardware block diagram to define all the external interfaces that the microcontroller will need to support. There are two general types of interfaces that need to be listed. The first are communication interfaces. These are peripherals such as

• USB
• I2C
• SPI
• UART
• Modbus
• etc

Make a special note if the application requires USB or some form of Ethernet. These interfaces greatly affect how much program space the microcontroller will need to support.

The second type of interface is digital inputs and outputs, analog to digital inputs, PWM’s, etc. The combination of these two interface types will dictate the number of pins that will be required by the microcontroller. With these lists, it becomes trivial to search your favorite distributors website for microcontrollers that match these parameters that are supported by the software platform that has been selected.

Step #6 – Estimate the flash and RAM requirements

Flash and RAM are two very critical components of any microcontroller and will drastically be determined by the software list. Estimating code space and RAM requirements can be difficult but some vendors are starting to provide typical values in their software platform datasheets. For example, Renesas includes these numbers in the Synergy Platform Datasheet which can help guide a developer on what they should be looking for at a minimum.

Making sure that you don’t run out of program space or variable space is undoubtedly of highest priority. It is far easier to select a part with too much of these features than not enough. Getting to the end of a design and discovering that you need 110% or that features need to be cut just isn’t going to fly. After all, you can always start with more and then later move to a more constrained part within the same chip family for production. Don’t forget to leave room for feature creep and the next versions! It will save many headaches in the future.

Step #7 – Start searching for microcontrollers supported by the software platform

Now that there is a better idea of what the required features of the microcontroller will be the search can begin! One place that can be a good place to start is with a microcontroller supplier such as Arrow, Avnet, Future Electronics or similar. Talk with an FAE about your application and requirements and often times they can direct you to a new part that is cutting edge and meets the requirements. Just keep in mind that they might have pressure on them at that time to push a certain family of microcontrollers!

Step #8 – Check and verify part availability

With the list of potential parts in hand, now is a good time to start checking on how available the part is.  Some of the things to keep in mind are

• what the lead times for the part?
• Are they kept in stock at multiple distributors or is there 6 – 12 week lead time?
• What are your requirements for availability?

You don’t want to get stuck with a large order and have to wait three months to be able to fill it.  Then there is a question of how new the part is and whether it will be around for the duration of your product life cycle.  If your product will be around for 10 years then you need to find a part that the manufacturer guarantees will still be built in 10 years.

Step #9 – Order development kit and download all necessary software

One of the best parts of selecting a new microcontroller is finding a development kit to play with and learn the inner working of the controller.  Once an engineer has settled their heart on the part they want to use they should research what development kits are available.  If a development kit isn’t available then the selected part is most likely not a good choice and they should go back a few steps and find a better part.  Most development kits today cost under $100.  The only time they cost more is if they are integrating more costly features on-board such as LCD’s and expansion connectors.

Step #10 – Evaluate software, hardware and make a final decision

Even with the selection a software platform and a microcontroller, nothing is set in stone.  Usually the development kit arrives long before the first prototyped hardware.  Take advantage by building up test circuits and interfacing them to the microcontroller.  Choose high risk parts and get them working on the development kit.  It may be that you discover the part you thought would work great has some unforeseen issue that would force a different microcontroller to be selected.

As quickly as possible start integrating the pre-built software components and make sure that they live up to their reputation and datasheets. A developer should be able to determine within a few weeks if the software platform is too cumbersome and won’t meet their requirements. If this is the case, it may be time to try another platform and microcontroller on the list.

Conclusions

Selecting a microcontroller is no longer just about the hardware. The major contributing to the decision is software. With so many devices being connected to the internet or requiring short development cycles, developers need to focus on using software that is ready to work with each other right out of the box. The days of spending weeks or months integrating a new component in the system are gone. The teams that can successfully utilize existing software platforms will be successful while those stuck in the old days of hardware comes first will be left behind.