# Advantages of 32-bit 48-96 Mhz microprocessors (such as in Arduino Due)

It seems Arduino Due ( 32-bit, 84 Mhz, ARM-Cortex-M3-based SAM3X8E ) was released today.

In addition, clearly there is a myriad of processors in this category ( 32-bit / 48-96 Mhz / ARM ) as well as corresponding prototyping boards:

• NXP LPC1768 / mBed
• STM32 / Discovery
• PIC32 / ChipKit
• PIC32 / Parallax Propeller
• etc.

I am trying to understand the appeal of these "in-between" microprocessors, which to me appear to lie in between the low-end AVR/MSP430/etc. (pros: inexpensive, low-power, small-footprint) and the high-end ARM7/etc (pro: capable of far greater instructions per second).

In what situations or ways are 32-bit / 48-96 Mhz / ARM-based microprocessors a suitable choice? More specifically, I am wondering in what applications or in which parameters they would make for a superior choice during design, over both the low-end 8-bit microcontrollers or the the very high-end ARM7 processors.

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

• Well- first thing on my mind you can process live video streams - where the Arduino could not handle that. It also allows advanced encryptions algorithms or hashing (faster and easier than in Arduino) I am surprised the Arduino came out with a 32bit platform but it just shows you - Some people just want to do more than control a relay. It is a great day for Arduino! – Piotr Kula Oct 24 '12 at 14:16
• You won't be doing more than trivial live video processing on <100 MHz processor, unless you do it in an attached special function core. And especially not in the fairly limited on-board ram on these devices. A more realistic point is that the cost of these chips just isn't substantially higher than that of 8 bit parts; it may actual be lower than an ATMEGA with comparable flash & ram. – Chris Stratton Oct 24 '12 at 14:24
• As far as I know, Parallax Propeller is a custom chip with no relation to PIC32. Any sources for connection? – AndrejaKo Jul 4 '13 at 16:16

This is one of those subjects that can become highly debated. There are so many different points of view, and different things are important to different people. I will try to give a comprehensive answer, but understand that there will always be someone who disagrees. Just understand that those who disagree with me are wrong. (Just Kidding.)

Quick Summary:

This answer is going to be a long one, so let me summarize this up front. For the vast majority of people the latest crop of ARM Cortex-M0/M3/M4 chips offers the best solution, the best features for the cost. This is even true when comparing these 32-bit MCUs to their 8 and 16 bit ancestors like the PIC and MSP430s. M0's can be bought for less than US$1/each and M4's for less than US$2/each so except for the very price sensitive applications the ARM solutions are very nice. M0's are very low power and should be good enough for most people. For those who are very power sensitive the MSP430s might still be a better choice, but the M0s are worth considering for even these applications.

If you are interested in a more in-depth analysis then read on, otherwise you can stop reading now.

I will now look at each area and compare the different MCU's:

Speed of Execution

Of course the 32-bit MCUs are going to be faster. They tend to have a faster clock speed, but also do more work for each of those clocks. MCUs like the ARM Cortex-M4 include DSP processing instructions, and can even have floating point support in hardware. 8 and 16 bit CPU's can operate on 32-bit numbers, but it is not efficient in doing that. Doing so will quickly consume CPU registers, CPU clock cycles, and flash memory for program storage.

Ease of Development

In my opinion, this is the most valuable reason for using modern 32-bit MCUs-- but also the most under-appreciated. Let me first compare this to the 8-bit PICs. This is the worst case comparison, but also the best to illustrate my points.

