Let's see the direction this thread will take organically, but in general, I would love to read your insights about how one should go when selecting the right microcontroller for an application.  It doesn't have to be a long post (although it can be).  Anything that you believe could add to the discussion and possibly be useful to someone going through the process is more than welcome.

Or if you feel like it, I think there would be lots of value for many in the Embedded Systems community in reading the story of how you went about selecting the right microcontroller for your own application.  It would be great to learn about the application itself, the candidates (#microcontrollers), the winner and why.  The more details you can add the better I suppose.  But I know your time is precious and counted so whatever you can contribute is great.

Thanks in advance for your inputs and let's see where this leads!

#FAQ

Tough subject!

I would say the recipe for selecting a microcontroller involves mixing:

• one part: business
• one part: art
• one part: resources on hand
• two parts: engineering

One Part - Business:

Clearly the business team must weigh in on the matter of costs. What is the target BOM cost for the product being created? How sensitive is the product to cost fluctuations? What is the expected life of the product? Is the product a one time sale, where every penny of margin is required, or does the product enable ongoing business income? How critical is initial time to market versus ongoing BOM costs?  

Ideally the business team is able to provide clear cost goals to engineering.

One Part - Art:

There is an 'art' to topics like selecting a microcontroller. I don't know how to fully explain it. What does your "gut" say about the microcontroller in question? Do you believe the company creating the microcontroller when they say it is ready for prime time? Do you believe their end-of-life guarantees? Do you believe they will support the microcontroller during and after the design of the target product? 

This is clearly a subjective area, honed through a life-time of hard knocks and experience.

One Part - Resources on hand

What microcontroller does the team already have experience with? What microcontroller would the engineering team want to work with? Which members of the team are available for the project on hand? What will you do if the only available engineer is deeply in love with the MSP430, but the preferred microcontroller happens to be an ST-ARM based microcontroller instead?

Another subjective area. But sometimes the politics of an engineering team should overrule the ideal selection.

Two Parts - Engineering

Clearly engineering must drive and select the microcontroller. I list engineering last because the other ingredients listed above should be known and available for the final decision making process. So, what priorities and questions should engineering be asking?

• What are the device power requirements? How will the microcontroller impact or manage the power requirements?
• What the the product security requirements? How will the microcontroller impact or improve the security of the product?
• What software algorithms will be executed by the microcontroller? Can these be characterized in advance to help determine microcontroller CPU requirements?
• What compiler or toolchain is available for the microcontroller? Is this toolchain readily available and common, or is it proprietary and expensive?
• What debugging or inspection tools support the microcontroller? Are they world-class tools that will help our engineering team iterate quickly during software development?
• What internal interfaces are required by the product? For example, will an external accelerometer require an I2C or a SPI interface?
• What external interfaces are required by the product? For example, will the product enable an Ethernet port, and if so, is the microcontroller expected to interface directly with ethernet?
• What are the safety concerns of the product? How will the microcontroller enhance the product safety?
• How will the microcontroller impact the overall BOM? Does this microcontroller require extensive glue logic or other external costs, such as RAM, Flash, etc. How do these external requirements impact the BOM?
• Did the sales rep take me out to dinner? Did they buy me a beer?!?   :-)

I'll leave it to reader to decide which of the above are the most important to their project. I know which is the most important to me!  :-)

Best regards,

Matthew

https://covemountainsoftware.com/consulting/

has written a definative answer.  I will only add that resources might include tools as well as personnel.  If you have invested in an ICE for a particular processor, that is likely to steer the choice in that direction if that processor is up to the new task...thats a real example from a previous job.  I recall that we even once chose to use an outboard 2nd UART rather than a uC variant with two internal uarts because we couldn't get a bondout 2 UART processor for the ICE.

Proper documentation for the part is very important.  We use the NXP LPC1788 which is a great processor with lots of functionality, but the user manual for the part is woefully lacking in the proper documentation for some parts of the processor.  

As an example, the I2C section is so good, I used it to write an I2C driver from scratch and it worked the first time without any debugging.  The documentation is clearly written with full details for interrupt flags, states, etc.  

On the other hand, the SD card documentation is so inadequate, we couldn't create a driver that worked but had to opt for the slower SSP driver.  Interrupt flags aren't properly documented and there's no info stating when a particular flag will assert.  Some flags, such as the ROD flag, have absolutely no documentation and it's not known what they are.  Online resources are lacking as well since all of the posted implementations don't work.  (It's possible that when NXP fixed the UART problem, they hosed the SD part.) 

So, when choosing a processor, read all sections that you will be using and ensure that you completely understand what the hardware does and how to implement it.  Otherwise you'll be setting yourself up for so much pain that even Dante would cringe.

@Matthew Eshleman hit most of the important points.

I'd add that previous familiarity with the microcontroller and its toolchain means that often the microcontroller is already selected for you--it's the one you used last time. Every microcontroller has quirks, errata, or corner cases that don't reveal themselves until deep into development. The same is true for the development systems. Familiarity with the microprocessor, the tools, and knowing where the dragons are will decrease time-to-market on subsequent projects using the same microcontroller.

If you/your team are forced to move to a new microcontroller platform for whatever reason, the odds are it is because you have some particular need a previous microcontroller doesn't address. More GPIO ports, faster processing, greater connectivity, whatever. That need will determine what microcontrollers will 'make the cut'. When I evaluate a microcontroller in those situations, to Matthew's excellent list I would add:

