# How to choose a MCU platform? [closed]

There are numerous MCU platforms and once somebody has gotten used to one, they are generally reluctant to switch to another platform.

My question is: If one started using a MCU for general purpose tasks today, how would one go about choosing one? What are the unique selling points of the different platforms?

• Let us know the kinds of projects and volumes you have in mind, and it will help us answer the question. – Rocketmagnet Aug 9 '12 at 9:10
• General-purpose is much too wide. It makes little sense to use the same uC for flashing a bike LED and for an RTOS with a hi-res touch color LCD. – Wouter van Ooijen Aug 9 '12 at 18:31
• Yes, you would ideally have several chips you are familiar with for different size problems - and be ready to pick up a new one if it is uniquely suited for a task. – Chris Stratton Aug 11 '12 at 21:56
• @WoutervanOoijen The idea with this question was as follows: there are many tasks that any of the platforms can handle easily (i.e. general purpose tasks). One is then completely free to choose between platforms. In this case, the "soft factors", e.g. ease of use, external component count, etc. become dominant. - I wanted to find out what different platforms do well/poorly compared to others. – ARF Aug 11 '12 at 22:29
• R E L I G I O N – vicatcu Aug 21 '12 at 17:19

A year go, I gave a talk on the subject of picking microcontrollers (it took about 1.5 hours). The audience were high-level software programmers and makers. Majority of the audience didn't have prior μC experience, the remainder has played with Arduino only. The head count in the audience was about 30. So, this was a multicast, as opposed to a one-on-one clinic.

# Dimensions

for comparing microcontrollers. The list is in descending order.

• Development environment (tool chain)
• Development environment
• Did I mention development environment?
• Support
• Application notes
• Peer support: tribal knowledge, friends, forums, teh codes [sic]
• Features
• Memory
• Peripherals
• Computation prowess
• Power consumption
• Cost

p.s.

I should define the scope which this answer of mine is limited to. I see this platform selection question through two kinds of lens. The first one is a prototyper. The second one is a developer of professional equipment with street prices on the order of $3k and quantities in hundreds a year. The hobbyist lens is not far off too. In these cases, the incremental cost of the microcontroller is small, compare to the cost of development, or to the cost of the professional equipment into which the microcontroller goes. There is, of course, a very different perspective of mass production. When somebody chooses a microcontroller for a cheap device which will be produced in large quantities (mainstream toys are a good example), they will be driven by the cost of hardware. A modest saving in the hardware cost multiplied by a large production volume (in hundreds of thousands or more) may justify the pain of using an unwieldy development environment and a bargain priced microcontroller with a mediochre support. • You focus on the development environment. Makes sense to me. What were your conclusions? – ARF Aug 9 '12 at 2:21 • @ArikRaffaelFunke Well, those bullets in my post above are the conclusions. Not conclusive enough? My objective for the talk was to: (1) Provide a minimum list the questions, which need to be asked during the selection process. (2) Show where and how to look for answers. I have specifically avoided making hard conclusions along the lines: family X is good if..., family Y is good if... – Nick Alexeev Aug 9 '12 at 2:24 • For small volumes and typical requirements, yes. But sometimes you have to pick the best technology. Or if volume is huge, fairly substantial headache in development can be justified if it saves a few cents per widget - including having solutions based on competing parts tested and ready to jump to. – Chris Stratton Aug 11 '12 at 21:57 • @ChrisStratton Power consumption is another thing [in addition to high production volume effects], which can justify some headache sometimes. Little one can do, if he wants very low power operation, and the uC (which he chose) can't support it. – Nick Alexeev Aug 13 '12 at 4:22 • The focus on dev environment is absolutely right. You could have the best chip in the world but if you can't program & debug the damn thing it may as well be a brick. I've heard good things about NXP, but no direct experience. I thought Freescale were poor, but then I tried TI (MSP and then DM36x) and now Freescale are a shining beacon of brilliance in my eyes. Best advice with ANY dev environment: Build/install it in a virtual machine and keep a backup of it in fully-working state so it won't break when moving computers / upgrading OS etc... – John U Jan 10 '13 at 9:16 Since this question has not quite produced the platform comparison I was hoping for, I have attempted to create one myself by studying the literature as well as the other answers. Maybe this can help somebody else in future. Please let me know if there are any mistakes or if there is information I can add. ## Platform Comparison Notes regarding the comparison: • IDE: comments relate to the free version PIC: • by far the cheapest entry-level chips • many have internal voltage regulators • at given price, typically have more and better peripherals • quasi industry standard: very good libraries and developer support • IDE: NetBeans-based, outstanding, inkluding full offline simulation and debugging • third-party debuggers: about$25
• very wide range of packages
• unique selling points: 1. XLP = extra low power devices available; 2. many modern chips have the Capacitive Sensing Module for touch buttons, etc.

