Recently I read a post by Steve Leibson that referred a very passionate on-going debate on the "ARM Based Group" on LinkedIn from a few industry veterans about the pros and cons of 8-bit versus 32-bit MCUs.
I did think about jumping in myself and adding to the debate but instead I thought I'd step back and try to clear the air about where my colleagues and I at ARM think the benefits of 32-bit lie for your average current 8-bit user.
First let's list out some of the main areas of debate in the discussion:
- 8-bit will always be lower power because they are simpler architectures with one-quarter the bus size
- Most applications can be handled by 8-bit MCUs and if efficiency is more important than performance then a 32-bit MCU offers no advantage over an 8-bit one
- 8-bit is far the best solution because the number of cycles to get to an interrupt is less
Here are my thoughts on each, for what they are worth, one at a time:
8-bit is always lower power. I struggle with this for lots of reasons. First the bus width doesn't tell you much about power, the amount of data/instructions I fetch from flash and RAM does. A few things that count in favour of ARM Cortex™-M processors here are our dense code (which means fewer expensive flash accesses when running your program) and our flexible support for bytes, half words and words. Flexible memory access means that the variables you read and write are always the size you need them to be; you aren't forced into all of your variables suddenly growing to 32-bits in size.
On top of that the simplicity position that some people take is very subjective. The ARM architecture is simple, in fact that is the point, no awkward banking of memory, registers, state, no fiddly hardware stacks and the like.
So to say that an 8-bit MCU will always be lower power just feels too simplistic to me and to be completely honest, is just not true.
Most applications can be handled by 8-bit MCUs. When I chat to software developers I start and end my story by talking about software productivity and reuse. It is often the case that the cost of the MCU is swamped by the cost of developing the firmware. This is why many of them love their Cortex-M processor-based MCUs, even for fairly simple applications. Trace, detailed profiling, very productive debuggers and great code reuse all count for a lot when you're part of a small team under a lot of pressure to get the firmware for your next product complete.
As an example, I had the pleasure of joining Freescale for their FTF event back in June and there I met one developer that was particularly excited about the prospect of no longer having to use any more PICs in his designs because he was tired of the unproductive and inefficient world that they were locked into.
8-bit is better at handling interrupts. This is another one that surprises me because no matter how I add things up, the time spent processing the interrupts dominates any calculations that I do. As a result the debate about five cycles here, ten there to get to the handler seems to disappear into nothing when the few hundred instructions to process the interrupt are so much more efficient on an ARM MCU.
Some conclusions. What interested me in the LinkedIn discussion was that there was a real mixture of the processor and the devices. This can make it really hard for a user to unpick and understand. This debate was particularly poor in this regard and I found myself struggling to keep up with the discussion. Let's try to separate out these things to give a more transparent debate about the pros and cons of the latest MCU technology; I believe end users will thank us for it.
Another topic that also seems to rarely come up and yet can make a big impact is code footprint and flash memory usage. I've lost count of the number of times I've had one of my silicon partners tell me that design wins have been won (and fortunately never lost!) based purely on the flash memory size for an OEM's codebase.
Closing remark. To those that think 8-bit is still the right choice for many embedded system developers, take a close look at Freescale Kinetis L, STMicroelectronics STM32 F0, NXP LCP11XX, Energy Micro's Zero Gecko and other ARM MCUs. I know what I'd rather be using, what about you?