8-bit uC - is there even a point?

[newbie666]

Hello,

I've spent couple of days looking at the low end of uC market as I'm trying to select a chip to learn and use in my hobby projects for simple things like driving displays, reading some pots etc. General housekeeping stuff.

I really like 8-bit controllers from silicon labs, but looking at their arm offering I can't help but wonder if there's even a point in using 8-bit chips anymore. Cortex M0+ chips are cheap as chips these days.

So my question is - what are 8-bit uC still used for (in new designs). As a hobbyst, is there still a point in using them or should I invest my time in learning ARM platform?

Regards,
M

[taydin]

8 bit MCU's are very simple. Their manufacturing process is much more coarse than the multi billion transistor chips used in modern designs. For a design that requires ultra high reliability, but not much processing power, these are very positive aspects.

Here is one example: Bit flipping as a result of cosmic rays is possible in modern high density RAM's, but it is very unlikely in the SRAM's that are used in yesterday's 8 bit MCU's.

But to answer your question, definitely learn the ARM architecture, which will be with us for a long time. You can always go back and learn the 8 bit MCU when you need it.

[Psi]

For simple projects i will often fall back to using an 8bit AVR, but whenever i need power its STM32F4 all the way
STM32F0xx or STM32f103 is also good if you need lost cost.

Something you do notice though,
It's easier to do coding on bare metal registers with a 8bit AVR than with an ARM micro.

The registers on 8bit micros are usually designed and structured to be easy to follow.

The registers on a 32bit ARM mcu are designed to be used by a peripheral or HAL library. They're also a lot more complex because the peripherals are more complex..
Hence trying to write register level code on an ARM can be a bit annoying.

Using a 32bit ARM micro means you'll very likely be using a peripheral library, and they're usually shit to work with.
Just when you start to learn the library they release a new version and it breaks everything.
 

[JPortici]

Yes, there is still a point in 8-bit MCU or microchip (just to name one) wouldn't sell millions of them every year.
You don't want to use them? fine, don't. Use what you prefer to use.

Me, i'm contemplating scaling back to an 8-bitter for a project because when comparing the two pre-prototypes
- Some of the peripherals involved are better/more advanced
- Pins are better laid out, which translates into a cleaner layout
- because of above there is an increased complexity in the more advanced MCU so despite it having a better architecture the latency is the same, if not worse
However, the more advanced MCU gives me better tools for debugging and tracing

[sokoloff]

Low power devices (battery power, untethered) are probably the biggest technical reason a hobbyist would be interested in 8-bit micros. (All those additional transistors aren't "free" in terms of power consumption.)

For commercial applications, a chip in quantity being $0.30 instead of $0.90 translates to about a $3 difference in the cost of the finished good on a retailer's shelf, so that's a huge driver. Then, if you're a hobbyist with industrial/commercial aspirations, you might be interested in following that trend as well.

For me, I also enjoy the idea of constraints driving engineering/creativity.

“An engineer can do for a dollar what any fool can do for two.”
― Arthur Mellen Wellington

[NivagSwerdna]

I'm trying to select a chip to learn and use in my hobby projects for simple things like driving displays, reading some pots etc.

For generic projects the cheapo hardware is Arduino Uno clones (ATmega328), esp8266, esp32, STM blue pill etc.  These devices cost nothing (compared to your time).
At some point you will have a specific project requirement that will make your choices more interesting.

[NorthGuy]

There is practically no benefits of having 32-bit processor (as compared to 8-bit) for most simple projects. It's the periphery you should look at.

That said, investing your time in learning is always a good idea.

[CJay]

The benefit of the simple 8 bitters is the utter simplicity of them, I can get a simple PIC up and doing 'stuff' in minutes with a page of assembler and no templates, I can't even find the relevant chapter in the ARM documentation in that time.

That said, the ARM chips are so incredibly powerful for the money it's difficult not to wonder if one should throw out all the old chips and use those instead.

[Warhawk]

As you may already expect, they are typically easier to program and design with. Just have a look how many bypass capacitors you need around e.g. STM32F051 and a similar 8-bit micro.
I do both but I seldom need higher computing power or memory. My programs spend most of the time in delay routines (= waiting for an event) anyway 

I suggest spending some time with 8-bits uCs and then looking into ARMs, e.g. STM32F0x. You will immediately see the difference when you start endlessly configuring the chip, PLL, stack, clock domains.. 

[nctnico]

I'd suggest going for a simple ARM (IMHO the LPC series from NXP is reasonably simple to get going; on par from what I've seen on typical 8 bit microcontrollers). On a fast 32 bit platform you are not running into speed limits and complications due to overlapping memory / seperate memory areas, etc. Looking back I really wish the modern 32bit ARM controllers existed 30 years go. They would have made a lot of my projects a whole lot easier. Also don't look at the price of the chips too much. Spare time is also valuable.

