28

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.

Scott Seidman
  • 29,274
  • 4
  • 44
  • 109
JDS
  • 1,156
  • 2
  • 18
  • 24
  • 11
    This is a useful question, anyone, please don't close it as _primarily opinion based_. – Dzarda Jun 23 '14 at 14:07
  • 2
    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 '14 at 14:18
  • 5
    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 '14 at 17:03
  • 2
    regardless of the value of this question (which I don't dispute in any way, since it *is* a very useful question), it is *still* a *primarily opinion based* question, since no hard reference can be given here, and we're basically asking people "what do you think?" - AFAIR, this kind of question is *not* proper for SE sites... also, currently all of the answers given **are** opinion-based. –  Jun 23 '14 at 22:20
  • NB, I'm not flagging it only because it *is* possible to answer this question in a non-POB way - but I highly doubt if that will ever occur. Anyway, this question has been "mentally flagged" by me. –  Jun 23 '14 at 22:27
  • 1
    Shouldn't this be off-topic since it is seeking recommendations for specific products? – tcrosley Jun 24 '14 at 08:12
  • In general, I think selecting components is a major part of being an EE. However, a underlying question about "ease of programming" makes this opinion based. – Rev Jun 24 '14 at 09:22
  • 5
    "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 '14 at 11:12
  • 5
    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 '14 at 13:52
  • Earlier in a different thread, I wrote [my list of selection criteria](http://electronics.stackexchange.com/a/37435/7036). It's as broad and agnostic as I could make it. – Nick Alexeev Jun 26 '14 at 17:14
  • Funny how these things kick in! I'm just this week finding out that it's troublesome getting a VID sublicense from STM for short production runs of USB devices. Never had that problem from Microchip. – Scott Seidman Jun 27 '14 at 20:42

4 Answers4

19

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.

Scott Seidman
  • 29,274
  • 4
  • 44
  • 109
  • +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 '14 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 '14 at 18:20
  • 1
    @NickHalden, "ARM" licenses the ARM core to chipmakers that package them and add peripherals. CMSIS -- Cortex Microcontroller Software Interface Standard -- http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php -- 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 '14 at 18:30
  • Thanks. We've actually looked at STM32 series quite a bit. Even within that - I can't decide between the F1-F4 series lol. Well I can sort of rule out the F4 just because it's relatively expensive. But say F1 vs. F3 - assuming both are capable enough, should I just opt for the cheaper one? – JDS Jun 23 '14 at 22:30
  • @ScottSeidman I say "free toolchain" because I think the price that e.g. Keil charge is comical. I have a Keil licence at work, and I'm using Coocox for home/study; Keil has a (mostly) nicer IDE, but Coocox is _free_ and has 95% of what Keil charge AU$11K for. Oh and I agree completely about the STM32's - great devices, great dev boards, annoying doco. – markt Jun 23 '14 at 23:59
  • 1
    @YoungMoney Go for the cheapest that will give you at least twice the resources that you think you will need. – markt Jun 24 '14 at 00:10
  • 1
    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 '14 at 01:32
  • @YoungMoney, the F4 is a Cortex M4, complete w/ some DSP affordances like a one-clock-cycle accumulate and add, a single precision floating point processor (for what that's worth), and some nifty addressing tools. Good stuff, but you do pay for it. – Scott Seidman Jun 24 '14 at 14:10
  • 1
    Free toolchains are important in a professional context, not because of cost, but because of **security of access** - go with a locked down toolchain, and your ability to maintain the project is imperiled by licenses that can expire or not be available for your travel laptop or co-worker, dongles that can get lost, license servers which can be unplugged after a few years, etc. Most embedded designs have lifetimes far beyond the desktop hardware and operating system versions used to develop them, and being able to resurrect the original tools in the future is important! – Chris Stratton Jul 16 '14 at 15:42
14
  1. Look for free toolchain, RTOS and low-cost JTAG/SWD support.
  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.

markt
  • 4,936
  • 2
  • 15
  • 13
  • 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 '14 at 15:48
5

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).

Brian Carlton
  • 13,252
  • 5
  • 43
  • 64
2

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)

Pre-programmed bootloader

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

Support contrast adjustment

Support blinking mode

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

Myanju
  • 213
  • 1
  • 3
  • 9