9

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?

Bruno Morais
  • 333
  • 1
  • 9
  • 1
    Power consumption? – Leon Heller Dec 04 '14 at 19:43
  • 7
    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 04 '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 04 '14 at 20:19
  • 2
    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 05 '14 at 10:07
  • 1/10 of a penny per part amortized over $100K additional NRE costs would require a volume of 100M. Even with $10K additional NRE costs it would require a volume of 10M. So if the 32-bit device saves NRE costs because of fewer software development limitations, it may be a cheaper solution in the end. – Jason S Jan 08 '15 at 16:40
  • Here's a relevant article I came across on Electronic Design's website: [8 Bit or 32 Bit? Choosing Your Next Design’s MCU](http://electronicdesign.com/microcontrollers/8-bit-or-32-bit-choosing-your-next-design-s-mcu) – Garth Wilson Dec 11 '14 at 21:13

6 Answers6

17

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.

tcrosley
  • 47,708
  • 5
  • 97
  • 161
  • 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
  • 1
    @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
5

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?

Majenko
  • 55,955
  • 9
  • 105
  • 187
  • About power consumption, I have doubts that it is simple as that. I'd have to see actual data to believe that, because I think it depends heavily on actual architecture and implementation. – Bruno Morais Dec 04 '14 at 19:54
  • 2
    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 04 '14 at 20:03
  • 2
    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 04 '14 at 20:05
  • Sure, but what about all the other families by other manufacturers? This explanation falls short because take for example the MSP430 family by TI. Some of the microcontrollers are very low-power by all standards. And they are 16-bit microcontrollers. The latch/register sizes and transistor count seem to be a good argument but I think that it is not definitive at all. I would think that the same reasoning applies to 32-bit versus the others. – Bruno Morais Dec 04 '14 at 20:08
  • 3
    Dig out some datasheets and look for yourself. – Majenko Dec 04 '14 at 20:15
  • Also consider this: if we have two different devices with different speeds and different power ratings, assuming that once they complete their workload they go to a sleeping state that consumes very low power, what happens to total power consumption and not only instantaneous if the one that is faster is so much faster that although it consumes more current, the overall consumption over the working period is lower than the ultra-low-power but slow device? – Bruno Morais Dec 04 '14 at 20:18
  • 2
    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 04 '14 at 20:21
  • 1
    If you are going to ask a question but argue with the answers, why ask the question? – whatsisname Dec 04 '14 at 20:42
  • 1
    @whatsisname Because I think discussions are a healthy form of fully understanding the problem. I don't think I need to or should accept an answer without exploring the implications. – Bruno Morais Dec 05 '14 at 00:39
  • 3
    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?). –  Dec 05 '14 at 01:31
  • I don't agree with this answer. It's also people, engineers. Not just price, size, consumption. Very often engineers behind it and their past experience form the most important factor in using 8bit or 16bit CPU's. – Al Kepp Dec 05 '14 at 23:49
  • 1
    @AlKepp So write one of your own then. And while you're at it, vote for the question to be closed as primarily opinion based, which is what you seem to have. – Majenko Dec 06 '14 at 00:03
2

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.

Garth Wilson
  • 111
  • 2
  • 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 05 '14 at 20:27
2

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.

supercat
  • 45,939
  • 2
  • 84
  • 143
  • I agree, but point out that maintaining and staying proficient with two toolchains involves engineering effort of its own. – Scott Seidman Dec 05 '14 at 20:42
  • 2
    @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 05 '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 05 '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 05 '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 05 '14 at 23:13
  • @tcrosley: Some ARM processors allow the peripheral clock and/or CPU clocks to be set to sub-multiples of the main clock *but* all of the ones I've seen require that the peripheral and CPU clock be derived from the same source. Thus, if one wants to have a counter continuously counting microseconds while the CPU switches between running at 32MHz and sleeping, the only way to do that would be to keep the 32MHz oscillator running the whole time. Even if the part had a 1Mhz oscillator which, when selected, only used 1/32 as much current as the 32Mhz oscillator... – supercat Dec 05 '14 at 23:19
  • ...there would be no way to have peripherals use that while the main processor uses something faster. – supercat Dec 05 '14 at 23:20
  • @supercat agreed. In the PIC32, the PB can not be higher than the CPU clock. So you can have a PB clock of 10 MHz, and a CPU clock from 10 to 80 MHz; but if you want to run the chip at 32 KHz, the PB would have to be at 32 KHz also. – tcrosley Dec 05 '14 at 23:36
  • @tcrosley: My complaint isn't so much with the peripheral *bus* clock, as with the fact that ARM peripherals often use that clock as their time base. On e.g. a Gecko it's possible to set the system clock to 1MHz and the peripheral clock to sysclk/1 (1MHz), or set the system clock to 28Mhz and the peripheral clock to sysclk/28 (1Mhz), but there's no way to change between a 1Mhz and 28Mhz system clock without having the periperhal clock gain or lose a significant number of counts. IMHO, it shouldn't be hard to design a system so that switching clocks might cause some... – supercat Dec 05 '14 at 23:47
  • ...peripheral-clock events to happen "early" or "late", but that the total deviation between when the nth peripheral clock was processed and when it would have occurred if the clock was perfectly smooth, would never exceed +/- one full cycle of the peripheral clock [e.g. if a cycle gets "missed" at some point, an extra cycle will get inserted somewhere to compensate]. – supercat Dec 05 '14 at 23:49
  • Similar to the 8051 clones (there are still a lot of 8051 based products out there) ARM is not vendor specific like PIC, AVR, msp430, etc. Everyone and their brother will sell you an arm, very hard to get the company/management to switch from what they have invested so much time in but once a company does switch to arm they can remain there and retain that investment even if they switch vendors, etc. – old_timer Dec 12 '14 at 02:52
  • arm is taking this very seriously, cortex-m0+, just a couple of stages in the pipeline, working hard to compete power wise, etc. MIPS coulda/shoulda gotten there first, still can but for whatever reason didnt, doesnt, wont, not doing the right things to compete with ARM. The programmers will help the transition, the 8 bit old timers will retire off and the younger 64 bit programmers will tolerate a 32 bit but not 8 bit environment. – old_timer Dec 12 '14 at 02:56
  • @dwelch: From what I can tell, ARM devices tend to be implemented with almost-fully-synchronous logic; I wonder to what extent routing clocks everywhere affects power consumption vs gating clocks based upon what circuitry is doing, using a split-clock-phase design to avoid differential propagation issues? I would think that e.g. a 32-bit synchronous counter operated off rising edges of a 1MHz clock would require much more power than a 28-bit synchronous counter fed by a four-bit ripple counter operating off falling clock edges, but the output from the latter... – supercat Dec 12 '14 at 17:24
  • ...could be fed cleanly into logic which sampled on a rising clock edge. In the former case, the 1MHz signal would have to be fed to the gates of many transistors. In the latter case, only the first stage of the counter would need to receive a 1Mhz signal. The second stage would receive 500Khz, the third 250Khz, the fourth 125Khz, and all stages beyond only 62.5Khz. I wouldn't expect a 16:1 overall reduction in current consumption, but I would expect a significant one. – supercat Dec 12 '14 at 17:27
1

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.

Edward
  • 2,698
  • 1
  • 18
  • 23
0

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.

rackandboneman
  • 3,085
  • 9
  • 13