[legacy]

if you want a cheap chip with a decent design, go for Avr8. You are full of support. If you then want to see something more advanced, go to Xmega.

[newbie666]

Thanks for all the replies - it's an interesting discussion. I think I'll order two boards one containing geco, the other bee chip from Silicon Labs and spend some time to evaluate them.

Keep the discussion going, I'm interested in all of your opinions.

[Jan Audio]

I like that PIC16 has seperate port with max 8 pins,

[HB9EVI]

When I stepped forward from AVR towards ARM (STM32), I noticed to spend much more time scrolling through the datasheet finding a certain information than I was used on the AVR; well was likely caused in my refusal of using fancy libraries like the real pita HAL.

So today, if I need power, what means in my case big TFTs, Ethernet, I2S or else, I use ARM, for lower end projects I prefer AVR

[SiliconWizard]

As you may already expect, they are typically easier to program and design with. Just have a look how many bypass capacitors you need around e.g. STM32F051 and a similar 8-bit micro.

On a hardware level, that's often true, although it usually depends on the pin count. STM32s are rather easy to integrate otherwise.

On a software level, that's a different story. Although the simplicity of 8-bitters may be less intimidating at first, their inherent limitations, especially regarding the memory models, can be a real PITA. Their limited ALUs as well. Some don't even have hardware multipliers or very limited ones (size-wise), which can make some computations extremely slow.

Typically, for a programmer that comes from the PC software world and wants to do embedded development, using a 32-bit MCU will probably be much simpler, at least from a programming standpoint.

The price tag really matters only if you make very cheap devices in large quantities.

As for power consumption - there are so many ultra low power 32-bitters these days that this is becoming a moot point unless you target ultra ultra low power (that you will find in only a handful of 8-bitters anyway) for very simple tasks. For more involved tasks, you may find that they spend a lot more time in run mode than a 32-bitter would, thus drawing actually more on average. So obviously, it all depends on the application, but the sweet spot may be hard to find before actually testing.

Other things to consider are the development tools, their quality, availability and cost.

[nctnico]

When I stepped forward from AVR towards ARM (STM32), I noticed to spend much more time scrolling through the datasheet finding a certain information than I was used on the AVR; well was likely caused in my refusal of using fancy libraries like the real pita HAL.

IMHO that is an STM32 specific problem. ARM microcontrollers aren't made equal and some have better documentation / easier to understand peripherals than others.

[HB9EVI]

Yea, I heard the critique on STM32 from several sides; personally I'm missing the comparision to other ARM uC so far; but I guess I'd agree with it.
Certainly one is going the 'easier' way using the HAL, however I decided to not use right after the first glimpse on it; but I always worked bare metal

[Kleinstein]

if you want a cheap chip with a decent design, go for Avr8. You are full of support. If you then want to see something more advanced, go to Xmega.

The XMEGA is essentially dead since AVRs come from microchip. There are now some new ones with a more confusing naming that is similar to the xmegas:  still AVR8 CPU with little changes, but ARM like periphery.

The AVRs are a relatively easy to learn type with short erratas. So a nice and easy start.

One more problem with most 32 bit micros is that they usually use some kind of cache memory that makes the run-time less predictable. The 8 Bit µCs usually have absolutely predictable run time, at least in ASM.

Price wise at the low end (low memory) and in large quantities the 8 bit µCs are still lower in cost, but this is not that relevant for a hobby use. With lots of memory the costs for the 8 bit µCs can be even higher than the 32 bit versions - so the 8 bit one are more something for the low end.

