# What is the place of 8- and 16-bit microcontrollers? Why hasn't 32-bit taken over?

What is the real cutoff point in terms of the trade-off between cost and performance for selecting 32-bit microcontrollers?

In other words, with the rise and domination of ARM architectures, why are we still using 8-bit and 16-bit microcontrollers? Are they still much cheaper?

I understand that very low-end devices do not need the resources offered by bigger and more complex architectures. However, what is the real motivation to still use them if costs seem to be converging towards the same range?

• Power consumption? – Leon Heller Dec 4 '14 at 19:43
• The cheapest 32-bit µC on Digikey I see is about $0.64, the cheapest 8-bit is$0.35. If you're a big company that's going to build a million simple widgets, that's a very major difference. – Samuel Dec 4 '14 at 19:45
• @LeonHeller At a first sight I tend to agree but look at the point I made in the proposed answer's comments. – Bruno Morais Dec 4 '14 at 20:19
• Looking at even bulk pricing on DigiKey is not a brilliant guide, for properly tiny micros in small low-power embedded applications which are being mass produced, no-one is buying them from DigiKey and chances are they're buying dies to stick down not a chip package to solder onto a board. An 8-bit micro will always be smaller, simpler, hence cheaper and lower power than a 32-bit one of equivalent construction. Yes the margin is dropping to the point of insignificance for many people, but in mass volumes even 1/10th of a penny saved is worth it. – John U Dec 5 '14 at 10:07
• Here's a relevant article I came across on Electronic Design's website: 8 Bit or 32 Bit? Choosing Your Next Design’s MCU – Garth Wilson Dec 11 '14 at 21:13

Maybe a year ago, there was a significant difference between the low end 8-bitters and the cheapest 32-bit microcontrollers. Not the case any more.

Based on Digi-Key bulk pricing, you can get an 8-bit PIC10F200 for 35ȼ in 2500 quantities in a SOT-23-6 package. You get a 32-bit CY8C4013SXI-400 (ARM Cortex-M0) for 36ȼ in 2500 quantities in a SOIC-8 package. (Digi-Key bulk pricing is not realistic in terms of what manufacturers actually pay, which is probably much less, but I think it is a valid to use for a rough pricing comparison between different products for similar quantities.)

So the OP is right, they are converging.

So why aren't the 32-bit chips being used more? Well as I said in my first paragraph, this price point and size parity only happened in the last year or 18 months. And they've still got a long ways to go before there are enough chips to be competitive.

Of the 6875 ARM chips available from Digi-Key, there are only four in stock with quantity pricing under a dollar. Four. Meanwhile there are hundreds of 8-bit chips under a dollar for engineers to choose from.

But lets say there were a least a few dozen low-end 32-bit micros available. Would they automatically be picked over the 8-bit ones?

First of all you have to get engineers aware of them. There is always a lot of resistance to change. New things to learn -- from a hardware standpoint, learning how to incorporate the new chip into a circuit. There are new tools, like in-circuit programmers, new compilers, etc. For the firmware engineers, learning how to use a brand new set of peripherals and timers (mostly register layouts and bit meanings).

32-bits is nice and all that, but unless one needs to do a lot of heavy computation, what's the point? If you have only four GPIO pins, accessing them internally as a 32-bit register gives no advantage over using an 8-bit register.

I think power consumption is always going to be in favor of the 8-bit micros.

For example, the PIC10F200 draws 175 µA running at 4 MHz and 2v and 100 nA in sleep mode. The CY8C4013SXI-400 draws approximately 800 µA running @ 4MHz and 2v and 1 uA in sleep mode. (The datasheet for the CY8C4013SXI didn't have numbers for either 4 MHz or 2v, so I had to do some estimating -- the datasheet says it draws 2 ma @ 6 MHz and 3.3v.)

So the ARM draw 4.5 times as much current when awake, and 10 times when sleeping. Doesn't seem like a lot, but its the difference between running on a coin cell for 3 months or for a year. (I'm assuming both microcontrollers are mostly doing timing, updating ports etc. and not doing real heavy computation. If the latter is the case, and the 8-bit micro has to do a lot of multi-byte arithmetic for an extended period of time, it loses some of its advantage.)

