Advantages of 32bit micros

[Aodhan145]

I really only use a couple of arduinos and like a pic so I probably wont avail of the advantages. I recently bought a ti tiva c TM4C123GXL launch pad as they are so cheap. Its great I use it a lot. I understand the differences in speed, RAM etc but what about practical advantages things you can do on a 32bit micro that you cant do on an 8bit?

[0xdeadbeef]

Well, "can't do" is a bit black and white. But modern 32bit CPUs like Cortex M3 and M4 have quite a lot about them to like.
Cortex M3 has hardware division, a lot of nice opcodes e.g. for counting leading zeroes, reservation (for atomic read/modify access) and stuff like this.
Cortex M4 adds DSP extension and an optional FPU.
Debugging posibilities (JTAG or SWD) are usually pretty good. Often it's possible to read/write to variables and registers while the CPU is running.
Some CPUs even have a micro trace buffer.
Depending on the actual CPU, there's also usually a lot of complex peripherals like 32bit timers, DMA and stuff like this that's typically missing on 8bit CPUs.

[rsjsouza]

0xdeadbeef is right; 8-bit processor cores are able to do most of what 32-bit cores do, unless the architecture is unable to access large memory ranges (in general 8-bit architectures are more limited on that aspect). Between the two, the main difference in this case usually relies on performance - as mentioned before, math operations with large or floating-point numbers have extra bits or dedicated hardware to be computed faster on a 32-bit architecture.

As a general statement the processor core datapath size does not influence the functionality of code written in C language. If you are performing code migration, other factors must be taken into consideration such as inlined assembly instructions, compiler implementation (vendor or architecture extensions that create ties to the core), and differences in peripherals, among others.

All in all, simpler operations and systems benefit from an 8-bit architecture given not only its lower cost (for large volume manufacturing this makes a huge difference) but also possibly lower power (although with more modern architectures this can be highly debatable). For regular hobbyists and low-volume manufacturing runs, the price difference is smaller and the benefits of using the same architecture in a broader range of products tends to tip the scale towards 32-bits.

Disclaimer: I have used large VLIW DSPs in the past and currently I am a big fan of MSP430 (16-bit) and TM4C (32-bit) devices.

[AlxDroidDev]

All in all, simpler operations and systems benefit from an 8-bit architecture given not only its lower cost (for large volume manufacturing this makes a huge difference) but also possibly lower power (although with more modern architectures this can be highly debatable).

8-bit Atmega328 : about US$ 1.70, in large quantities > 1000

32-bit STM32F301K6U6: US$ 0.986, in multiples of 10k

So, the 8-bit uCs loses in that aspect. Also, the faster the CPU runs a routine, the faster it can go into sleep mode and stay there longer until there is something else to be executed. That saves a lot of power, because they are executing things for a much shorter time. So they are more power-friendly than the 8-bit.

In short: 8-bit uCs are more expensive and use more power.

Their price advantage, however, is not on the chip itself, but on the supporting circuitry that is required to make them run. An AVR, for instance, can be run with nothing but a bypass cap... and on a breadboard! You don't even need a xtal if you use the internal oscillator. Most 32-bit CPUs need more external circuitry, which makes the project a little more expensive and take more PCB real estate. Try breadboarding a Cortex M3...

The part where 8-bit uCs really shine - at least in my experience - is the easiness to code them. Take the Arduino or PIC ecosystems: there are lots of examples for everything, and it all works even on slightly different chips. Even if you use Atmel Studio, code is simple enough and most times you don't have to worry if you have an Atmega8, Atmega2560, Atmega328 or Atmega1284: the code is very much the same most of the time. When it comes to 32-bit Cortex chips however, you have to code for the specific uC you have, and that is a pain the ass.

Neverthless, I still use mostly AVRs. Why?
First, I have about 30 chips at home, of several models (M8, M328, M1284), because I got them for cheap from Amazon the last time I went to the US. Second: I save tons of time in development. Like I wrote, easiness of coding is what makes 8-bit shine at the moment, but hopefully this will change.

[rsjsouza]

8-bit Atmega328 : about US$ 1.70, in large quantities > 1000

32-bit STM32F301K6U6: US$ 0.986, in multiples of 10k

So, the 8-bit uCs loses in that aspect.

Anecdotal evidence. A single example taken from specific part numbers is not a true benchmark. If 32-bit was more expensive in all scenarios, TV remote controls wouldn't be using 4 or 8-bit microcontrollers from Holtek, for example.