AVR:

• AVR generally lags behind regading peripherals and is slightly more expensive. On the whole, however, AVR is very similar to PICs in functionality and price.
• 8bit AVR chips are faster than 8bit PIC chips
• third-party emulators: about $20 • very wide range of packages Arm Cortex-M: • modern processor architecture: no memory banking, good multi-tasking • by far the cheapest 32 bit devices • fairly easy to move between different chips and different manufacturers • devices generally require more external components than PICs • very cheap USB devices with ROM bootloader: NXP LPC1342/LPC1343 • reasonable library support • IDE: reasonable, no offline simulation • SWD interface allows in-system programming, debugging and tracing with easy-to-build hardware ( • inexpensive NXP chips only come in small-pitch or pin-less packages • selling points: 1. cheapest 32bit platform; 2. cheapest platform with USB ROM bootloader PSoc: (from Rocketmagnet's answer) • king when it comes to analogue peripherals: a given chip can be re-configured internally to provide different analogue and digital peripherals • significantly more expensive than PICs • IDE: excellent •$88 programmer (does it allow debugging?)
• only SMD packages

• multi-core MCU: different cores can work simulateously on different tasks
• eliminates/reduces(?) need for traditional interrupts
• few hardware peripherals, must be explicitly coded to run on one of the cores, provides incredible flexibility
• weak when it comes to analogue peripherals
• IDE: excellent
• DIP package available

## Comparison by Application

USB:

"Legend" for the list below:

• voltage regulator = can be powered from bus without external regulator
• pullups = no need for external pullup
• impedance matching = no need for external matching resistors
• precision oscillator = no need for external crystal

Properties of least expensive device: (in approx. order of price)

• PIC: 8bit, low- and full-speed, voltage regulator, pullups, impedance matching, ESD protection
• NXP: 32bit, bootloader, full-speed only, ESD protection
• Freescale: 8bit, low-speed only, voltage regulator, impedance matching, ESD protection
• Atmel: 8bit, bootloader, full-speed only, voltage regulator, pullup, ESD protection
• STM: 32bit, bootloader, full-speed only, pullup, impedance matching, ESD protection
• Silicon Laboratories: 8bit, low- and full-speed, voltage regulator, pullups, impedance matching, precision oscillator
• TI: 32bit, bootloader, low- and full-speed, other properties unknown
• PSoc: configurable as module, other properties unkown
• Propeller: 32 bit, bitbanging only

Ethernet:

• PIC: cheapest device with integrated PHY
• Few notes here: Propeller doesn't have interrupts at all and there's no support for debugging in the official IDE. Instead, the preferred debug mechanism seems to be to connect the thing to a TV and use a provided library which displays variables on the screen. Also there's no code completion, no simulator, no integration with code management systems, unusual implementation of includes... Also there are no hardware peripherals except the two counters per core, as far as I know. – AndrejaKo Aug 11 '12 at 19:48
• Note about the propeller - It has NO interrupts. At all. If you need something that resembles a traditional interrupt, you spin up a additional CPU core, and have it spin-wait. – Connor Wolf Aug 12 '12 at 0:36
• Such a list is almost inevitably pointless and out of date. All the manufacturers are competing with each other all of the time and most try to offer something in each category - you do a survey when you have a need, pick a solution, and and if it works you run with it until you have a need for which there is a better solution. – Chris Stratton Aug 13 '12 at 4:38
• For what it's worth, you could include the MSP430 line here as well for its ultra-low-power-consumption – boardbite Aug 22 '12 at 1:37
• "Embedded Systems/Particular Microprocessors" has similar information on how to choose a processor, that similarly can be edited to (hopefully) keep it up-to-date and relatively neutral. – davidcary Jul 9 '13 at 17:23

Your choice of MCU depends a lot on the kind of projects you're going to be working on. Are you making high-volume, super-cheap and simple devices like flashing bike lights? Are you developing complex prototype robots which have to deal with numerous bizarre IO devices and sensors?

I mostly work on the latter. The main problem for me is trying to find microcontrollers which have the peripheral set I want. This is very difficult as our requirements don't seem to be mainstream. We want things like 5 PWM channels, 5 Quadrature decoders, 2 non-standard SPI ports and a UART with negated IO.

The only MCUs I have seen which can handle those kind of requirements with ease are the PSoC and the Propeller.

The Propeller is basically eight 32-bit MCUs in a single chip. If you want some type of peripheral, you simply program one of the MCUs to perform that job. So you can have whatever you want.

The PSoCs come on two flavours, 3 and 5. The 3 is an 8051 core, and the 5 is an ARM cortex M3. Also included on the chip are re-configurable digital and analogue blocks which can be made into a wide range of peripherals: ADCs, filters, op-amps, DACs, SPI, UART, quadrature decoder, CRC generator, etc.

The development environment is fantastic. You have the usual source code editing of a typical IDE, but you also have a schematic editor. You can literally wire up any digital circuit you like, connecting up the peripherals with gates, flipflops, etc. Need 5 PWMs? Easy, just put them into the schematic, wire them up, and away you go. You can even write your own peripherals in Verilog if you want something that's not provided. A great deal of your application can simply be implemented in this sort of hardware.

The real benefit is that you can stick with one chip, knowing that it can tackle a great many of the projects you'll want to do in the future. What I found annoying about PICs was constantly trawling through dozens of devices looking for the one which had the particular peripheral set I needed. Now I don't have that problem.

• The Propeller is a curious concept. I have to think a bit about that one. Regarding PSoC: I have considered those in the past due to the incredible flexibility but the need for a $250 programmer made it pretty much a non-starter for me. – ARF Aug 9 '12 at 2:20 • @ArikRaffaelFunke - The programmer is only$88, less than half the price of the ICD3. – Rocketmagnet Aug 9 '12 at 9:08
• @ArikRaffaelFunke -- another consideration is packaging. If you plan on building your own prototypes, then it is much easier to work with DIP packages. Most PICs and ATmel AVRs come in DIPs, as does the Propeller. The PSoC 3 and 5 do not. – tcrosley Aug 9 '12 at 22:59
• schmartboard has an easy to use smt to dip solution:youtube.com/watch?v=-32orELxkpE – hulkingtickets Aug 10 '12 at 14:13
• @quantum231: I considered it but: 1) FPGAs seemed to generally be larger and more expensive than microcontrollers (and robots are often desperately short on space). And 2) I don't have a lot of experience with FPGAs, and it's always a hassle to have to learn a completely different toolset and way of thinking just for some minor application. – Rocketmagnet Apr 23 '15 at 21:16

