# How to choose an ARM Cortex M3 microcontroller?

Based on my rough requirements of being in the 36 to 72 MHz range, having 16kb+ SRAM, 128kb+ flash, being programmable in C, I have decided that for my application I want to use an ARM Cortex M3 MCU.

The question is, what criteria do people use to pick which M3 version to use? There are many possible vendors such as TI, ST, NXP, Freescale, etc, etc.

A main differentiator from my standpoint would be ease of programming. Ideally I test it out on a breakout/development board, followed by implementation in my own PCB.

-
This is a useful question, anyone, please don't close it as primarily opinion based. –  Dzarda Jun 23 at 14:07
Picking the chip vendor is only part of the problem. Have you thought about what development toolchain you're going to use? –  kkrambo Jun 23 at 14:18
I'd say that the importance of choosing the uC chip in a situation like this is severely overrated. All chips that fulfill the basic requirements will do. I you stick to C or C++ and don't need fancy peripherals you can even switch later on with little effort. I would base my choice on the amount of support you can get from the www, vendor, (user) groups, lists, fora etc. that you have easy access to. –  Wouter van Ooijen Jun 23 at 17:03
"There are a dozen makers of the same core. What sort of things do people look at to help them choose one?" seems like a fine question to me. –  Scott Seidman Jun 24 at 11:12
It the highest scoring question in the list of our 250 newest, with three favorite labels. With those stats, if this is OT, we might consider asking why. I think its pretty clear that the poster considers "ease of programming" to be ONE of the criteria that he is currently using, and he's asking for more. Of four answers, only one makes a clear recommendation for a controller, and the others all discuss what criteria they use to make a selection. I've made a small edit which should make the question more on-topic, but it seemed pretty clear to me before the edit. –  Scott Seidman Jun 24 at 13:52

I think @markt is certainly in the right place: Toolchain, peripherals, packages, devkits.

I'll add a few, and maybe take off a few. Toolchain is certainly important, but FREE may or may not be. Sometimes, working without real support can be more expensive than you think it is, and using a reasonable commercial package may well be worth it for a given situation. Sometimes, being able to pass a thorough license audit is important as well, and using a free tool with a restrictive license can bite you later.

A good CMSIS library to support the microcontroller is a must for me. CMSIS -- Cortex Microcontroller Software Interface Standard -- arm.com/products/processors/cortex-m/… -- is a hardware abstraction layer for Cortex-M series microcontrollers. In theory, if a library is CMSIS compliant, it's vendor-independent, and its easier to swap different families, and you don't have to relearn an environment from the ground up to be able to use the library. One of the attractive aspects of the ARM Cortex environment is the ability to change platforms without a whole bunch of sweat. If you pick a platform that doesn't buy into the CMSIS structure, you may not be able to move around as conveniently.

For me, cheap and convenient dev boards is a must, but this may or may not be as important as some other things (I think the STM32 series has amazing devboards). If the family has very convenient and cheap dev boards, then you're more likely to find help from a larger userbase if you need it. Also, these chips tend to be in SMT packages. When you inevitably blow up a chip, or a port on a chip, or a bit on a port on a chip, replacing the chip is a PITA involving SMD rework. If you can purchase two or three boards at $10-$15 each, and replace them as you bust them, you won't even THINK about doing that SMD rework!

Think "Extras". You may need something above and beyond what is considered a "peripheral". For example, maybe you have heavy bluetooth needs, and you might choose to go with Nordic Semiconductor for that kind of support. You might consider some other things, like how easy is bootloading, etc.

Think Documentation. I've been a bit less than impressed with how hard it can be to wade through some of the STM documentation.