The smaller PICs basically require that the programming be done in assembly language. True, there are C compilers available for even the 8-bit PICs but those compilers are either free or good. You cannot get a compiler that is both good and free. The free version of the compiler is crippled in that its optimization is not as good as the "Pro" version. The Pro version is approximately US$1,000 and only supports one family of PIC chips (8, 16, or 32 bit chips). If you want to use more than one family then you have to buy another copy for another US$1,000. The "Standard" version of the compiler does a medium level of optimization and costs about US$500 for each chip family. The 8-bit PICs are slow by modern standards and require good optimization. You can either fork over the money for a good compiler or you can write in assembly language-- I prefer assembly in this case. By comparison, there are many good C compilers for ARM MCU's that are free. When there are limitations, those limits are usually on the maximum size of Flash Memory that is supported. On the Freescale Codewarrior tools this limit is 128Kbytes. This is plenty for most people on this forum. The advantage of using a C compiler is that you don't have to bother (as much) with the low-level details of the CPU's memory map. Paging on the PIC is particularly painful and is best avoided if at all possible. Another advantage is that you don't have to bother with the mess of handing 16 and 32 bit numbers on an 8-bit MCU (or 32 bit numbers on a 16-bit MCU). While it is not super difficult to do this in assembly language, it is a pain in the rear and is error prone. There are other non-ARM C compilers that work well. The MSP430 compiler seems to do a reasonable job. The Cypress PSoC tools (especially PSoC1) are buggy. Flat Memory Model A MCU that has paged RAM/registers/Flash is just stupid. Yes, I am talking about the 8-bit PICs. Dumb, dumb, dumb. That turned me off of the PICs so much that I haven't even bothered to look at their newer stuff. (Disclaimer: this means that the new PICs might be improved and I just don't know it.) With an 8-bit MCU it is difficult (but not impossible) to access data structures larger than 256 bytes. With a 16-bit MCU that gets increased to 64 kbytes or kwords. With 32-bit MCUs that goes up to 4 gigabytes. A good C compiler can hide a lot of this from the programmer (a.k.a. You), but even then it does effect program size and execution speed. There are many MCU applications that this will not be a problem for, but of course there are many others that will have problems with this. It is mostly an issue of how much data you need (arrays and structures) in RAM or Flash. Of course, as CPU speed increases so does the odds of using larger data structures! Package Size Some of the small PICs and other 8-bit MCUs are available in really small packages. 6 and 8 pins! Currently the smallest ARM Cortex-M0 that I know of is in a QFN-28. While a QFN-28 is plenty small enough for most, it isn't small enough for all. Cost The cheapest PIC is about one third the price of the cheapest ARM Cortex-M0. But that is really US$0.32 vs. US\$0.85. Yes, that price difference matters to some. But I posit that most people on this web site don't care about that small of a cost difference.