[PCB.Wiz]

I really like 8-bit controllers from silicon labs, but looking at their arm offering I can't help but wonder if there's even a point in using 8-bit chips anymore. Cortex M0+ chips are cheap as chips these days.

So my question is - what are 8-bit uC still used for (in new designs). As a hobbyst, is there still a point in using them or should I invest my time in learning ARM platform?

Of course 8 bits are alive and well. They are simpler, most have wider Vcc, and are still cheaper.
SiLabs have very good Analog peripherals, and their DAC parts are cheaper than buying a 12b DAC, so you find these days, parts like that are used as well as an ARM

The 8051 core is seeing a resurgence in Asia, and companies like Nuvoton have N76E003 parts starting at 25c, for 18kF, and STC have STC8H series coming.

That said, if you are not into volume production, many hobbyists even use Raspberry Pi modules, and are happy with that level of operation.

For casual use, choose the core that has the best debugger support.

[NorthGuy]

... their inherent limitations, especially regarding the memory models, can be a real PITA.

They may. But under some circumstances, they may be turned into advantages. For example, some of PIC16 have the PCLATH register which must be set every time you do GOTO. This is certainly an example of PITA you're talking about. However, I had a project once, where I managed to put 3 different apps into a small PIC16 by giving each of them its own page. Each application had its own ISR, its own table of virtual functions. Switching between them was as easy as setting the PCLATH register. It is really fast and it preserves good ISR latencies. Replicating the design with "proper" 32-bit chip while preserving the same latencies would require really big and fast chip.
 

[Mr. Scram]

Many ARM chips require external tools to configure properly. They're quite complicated beasts. An 8 bit chip is less capable, but obtaining full control over it is doable. If you want simple and robust, the 8 bitters still have an edge.

From a hobbyist perspective I guess it's much more fun to drive around in a bare bones Beetle than it is to zip around is a modern Twingo. The latter gets the job done, but it's just not the same to drive or tinker with.

[SiliconWizard]

... their inherent limitations, especially regarding the memory models, can be a real PITA.

They may. But under some circumstances, they may be turned into advantages. For example, some of PIC16 have the PCLATH register which must be set every time you do GOTO. This is certainly an example of PITA you're talking about. However, I had a project once, where I managed to put 3 different apps into a small PIC16 by giving each of them its own page. Each application had its own ISR, its own table of virtual functions. Switching between them was as easy as setting the PCLATH register. It is really fast and it preserves good ISR latencies. Replicating the design with "proper" 32-bit chip while preserving the same latencies would require really big and fast chip.

That's certainly an interesting use of paging.

And all in all, granted that 8-bitters usually have (sometimes much) lower interrupt latencies than the 32-bitters for a given clock frequency.

[digsys]

... I really like 8-bit controllers from silicon labs ... 

I've been using the Silabs series for years, and still am. They have an awesome amount of I/O A/Ds D/As IRQs etc etc There's bugger all I can't do without them.
It's vert rare that I need anything bigger, and I can often split a design up with 2+ modules and if needed, a simple 16/32 IO peripheral.
I've even replaced legacy / dedicated 3rd party ICs with a cheap single ~$2-3 8051. They won't die :-)

[richardman]

All our new designs use the new 32-bit ARM MCUs. From a price, performance, and even ease of use in terms of not less limited by the I/O peripheral capabilities, ARM MCUs win in every way.

[Bassman59]

So my question is - what are 8-bit uC still used for (in new designs). As a hobbyst, is there still a point in using them or should I invest my time in learning ARM platform?

Say you have a main board and a front panel/user-interface board. Your main board has a big micro or an FPGA or whatever, and you could run a large ribbon cable between the two boards so the main micro could control everything on the front panel, or you could use a small 8-bitter as a co-processor, managing all of the user interface stuff and communicating with the main board over SPI. SPI at 20 MHz, say, gives you a ton of bandwidth for reading buttons and encoders and updating the blinkenlighten.

Some of these 8-bit guys are cheaper than those I2C-based LED drivers. It's crazy.