-
+1 Totally agree. Last year I got started with ARM Cortex-M3/M4 using STM32. I had nearly completed an STM32F207 design when we made the switch to STM32F407 based on price/availability. It was a drop-in for hardware, and software changes were trivial. The documentation and complexity made it a bit painful to learn, but the design is solid and well worth the trouble. I use the GCC compiler (free) for writing test code and the code size limited free eval version of Keil for writing/testing sample drivers. Our programmer has a license for the full Keil compiler. Both seem solid. –  Tut Jun 23 at 18:19
Could you elaborate a little more on what CMSIS is exactly and what it is/does which allows you to move between CPUs more easily? As I understand it now it seems to be like a very low level firmware library which provides some form of hardware abstraction? –  NickHalden Jun 23 at 18:20
@NickHalden, "ARM" licenses the ARM core to chipmakers that package them and add peripherals. CMSIS -- Cortex Microcontroller Software Interface Standard -- arm.com/products/processors/cortex-m/… -- is a hardware abstraction layer for Cortex-M series microcontrollers. In theory, if a library is CMSIS compliant, it's vendor-independent, and its easier to swap different families, and you don't have to relearn an environment from the ground up to be able to use the library. –  Scott Seidman Jun 23 at 18:30
@YoungMoney Go for the cheapest that will give you at least twice the resources that you think you will need. –  markt Jun 24 at 0:10
Develop on big, just to keep things from getting stuck. Once you have a good grip on what resources you need, cut back. –  Scott Seidman Jun 24 at 1:32
2. Consider what packages you're able/willing to work with - if DIP is a must, rule out silicon vendors that don't offer DIP packages.
3. Look at what peripherals are on offer, and what you're likely to want/need.
4. Look for bang-for-buck - use one or more of the big electronics vendors websites to compare apples with apples.

Given your desire for dev boards, consider what's available there.

If you're coming over from another platform (PIC, Atmel, etc) accept that there will be a fair learning curve in many areas in the move to ARM, but it's well and truly worth it.

-
Yes - free toolchains are important for security of future / alternate computer / alternate engineer access to the toolchain more than for cost. For Cortex parts the toolchains are fairly universal, so it's more knowing you can program them with an easy-to-work-with SWD interface device that will be available or re-createable and can be driven from your present (and future) OS of choice. –  Chris Stratton Jul 16 at 15:48

If you don't have a strong preference (e.g. price, size, power, plus what others listed), then I would consider who supports you. If the manufacturer doesn't reply to your questions, that could be an issue. Or do they have a local distributor with a FAE (Field Applciation Engineer) you can ask? That's particularly important for small companies and hobbists.

Some parts may not be available in small quantities. For example, those that have DRAM in the same package are aimed at big buyers (> 10 k units).

-

Probably STM32L151VBT6 suits your requirement. Even we used it in our company it's having moderated cost and good in terms of the power consumption. also you will get most of the design resources on http://www.st.com.

Key Features of STM32L151VB MCU are :

Ultra-low-power platform 1.65 V to 3.6 V power supply

-40°C to 85°C/105°C temperature range

0.3 μA Standby mode (3 wakeup pins)

0.9 μA Standby mode + RTC

0.57 μA Stop mode (16 wakeup lines)

1.2 μA Stop mode + RTC

9 μA Low-power Run mode

214 μA/MHz Run mode

10 nA ultra-low I/O leakage

< 8 μs wakeup time

Core: ARM®Cortex™-M3 32-bit CPU

From 32 kHz up to 32 MHz max

33.3 DMIPS peak (Dhrystone 2.1)

Memory protection unit

Reset and supply management

Ultra-safe, low-power BOR (brownout reset) with 5 selectable thresholds

Ultra-low-power POR/PDR

Programmable voltage detector (PVD)

Clock sources

1 to 24 MHz crystal oscillator

32 kHz oscillator for RTC with calibration

High Speed Internal 16 MHz factory-trimmed RC (+/- 1%)

Internal Low Power 37 kHz RC

Internal multispeed low power 65 kHz to 4.2 MHz

PLL for CPU clock and USB (48 MHz)

USART supported

Development support

Serial wire debug supported

JTAG and trace supported

Up to 83 fast I/Os (73 I/Os 5V tolerant), all mappable on 16 external interrupt vectors

Memories:

Up to 128 KB Flash with ECC

Up to 16 KB RAM

Up to 4 KB of true EEPROM with ECC

80 Byte Backup Register

LCD Driver for up to 8x40 segments

Step-up converter on board

Rich analog peripherals (down to 1.8 V)

12-bit ADC 1 Msps up to 24 channels

12-bit DAC 2 channels with output buffers

2x Ultra-low-power-comparators(window mode and wake up capability)

DMA controller 7x channels

8x peripherals communication interface

1x USB 2.0 (internal 48 MHz PLL)

3x USART (ISO 7816, IrDA)

2x SPI 16 Mbits/s

2x I2C (SMBus/PMBus)

10x timers: 6x 16-bit with up to 4 IC/OC/PWM channels, 2x 16-bit basic timer, 2x watchdog timers (independent and window)

Up to 20 capacitive sensing channels supporting touchkey, linear and rotary touch sensors CRC calculation unit, 96-bit unique ID

-