To take ST as an example, their lowest-cost 8-bit is US$0.391 in 10k quantities.

[rich]

The part where 32-bit uCs really shine - at least in my experience - is the easiness to code them. Take the Arduino or PIC ecosystems: there are lots of examples for everything, and it all works even on slightly different chips.

I'm struggling to parse the above. Did you mean to type 8-bit uCs ?

Maybe when you get to M3, M4 levels then you need to crystals and supporting components, but there are several M0+ level devices with internal oscillators, not many DIP packages suitable for breadboarding though.

[0xdeadbeef]

Actually most NXP Cortex M3s have an internal oscillator. Typically 12MHz. Then again, adding an Xtal and two capacitors is not rocket science and allows higher clocks and more precise timing.
It's not so difficult to create a small PCB with the µC+XTAL+caps and debug/supply pin that can be used for breadboarding during development or even as CPU board for a project.
Did that for LPC1347 and LPC1549.

[AlxDroidDev]

Post corrected.

[nctnico]

Actually most NXP Cortex M3s have an internal oscillator. Typically 12MHz. Then again, adding an Xtal and two capacitors is not rocket science and allows higher clocks and more precise timing.

Not quite right. The internal RC oscillator (1%) in the NXP devices can be used to run the core at maximum frequency using the PLL. Needing to use a crystal is rare for my typical projects.

[Brutte]

Advantages of 32-bit over 8-bit for low volume and hobby projects..

Less constrains.
Typically 8-bitters end up in 128k words program size while 32-bitters with 1M words are not uncommon. Additionally I have never heard about an off-the-shelf 8-bitter with TFT display controller, USB HS, BLDC controller, 5 UARTS, 3 SPIs etc.
What can be made with 100h/100$ using 8-bitter, can be made on 32-bitter with half of that budget. Things change with higher volume but for low volume it does not matter if a uC is $2 or $12 a pop when it saves you time and gives flexibility.

[0xdeadbeef]

Not quite right. The internal RC oscillator (1%) in the NXP devices can be used to run the core at maximum frequency using the PLL. Needing to use a crystal is rare for my typical projects.

Indeed you can use the IRC oscillator as source for the main PLL (not for the USB PLL as far as I recall) in most LPC devices. I wouldn't be so bold to say that it's possible in all devices or that it's always possible to reach the maximum frequency since the IRC oscillator frequency is sometimes quite a bit lower than 12MHz (like 4MHz for the LPC178x). Also keep in mind that the 1% deviation means you also exceed the maximum frequency by 1% which might be OK for hobby use, but is nothing you would usually do in a commercial environment. Letting aside that some asynchronous protocols like CAN require better accuracy than 1% (e.g. 0.3% accuracy for 500kbit/s CAN).
Also e.g. the LPC176x manual clearly states that you should not use the main PLL for the USB peripheral if the main PLL is driven by the IRC oscillator and the USB PLL can only use the XTAL as source.
So if you want to use USB, you need the crystal anyway.

[dannyf]

For most projects, the difference between an 8 bit mcu and a 32 bit mcu is practically no.

Generally speaking, 32 bit mcus can run faster, have more space, and have more and better peripherals. So if your application is math intensive, go with a 32 bit mcu.

On the flip side, A 32 bit mcu is much more complex to learn and to code, consumes more current, and are more expensive.

I would suggest that you pick a mcu based on its peripherals, OEM aupport, software investment, and not on its core.

[Sal Ammoniac]

For hobby projects cost isn't a consideration. A $1 8-bit MCU versus a $10 32-bit MCU would matter in a commercial product, but for the one-off projects that I do it's lost in the noise.

Commercial products tend to squeeze the cheapest, smallest MCU into the design the designers think they can get away with. This makes financial sense, but it often causes problems later when additional features need to be implemented or fixes made and the developers are right up against a flash or RAM capacity wall. When I do a project, on the other hand, I tend towards massive overkill with respect to the MCU, with much much more flash and RAM than I really need, just because I can and because an extra $5 for a hobby project that I do perhaps 4-5 of a year means the additional cost is just peanuts.

[dannyf]

"Commercial products tend to squeeze the cheapest, smallest MCU into the design the designers think they can get away with."

There are commercial products and then there are commercial products.