Likewise, when comparing more capable MCUs with the ARM Cortex-M0/M3/M4 usually the ARM Cortex comes out "roughly even" or on top. When factoring in the other things (ease of development, compiler costs, etc. then the ARMs are very attractive.

Second Summary

I guess the real question is: Why would you NOT use an ARM Cortex-M0/M3/M4? When absolute cost is super important. When super low power consumption is critical. When the smallest package size is required. When speed is not important. But for the vast majority of applications none of these applies and the ARM is currently the best solution.

Given the low cost, unless there is a good reason to not use an ARM Cortex, then it makes sense to use one. It will allow faster and easier development time with less headaches and larger design margins than most other MCUs.

There are other non-ARM Cortex 32-bit MCUs available, but I do not see any advantage to them either. There are many advantages to going with a standard CPU architecture, including better development tools, and faster innovation of the technology.

Of course, things can and do change. What I say is valid today, but might not be valid in a year or even a month from now. Do your own homework.

• To access any memory location with the ARM, one must first load a register with an address that's within 4K of it; many I/O devices are allocated more than 4K of address space, even though many only use a few discrete addresses. By contrast, the 18Fxx PICs can directly operate on most I/O locations with a single instruction, independent of the state of banking. The means by which most of the RAM is banked is rather annoying, but for certain types of bit-banging (the purpose for which the PIC architecture was designed in the 1970's) the PIC architecture works very well. – supercat Oct 24 '12 at 18:17
• BTW, I find it curious that while a popular 8-bit microprocessor from the 1970's could efficiently process arbitrarily-aligned 256-byte data structures, and a popular 16-bit processor could work well with 65,536-byte data structures that were aligned on 16-byte boundaries or arbitrarily-aligned data structures almost that big, newer 8-bit and 16-bit processors make it hard to write efficient code that straddles page/bank boundaries. – supercat Oct 24 '12 at 18:28
• @supercat The 4K address range for a "LDR/SRT Immediate Offset" instruction is true, but often not a problem. I disagree with the rest of your comment. Looking at the Freescale M4 docs, each peripheral does not take up more than 4K of address range so a single "base address pointer" is sufficient for accessing all the registers in that peripheral. There is also 32 general purpose registers, any of which can be used as a base address pointer-- so accessing multiple peripherals quickly in the same section of code is relatively painless. – user3624 Oct 24 '12 at 18:57
• @supercat Your second point touches on the whole RISC vs. CISC debate. ARM is a RISC CPU, which means that it is optimized to do the most frequent tasks. Tasks which are not frequent, like unaligned accesses, require either more work or take more time (depending on the CPU Arch). I view this as being a positive thing, not a negative thing. That is why we get fast 32-bit MCUs for the price of an older 8-bit. Even with these quirks, I'd take one of these CPU's over a PIC any day. – user3624 Oct 24 '12 at 19:04
• I misspoke; I didn't mean to imply that one base register couldn't handle an entire peripheral, but rather that a register would often have to be loaded for each peripheral (so one couldn't simply e.g. leave a register sitting with IO_BASE_ADDR all the time). For some types of code, being able to set an I/O bit in a single cycle with an instruction like "bsf LATA,4", without having to pre-load any registers first, can be very handy. I like the ARM, but the direct I/O mapping on the PIC can be quite nice (too bad other memory access isn't so nice). – supercat Oct 24 '12 at 19:10

David Kessner is correct. I would like to add the following.

1. 8-bit MCUs are the only MCUs that are readily available in PDIP packages which are easy to handle and easy to stick in a prototyping breadboard.
2. 32-bit MCUs can actually use less power than 8-bit MCUs. It is not necessarily true that the < 20 MHZ 8-bit MCU will use less power than a Cortex M4.
3. 8-bit MCUs are often used by hobbyists who usually don't require a lot from the MCU. Maybe a few hundred lines of simple C code.

I agree that these days there is little reason not to use 32-bit MCUs. I would only use them [8-bit MCUs] for 2 reasons: I like the ease of the PDIP package (no soldering required); I often don't need more power/complexity than what an 8-bit MCU can offer.

The deal breaker is really the tools available.

• For prototyping, there are sockets for LQFP, which work fairly well. And of course you can solder LQFP by hand, just takes a bit of practice. QFN, DFN and BGA I wouldn't solder by hand, but then every single low-end 32 bit MCU on the market come with LQFP. – Lundin Jul 4 '13 at 14:18

We use a relatively unfashionable Freescale MCF52259, a 32-bit ~80Mhz capable MCU.

Reasons / thought process for the choice were:

• It was replacing a 32-bit M.Core device, so porting was relatively simple
• It also meant we could stick with the existing IDE (CodeWarrior)
• We needed plenty of IO: Control for step/direction on 3 stepper motors, 4 channels of PWM, 3 UARTs, and I2C and SPI.
• There was a lot going on (see last point) and some of it needed to happen in a timely manner, so we needed to be sure there were enough CPU cycles to get everything done.
• The legacy code was bumping against the 256k flash size and 32k RAM of the M.Core, so doubling the flash & the RAM made life easy to get up & running quickly.

These days it is more cost-effective (and expedient) to over-spec / expand the hardware's capabilities (storage, speed, IO, etc.) than spend valuable development time optimising code to squeeze into a marginally cheaper/smaller MCU unless space or power are big issues.

In our case, the device was twice the spec of the M.Core for half the price, going to a cheaper MCU would only save pennies per board but cost a lot of development time and limit the potential for future development without changing MCU's again.

If we were building a million boards it would be worth doing the cost-engineering exercise to paring things down, but as it stands it's not worth the development time.