It's interesting that the ARM draws about four times as much current as the 8-bitter, and it in turn has internal registers and data paths that are four times as wide. I don't think this is a coincidence. For CMOS, power consumption is roughly proportional to the number of transistors being switched, and the ARM is obviously doing a lot more per instruction executed.

As more ARM vendors bring out low-end chips, I wouldn't be surprised if vendors like Microchip dropped their prices even further. In any case, with the prices more or less equal, similar size packages, but a lot less 32-bit chips to chose from, I think the 8-bit microcontrollers are still going to be around for awhile -- particularly because you've got tens of thousands of engineers familiar with them.

• For power consumption with sleep modes implemented, you'll also have to consider code efficiency. If the MCU wakes up by a trigger, then executes some code and goes back to sleep, the number of clock ticks it takes to finish the job will be quite relevant. I would think that most of the current consumption of a MCU comes from the oscillator running at full speed. To do the same job as a 32 bitter, an 8 bitter will probably need roughly around five times the amount of cycles, simply because they are generally far less code effective even when doing simple arithmetic. – Lundin Mar 24 '15 at 10:53
• (And that's not so much because they have an 8 bit data bus, but mainly because all the mainstream 8-bitters of the market have ancient CPU core designs from the 70s and 80s.) – Lundin Mar 24 '15 at 10:55
• @Lundin I say this in my answer -- if the 8-bitter has to do a lot of fancy math in the ISR, then yet it loses some of its advantage. But if it is just setting some flags, or updating a register, then it will be more efficient. – tcrosley Mar 24 '15 at 14:42

Three main points:

• Price
• Size
• Power consumption

50¢ when you're ordering 10,000 chips is rather a lot of money. Even more when you're ordering 100,000 chips.

You can get 8 bit chips considerably smaller than 32-bit chips, such as the PIC10 that is available in an SOT23-6 package.

32-bit chips, because they are generally clocked faster, and do more, consume much more power than a little 8-bit chip. Batteries drain faster, power systems have to provide more current (and hence be more costly), etc.

After all, why would you buy a juggernaut to take a cup of sugar next door?

• Just compare two chips from the same manufacturer - for instance the PIC18F25K20 and the PIC32MX250F512 from Microchip. Both modern MCUs. Both datasheets have Idd vs clock speed. The 8 bit's graph tops out at 5mA, the 32-bit's tops out at 20mA. If you think about it, an 8 bit operation would do something to 8 latches - a 32 bit would do the same (or equivalent) to 32 latches. That's 4 times the latches that have to be manipulated, so 4x the typical current consumption. – Majenko Dec 4 '14 at 20:03
• Idle current for the 32 bit is between ~0.5mA and 7mA. The 8 bit's graph for idle current is measured on the µA scale and tops out at 7µA - a mere 4µA when running at normal room temperature...! – Majenko Dec 4 '14 at 20:05
• Dig out some datasheets and look for yourself. – Majenko Dec 4 '14 at 20:15
• That is assuming that all the chip is doing is processing. Things take time that aren't dependent on the speed of the chip, such as reading data from external sensors, etc. An 80MHz 32-bit CPU isn't going to read a 100KHz I2C device any faster than a 16MHz 8 bit CPU. – Majenko Dec 4 '14 at 20:21
• Don't forget legacy software (especially for systems requiring certification) and developer familiarity, peripheral/RAM/flash component selection (a microcontroller design with a higher performance processor will use more chip area for memory; a Cortex-M with 256 bytes of RAM seems unlikely any time soon), and package/voltage choices. A good answer should also explain why the 16-bit market is not doing better (and more modern 8-bit ISAs like AVR) and why the 4-bit market is seemingly very constrained (watches and what else?). – Paul A. Clayton Dec 5 '14 at 1:31

The uC applications I've developed for commercial products almost never handled data sizes bigger than 8 bits; so even if 32-bitters were the same price as 8-bitters, there would still be no benefit. As someone else said, we go for what's familiar, so we can punch it out more quickly. The last one I developed however turned out to push the PIC16 I used to the limit in every way-- but that wasn't because of the data size. If I do any more like that, then I really should learn ARM.

• I would guess that for most small-micro applications the largest required data size would be 16 bits or maybe 24. Most applications won't need to do much with things greater than 8 bits, but they'll need to do something. On the other hand, almost every 8-bit microcontroller ever made (if not absolutely every) has a carry flag which make it possible to use a sequence of operations to perform a 16-bit (or even larger) one. – supercat Dec 5 '14 at 20:27

I would expect that ARM chips will take over most of the functions where something behaves like a "computer". On the other hand, a lot of 8-bit microcontrollers get used to do things which could be done with a relatively simple programmable logic device or a moderate number of gates, but can actually be done cheaper and/or with less current draw using a simple 8-bit micro. When designing more complicated applications it's often easier to use a 32-bit micro than an 8-bit one, but if the whole purpose of a chip is to, e.g. watch and debounce a certain input and, if it goes high, start outputting 200 pulses on a certain output at 1ms intervals, then 100 at 2ms intervals, then 100 at 3ms, then pause for 100ms, and keep doing that until the input goes low, designing the code for that may actually be easier on an 8-bit micro than on a 32-bit one. The cost difference between 8-bit and 32-bit micros may no longer be sufficient in many cases to justify spending additional engineering effort to make a project "fit" in an 8-bit micro, but in cases where a 32-bit part wouldn't save any engineering effort there's no reason to spend even a penny extra.

• I agree, but point out that maintaining and staying proficient with two toolchains involves engineering effort of its own. – Scott Seidman Dec 5 '14 at 20:42
• @ScottSeidman: True. On the other hand, it may also be worth mentioning that some 8-bit micros can start running code almost immediately on power-up, while the 32-bit micros I've seen take a bit longer. – supercat Dec 5 '14 at 20:51
• I wonder if we'll ever see ARM license out 8-bit platforms. There are some wonderful features of ARM implementations, like the ability to simply not clock whole peripherals and busses, that should make 8-bit ARMS run rings around other platforms in terms of sipping power. If the mfct's make CMSIS compliant libraries, I think they'd eventually wipe out the big players. – Scott Seidman Dec 5 '14 at 20:55
• @ScottSeidman: Actually, what I'd like to see would be designs which can have the timing-sensitive parts of peripherals (e.g. timers, baud-rate generators, etc.) run with a constant time base which is independent of the CPU speed, but I've seen only minimal support for such a concept. It wouldn't be hard in silicon, but I would guess that synthesis tools lack the means of doing such things efficiently. – supercat Dec 5 '14 at 21:01
• @supercat I'm not sure about other microcontrollers, but the PIC32 has the concept of a peripheral bus clock that can be set up to a different clock speed from the main clock. So you can change the CPU speed, for example to save power, and still keep the same PB clock so you don't have to reprogram all of your peripheral baud rates etc. – tcrosley Dec 5 '14 at 23:13

While I agree that CPU cost and power consumption are the major reasons, one more consideration I haven't seen listed here yet is PCB space. For many kinds of embedded systems, such as, say, an electronic bathroom scale, there is not much need for lots of I/O, no benefit to larger bus size and no benefit to faster processing. However, there is a benefit to a smaller package with fewer pins because it makes the layout and routing of a printed circuit board simpler and often smaller. If a board can be designed as a 2-layer board rather than a 4-layer board, there is a considerable cost savings, and the smaller pin counts that often come with 8-bit processors tend to facilitate that savings more readily than 32-bit processors which generally have more pins and physically larger packages.

• You realize this is a 2 1/2 year old question, right? – Olin Lathrop Apr 18 '17 at 10:59
• @Olin Another point of view doesn't hurt. – m.Alin Apr 18 '17 at 11:01
• @OlinLathrop: yes, my 8-bit CPU driven clock/calendar is working just fine. :) – Edward Apr 18 '17 at 11:03

Even within the 8 bit world, newer types have been known to take very long times to take over in favor of older types - see MCS51 being still alive in its niches and MCS48 still being found in unexpected places.

In many cases, change does not happen because it brings no additional value, and comes with the cost of learning a new technology that hasn't yet proven to be there to stay and/or is expected to still be a moving target (which makes it interesting to people who want to focus on MCU technology but annoying to people who want to focus on their application and not constantly fix and retest production software to adapt this year's ARM vintage!). To some, a component no longer developed is obsolete, to others it has finally become stable, and while it might need workarounds to ingrown bugs, it does at least provide a stable platform for these. Lava flow is not always the antipattern it is cracked up to be - tends to make mountains stay the f... put.