For me the most important requirement was if the device / the IDE is well supported on my non-Windows PC (Linux). Turned out that for me Atmel AVR's had better (open source) support than PIC.

Using more than one platform is okay. Selecting the best one for each job and also availability of code and examples related to the job.

Most of them have good development tools, arduino has visual studio, pic has a great tool and so do others. So, for me, it is how quickly and easily can I get the job done well, + how many open source people working on the same thing?

• But how does one find such information while not being mislead by marketing clutter. I mean, we have to find people that have used the hardware and the toolchain to get all that information. How do you find such communities in your job? Or is it that you rely on what the Applications Engineer tells you? – quantum231 Apr 26 '15 at 18:27
• You can ask questions on various forums such as this. Explain your application and ask for help – Visual Micro Apr 27 '15 at 19:26

Microcontrollers are a fast changing world, there are many advantages of learning on the current "in" chips and most popular IDE's most notable is getting help from the community. As a PIC person I would say the Aduino probably has the best IDE and development boards for newbies at the moment and you can add a lot to a basic aduino board without touching a soldering iron.

Anyone using an aduino for real life stuff may soon want to move on but by that time you will have learnt a lot of basic digital electronics and a good sub-set of C to easily use something more suitable.

As someone has mentioned you choose the chip for your project, I have seen a few projects using ARM chips as simple temperature sensors or AD converters, same way I have seen aduinos and PIC 16's pushed to their limit to generate a space invaders game, FPGA's are galso reat and its good to understand HDL if your seriously going into electronics design.. but unfortunately there are not many projects out there in the real world where you will need to use one most jobs are low volume, rapid design and price constrained and this is where the 8 bit uC reigns supreme

• I see, what are limitations of Arduino that a person would cause a person to move beyond them? Does ARM have more processing power than PIC and Arduino, does it have peripherals not present in PIC and Arduino, or is its toolchain superior to what exists for PIC and Arduino? Why so much noise about ARM based chips. I know they have very low power consumption but why else would ARM be chosen for "serious" projects? – quantum231 Apr 26 '15 at 18:30