• Is the microcontroller a one-off, or is it part of a family of microcontrollers that can be used in subsequent developments (gaining all those benefits of familiarity)?
• Is there an active and open community around the part and/or family? Some companies encourage and support hackers, 'makers', open source, and online communities with plenty of documentation, downloadable datasheets, forums, etc. Others prefer to support only commercial toolsets, require NDAs for datasheets, and won't talk to you until you have given them budgetary estimates of annual quantity. I have found that part longevity and support are typically better when a company takes the former approach than the latter.

I totally agree with Matthew that there is a lot of 'art' to making the choice. It's hard to quantify, but some microcontrollers just 'feel' like a better fit for a particular project. They hit that sweet spot of cost, complexity, and capability that makes the project enjoyable and smooth, instead of a last-minute fight to find 100 more bytes or bit-banging another I2C port out of a few spare GPIO pins.

Anyone that is looking for a new microcontroller shouldn't start with the hardware but instead, they should start by examining their software requirements. Microcontrollers today have become a commodity with vendors providing very similar offerings and competing mostly in price. The real differentiator is the software ecosystem that surrounds the microcontroller and whether a developer can use a single supplier with fully integrated and tested software stacks or whether they will need to source multiple suppliers and integrate the software themselves. 

I recently posted a personal blog (https://www.beningo.com/10-steps-for-selecting-a-m...) that describes the 10 steps that I see in selecting a microcontroller. They include:

Step #1 - Create a software component list

Step #2 - Identify matching embedded software platforms

Step #3 - Examine the ecosystems

Step #4 - Select the software platform

Step #5 - Make a list of required hardware interfaces

Step #6 - Estimate the flash and RAM requirements

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

Step #8 - Check and verify part availability

Step #9 - Order a development kit and download all the necessary software

Step #10 - Evaluate software, hardware and make a go/no-go decision

Now these steps are completely engineering focused and don't take into account some of the business or other aspects that should be taken into account, but they demonstrate the change to software centric microcontroller selection.

Being late to the party, I only have a few points that I feel have not been completely covered.

The first thing that strikes me from the comments is that no one has mentioned customer support. Only Bob11 speaks about an "open community". It's almost as if no one expects manufacturers to provide technical support for their products. I think it is an important consideration-(let me plug my own blog on the subject "Comparative technical support with tortuous tricky technical problems" (https://www.embedded.com/electronics-blogs/without...))

Sometimes you know a project requires a micro outside of your experience. Even if you manage to narrow down a manufacturer or better yet, a family, how do you know which processor will meet you needs. I actually came up with an Excel worksheet to approach this. It was published as a design idea "Program “excelerates” microcomputer-I/O allocation" (http://www.edn.com/design/other/4313287/Program-ex... ). The problem with this is that manufacturers don't provide this information for their product and you almost have to know the micro before you can create the worksheet and that takes time especially if you have to compare several of them.

How well will the micro adapt to errors you make, (pinouts for example) resource restriction (I/O modules sharing pins for example)  unforeseen requirements (like BIST), change in requirements and feature creep. Some micros have the ability to route almost any internal I/O point to any pin. Modules can be reconfigured, functions can be customised with truth tables and other internal modules. Microchip has some of this as do others, but the ultimate in reconfigurability is the Cypress PSoC. This allows more flexibility with the PCB layout and if someone makes a mistake, no hardware change is needed. In addition these features can lead to a significant reduction in the external devices that you may need.  Allow me to elucidate- I managed to create a hardware true RMS detector internal to a PSoC. (It is described as a 3 part blog https://www.planetanalog.com/author.asp?section_id... (this is part 3, it points contains the pointers to part 1 and 2)). Earlier designs that I have worked on either needed intensive software to square/ divides and take the square root, or required expensive external chips.

Do you need that kind of versatility?

Of course there are many factors, but for myself, I like to choose a powerful, small form factor microcontroller board for most of my applications and usually I like a board that is Arduino compatiable since there are so many useful shields available.  I also like to develop the software in Ada so I usually choose one of ST's STM32F4 or F7 boards like their Nucleo boards.  AdaCore has great ARM support for these and I have implemented a lot of drivers in Ada to support dozens of the ST boards and a lot of common peripherals.

I find I can get something going quite fast with this environment.  The processing power and on-chip peripherals are amazing with these ARM chips!

For my last couple projects it was quite easy to select one- here is why:

my target 'products' are single or very low quantity systems and most of the projects have no time to market/customer ;-) -

so for me the main point is that i already know the system/tools/chips as much as possible. 

#1 'simple' logic and peripherals:

for me this is the Arduino environment with the atmel ATmega- processors and an external good text-editor ;-). If the processing power was not enough or complex logic and Network-Interface was required i switched to #2

as second point i checked if one of the shelf available boards fits with the needed peripherals and form-factor requirements. -> buying is easier than producing minimal quantities yourself - so i only have a 'baseboard' where the module can plug in. -> fewer parts to stock/mount (assembly mostly done by hand)

#2 'complex' logic and peripherals:

for this i used a embedded linux SOM (ACME Arietta / Aria ARM9@400Mhz) that had a really good documentation and tutorials. With this i could use ready available high-level libraries and frameworks to get going fast again.. (took me about 1year from minimal/no embedded linux knowledge to a working product with 40 pieces manufactured successfully - and it was about the same price point as with an microcontroller+ethernet solution)

This approach worked well for me :-) (with my surrounding conditions)
so hopefully some of you find this also useful to read ;-)

sunny greetings stefan

Cost per ECU (including all development/design costs like man days, toolchain, BOM, etc).