Of the ones I have worked over the last few years, the mcu choices were driven largely by software availability, certification, and corporate sourcing decisions, as performance was a non factor. In those cases, software costs far outweighed hardware costs.

I think it greatly depends on where your mkt niche is. I tend to think that if you are penny pinching that much, you should consider if that's the right place to deploy your resources.

[Sal Ammoniac]

There are commercial products and then there are commercial products.

I was referring primarily to mass market consumer products like TV remotes, toys, toothbrushes, that sort of thing, although even expensive items are often are looked at through a cost reduction microscope.

[andyturk]

... but what about practical advantages things you can do on a 32bit micro that you cant do on an 8bit?

ARM Cortex-M isn't synonymous with "32bit micro" but comes pretty close... And a big advantage of Cortex-M is the availability of a world-class toolchain for free. That's GCC, of course, and it sits inside most of the OEM development environments even if the UIs are vendor specific.

[Sal Ammoniac]

PIC32 also has GCC support, along with an IDE based on NetBeans, which, IMHO, is better than Eclipse.

[nctnico]

For most projects, the difference between an 8 bit mcu and a 32 bit mcu is practically no.

Generally speaking, 32 bit mcus can run faster, have more space, and have more and better peripherals. So if your application is math intensive, go with a 32 bit mcu.

On the flip side, A 32 bit mcu is much more complex to learn and to code, consumes more current, and are more expensive.

wrong wrong and wrong.
1) 32 bit MCUs have a flat memory space where 8 bit microcontrollers like 8051 and PIC have convoluted memory layouts not even allowing to use pointers properly and need pragmas to place variables into certain memory areas manually.
2) Cortex M0 devices are very power efficient. Recently I had to choose between MSP430 (king of low power) and an NXP Cortex M0 device... The M0 device turned out to consume just as much power
3) The NXP Cortex M0 device under point 2 was cheaper than the MSP430 device which fitted the design.

[Gribo]

One critical advantage of the 32-bit MCUs is an MMU. yes, not all of them have it, but it makes your life so much easier in larger projects.

[hamdi.tn]

i used PIC 8-bit MCU a lot , but since i start using  STM32 2 or 3 years ago, i didn't design any product with PIC mcu again.
price is good and i can say even if i don't need most of it's functionality for some project, i prefer to use a STM32 than a 8-bit PIC cause most of the time a PIC18F is the same price if not more expensive than a STM32F.
The only problem with them is as some ppl said here, learning how to use that take much more time but as any new thing it take time to learn how to use it, so no excuse there.

[Brutte]

One critical advantage of the 32-bit MCUs is an MMU. yes, not all of them have it, but it makes your life so much easier in larger projects.

I have never heard about a microcontroller with MMU. Reference, please.

[Codemonkey]

I have never heard about a microcontroller with MMU. Reference, please.

NXP LPC3220/30/40/50

http://www.nxp.com/documents/data_sheet/LPC3220_30_40_50.pdf

[coppice]

I have never heard about a microcontroller with MMU. Reference, please.

NXP LPC3220/30/40/50

http://www.nxp.com/documents/data_sheet/LPC3220_30_40_50.pdf

NXP describe that as a microcontroller, but its not really what most people think of as a microcontroller. It has a lot of on board peripherals, but needs external memory. This is becoming a grey area, though. A number of chips most people do think of as MCUs may have internal memory, but that needs to be booted from an external serial flash chip.

[Jeroen3]

32 bit processors often have a von neumann software approach, whiles using a harvard hardware approach.
This results in a single piece of assembler being able to read/write from any place. Peripherals, RAM and ROM and external ram/rom. The core will have multiple buses to the bus matrix, yet the programmer is not able to influence which is used. As opposed to AVR or 8051 where you need separate instructions to read from flash, switch address overlays to access more memory if it does not fit in a 16 bit address. Which makes the software design more lower level.

In short: you can use pointers more easily, which can make your life hell or heaven depending on your coding skills.
Allowing you to take more distance from assembler, and go into the higher layers.

[VEGETA]

from my opinion, I find 8-bit uC still better in terms of using them by beginners. Like, they can be hooked on a breadboard and with minimal circuitry. However, 32-bit ones MUST be on a dev/whatever board to be used by beginners. One can buy a PIC chip and use it, but when he wants to buy a 32-bit ARM one he asks "which manufacturer is better?" and "what board should I get?".

Also, dev tools like IDE and compilers are harder in 32 bit. you can not even name a standard one that the industry uses.