Since many of the posted answers focus on hobbyist use, here comes various recommendations directed to professional developers only.

Bare minimum requirements
If the MCU doesn't fulfil all of these, it shouldn't be used.

• Been in production for at least 1 year.
• Silicon errata is available and has been revised at least once.
• Internal watchdog.
• Internal low-voltage/brownout detect.
• Flash memory on-chip.
• ESD protection.
• JTAG/SWD or some single-wire debugging interface.
• The core uses 8 bit bytes and 2's complement signedness.
• Samples and evaluation boards readily available.
• Has responsive technical support directly from the manufacturer.

Warning signs - MCU hardware
These are things you shouldn't waste time with in the year 2019.

• Obscure addressing modes that must be handled by the programmer. Including the use of obscure, non-standard keywords in order to access ROM data.
• Severe stack memory or stack depth limitations.
• 16 bit int, which in turn comes with all hidden dangers of C language integer promotions.
• Can't perform 16 or 32 bit arithmetic without starting to boil.
• Doesn't trap if you execute code in data sections.
• No instruction trace buffer.
• Comes with exotic hardware peripherals that you have no use for.

Warning signs - tool chain

• Relies on software simulators in PC or some manner of bootloader, instead of flashing the whole MCU and using on-chip execution/debugging.
• Doesn't come with pre-made drivers/examples/libraries written by professionals. Relies on devs re-inventing the wheel, or internet forums/open source.
• The CRT for the C compiler does not fulfil the requirements listed here.
• The C compiler comes with a long list of standard C features that are not supported.
• The C compiler still does not support C11 (regardless of if you intend to use it or not).
• The IDE spews multiple strange linker errors on you the first time you attempt a "hello world" program.
• Encountering many IDE or compiler bugs during the first weeks of use.
• This is overly dogmatic. You've completely omitted cost, packaging options, (open source != unprofessional), quality of peripherals, etc etc. I don't disagree in general with most of this, but things like "stack [...] limitations" just means you need to know the trade off that led to these limitations in the first place. – awjlogan Jan 11 '19 at 10:50
• @awjlogan Cost and packaging options are very project-specific, so it doesn't make sense to address here. I didn't say that open source is unprofessional, but a company who outsources their tool chain to open source and their support to sites like SO is not professional. Although open source projects with too few contributors are not professional either, as we can see with open source compiler ports to various exotic MCUs. There should not be any reasons to pick a MCU with limited stack in the year 2019. – Lundin Jan 11 '19 at 12:06
• Sure, they're project specific but you've increased your baseline cost straight away by specifying 16/32 bit only in your list (quick scan of Digikey) and I haven't seen a 6 pin M0 recently. If you don't need something (including time), don't spend the extra money on it, that's the decisions you should be making as a professional. But, yes, good tooling is so essential, couldn't agree more. – awjlogan Jan 11 '19 at 13:20
• @awjlogan LPC81X has been around for over 5 years. I just recently found out about Cypress PSoC4 which looks interesting. And so on. The number of pins is not often an argument, just package size and type. If you can tolerate QFN or BGA, you can get very small chips. – Lundin Jan 11 '19 at 13:37
• agreed on that, your choices narrow at small size (same for any architecture though). My overall point is that while all the things on your list are desirable, you should also be clued up enough to know when to break them. – awjlogan Jan 11 '19 at 13:42

If you are going for a general purpose tasks which can have analog and digital processing then I would have preferred PSoC for its IDE, Debugger and sheer number of things you can do with those.

I have used PSoC3 in college for my projects and it is quite simple to master. Only thing is if you need some performance chips, you'll still need to get them separately. It has good enough ports. So if you are looking some performance chips along with development kit, better go for separate components.

• It might be worth adding a bit more information on the PSoC to make this more useful, a couple of other answers already cover it. – PeterJ Jul 3 '14 at 4:04
• @PeterJ : I wanted to give this as a comment for Rocketmagnet's answer but I don't have any reputation to give a comment. – ganesh Jul 3 '14 at 4:10
• Is there a reason that you did not go for softcore based design like use Nios II on Altera FPGA or microblaze/picoblaze on a Xilinx FPGA? They can be used to get the same effect as the PSoC and I would argue are in many ways a superior choice. – quantum231 Apr 26 '15 at 18:32
• @quantum231 : I would accept that, but the main constraint for me at that time was the budget and this was available for free in our electronics department. – ganesh Apr 29 '15 at 0:51