8-bit uC - is there even a point?

[langwadt]

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.

and there are several ARMs that are faster, with more flash and RAM that is just as cheap

[AndersJ]

Many posters have mentioned the PIC and AVR 8 bitters in the preceeding posts.
How about all the other traditional mcu’s, such as HCS08 and HCS12?
Are they no longer used?

[james_s]

I still use 8 bit AVRs. They're simple, dependable and familiar. I messed around with ARM some but even just setting up the environment to develop for them is far more complex and for most of the stuff I'm doing the added horsepower is wasted. Even the 8 bit AVRs spend most of their time twiddling their thumbs waiting for something to happen.

[rx8pilot]

I am designing a brand new system with 4x 8bit AVR's in it. The tasks are appropriate for the capability of the AVR's, I can distribute the tasks to physically separate MCU's, they are low power, cheap, familiar, reliable. There are 9 PCB's in the system so a single 32bit MCU with big IO capability would be a signal routing disaster.

One deals with a few buttons, LCD display, and a few LED's, another is essentially an IO expander since I need to monitor quite a few low-speed digital inputs, another is primarily for A/D conversion to monitor fairly slow analog signals, the fourth one is master control with the most robust firmware. They are all connected with I2C so it only takes 2 wires from PCB to PCB instead of 40+ discreet signals per PCB.

I like them, even for modern and brand new designs of industrial gear.

[thermistor-guy]

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.

 ... As a hobbyst, is there still a point in using them or should I invest my time in learning ARM platform?

I am biased by my experience, having fond memories of developing embedded telecom applications on 8051-type chips.

8-bit microcontrollers generally allow you to get close to the hardware. This is useful for driving unusual or DIY peripherals, directly and simply, with predictable timing and behaviour.

OTOH, I have settled on Raspberry Pi modules + Linux for applications which require more networking capability, more processing power, more logging and remote management functions, but which need only interact with standard interfaces like serial, USB, ethernet and so on.

So if I was building, say, some custom test gear for personal use, I would be tempted to partition the design, to speed the development: use a microcontroller (8-bit, 16-bit, or an FPGA) for the direct hardware control. Then add an rpi to supervise the controller and add the higher-level features: logging, management, flexible networking and so on. The rpi could be inside the test gear or outside it.

If you are working closely with peripheral hardware, then there is a place in your skill set for small easy-to-use microcontrollers.

[langwadt]

I am designing a brand new system with 4x 8bit AVR's in it. The tasks are appropriate for the capability of the AVR's, I can distribute the tasks to physically separate MCU's, they are low power, cheap, familiar, reliable. There are 9 PCB's in the system so a single 32bit MCU with big IO capability would be a signal routing disaster.

One deals with a few buttons, LCD display, and a few LED's, another is essentially an IO expander since I need to monitor quite a few low-speed digital inputs, another is primarily for A/D conversion to monitor fairly slow analog signals, the fourth one is master control with the most robust firmware. They are all connected with I2C so it only takes 2 wires from PCB to PCB instead of 40+ discreet signals per PCB.

I like them, even for modern and brand new designs of industrial gear.

9 pcbs? what are you building the next generation space shuttle?

[rx8pilot]

9 pcbs? what are you building the next generation space shuttle?

Slightly less ambitious......

The PCB count was determined by the form factor and the mix of power-analog-and user interface.

One PCB is the delicate master control, another is a display, another is power routing with 3oz copper, another is for a bunch of LED and PWM controllers, another for SMPS control, etc, etc........each PCB has to be in a particular place and has different electrical needs from 6-layer 1oz to 2-layer 3oz.

In the end....it all fits into an enclosure that fits in the palm of my hand.

[Rerouter]

Then there are those anomaly chips that just suit your project perfectly, there are plenty of 8/16 bitters out there where every pin is routed via an ADC mux, e.g. you need a 22 channel ADC with SPI, well that is a 32 pin 5x5mm QFN in 8 bitter land, bit harder in ARM,

Its whatever is fit for purpose, I can bash out and bit-bang protocols on an 8 bitter getting a product out the door in 3 days of software dev time by twiddling registers from the datasheet for simple stuff, But when you need raw processing power to solve a problem, its hard to avoid an ARM or FPGA,

[PCB.Wiz]

Many posters have mentioned the PIC and AVR 8 bitters in the preceeding posts.
How about all the other traditional mcu’s, such as HCS08 and HCS12?
Are they no longer used?

Sure, still used.

The HCS12 are still Automotive active at NXP, and the HCS08 had a press release last year for the MC9S08PA4AVDC
However, the price point of that part is not great at 70c/5k for a 4k core part, so they are certainly 'tail end' parts.

[legacy]

The PCB count

which software are you using for the the CAD/CAM?

[legacy]

How about all the other traditional mcu’s, such as HCS08 and HCS12?
Are they no longer used?

My door-neighbor, in the place I am hosted at the moment, works at Beckman, he told me they have customers in remote corners of the Earth, who are still using 68HC11, well ... they still have equipment (oil pipelines) based on HC11 ... still solid working. When something goes defective, that is the when you have to take the airplane, go there (usually it's not a good place to visit), and replace the old equipment with a modern one, base on a completely new MPU.

But, they want it to last at least for 20 years. I haven't asked what he is confident to use to have so long life expectancy.

Here I wasn't so lucky when I found a decommissioned weather station, again based on HC11, someone removed the shield and trashed it out into the dump, where the sun and the rain made the rest ... with UV rays penetrating into the frame, erasing the PROM.

The firmware is gone, the PSU is dead, as well as sensors and the LCD is completely dark, but the rest of the hardware is still solid-working, even if it was exposed for four years to the weather 

In short, it seems you can't easily kill a Motorola HC11 chip, and the funny story is, my other door-neighbors have told me we have some ARM chips to open and close doors and window-shades in our apartments, and when a thunderstorm happens ... these chips might randomly fail, lose the configuration, etc etc ... - "do as you wish, but we suggest you keep the keys with you because if the thunderstorm makes the domotic chip to fail (or to die) your badge won't be able to open the door" -

Probably the defect is due to a bad ground shield, but the story is funny 

[Kjelt]

I guess the F0 arm chips are the 8 bit uC killers, they seem to have everything the 8 bitters have and more (ROM-RAM - faster) and eventually the 8 bitters will be phased out by the silicon vendors.
Still I like the small 8 bitters since they run on 5V have internal oscillators and don't need many external components, but some F0's will probably also have these qualities (not sure have to check).

I think that an 8 bit design is still preferred for starters since it is much easier to grasp (complete datasheets of 200 pages instead of 3 different datasheets some going over 1000 pages) and play with than the arm chips.
If you are giving some educational course or something similar and you have 30 hours to get students to learn the basics of microcontrollers and want >90% of the students to succeed I think a 8 bit uC would have more success than the 32 bit Arm architecture but if you want to prepare your students for the future you can only teach the 32 bit Arm world.

[mikeselectricstuff]

I regularly use 8 and 32 bit PICs. The main reasons I choose the 8 bit (PIC) parts :
Low pin-count/small easily solderable package : 6/8/14 pin,  SOT23/SO/SSOP/QFN as required - many low-end PICs have 3 or 4 choices of package.
Wide supply range - runs from the whole range of a Li-ion,2 or 3xAA, coin cell or USB with no regulator while maintaining <1% internal RC osc accuracy, minimising external parts.
5V operation (5V levels commonly needed when driving LED drivers that are supplied from 5V)   
Low total cost, especially when using Microchip's factory programming service, which is only  a few cents for the small 8-bit parts.

[JPortici]

There are some cortex M0+ that come in +5V Variants (like ATSAMC21) and even some M4 (Kinetis E)
However, i have evaluated the ATSAM for a while and sorry but give me a PIC18 (K42/K83) any day. Don't care about doing math, the peripherals on the PIC18 (K42/K83) are so much better

[EEVblog]

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.

But generally not as cheap as 8 bit micros in production quantity.
They also tend to have a reputation of still being sold in 10-15 years time.
Also the 8 bitter come in tiny low pin count packages and can often work from 5V.

[legacy]

if you want to prepare your students for the future

you'd better teach them how to design 

[rjp]

With a fancy pants 32bit SMD you cant pick up  a bit of holey board and crudely   bodge up a circuit like you can a with 8 bit DIP.

super cheap breakouts like the bluepill or esp32's do make that somewhat moot.

[wraper]

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.

But generally not as cheap as 8 bit micros in production quantity.
They also tend to have a reputation of still being sold in 10-15 years time.
Also the 8 bitter come in tiny low pin count packages and can often work from 5V.

Yep, for example I like their MCUs with USB. I can get MCU with USB, decent ADC which is more flexible to use (in analog) than in most MCUs, internal 3.3 vreg (that can provide up to 100mA) and precise internal oscillators, starting from $0.75 at qty of 1 and $0.65 Q qty of 100, $0.55 @ qty 1000. I don't even need any crystal. MCU and a few decoupling caps is all I need to get a working USB device. Try that with ARM.
Also there is extremely cheap end of 8 bitters where MCU can cost less than 5 cents.

[JPortici]

if you want to prepare your students for the future

you'd better teach them how to design 

  unfortunately that requires the teacher to have a hint of experience in designing

[brabus]

You will end up learning how to use them both. Once you start working with one architecture, the jump between similar platforms is easier.

Each project has different constraints, that may be completely independent from BOM price, e.g.: part number availability in 10 years, SMT package, etc., so 8-bit uCs still have A LOT to say nowadays.

[Peabody]

For me the Goldilocks format is TI's MSP430 parts, which are 16-bit.  Secure supply, and many in DIP packages.  But unfortunately they are more expensive than pretty much anything.

[Siwastaja]

I still use 8 bit AVRs. They're simple, dependable and familiar. I messed around with ARM some but even just setting up the environment to develop for them is far more complex

This is fully your choice, not a necessity. I have never installed any complex environment for ARM development, and my setup is simpler than on AVR. On AVR, I use:
text editor
avr-gcc
avrdude
Special custom programming device - which always gets lost, and is a separate dongle in addition to USB serial used for development work

On STM32, I use:
text editor
arm-gcc-none-eabi
stm32sprog
Ubiquitous USB serial cable for both programming* and development prints.

*) at least initially, before I write my own flasher

And that's it.

Otherwise, my flow on ARM is exactly the same it was on AVR. The only difference is, instead of 300 pages of peripheral documentation, you have 3000 pages. You have many more features to utilize, and of course it will be a bit more complex. But there is absolutely no fundamental difference. The basis is the same - just more details.

There are many simplifications, as well. ARM core is simple to understand, the memory models are easy and bring no surprises, large number of interrupt vectors and being able to use any standard function as interrupt handler makes understanding everything easier. Having no separate "fuses" means less confusion when programming a device and trying to get it work. (At some point, you tend to "brick" an AVR by typo'ing a fuse value - at least to a state where you are not experienced enough to recover it, for example, by using a function generator as a clock source. Won't happen on STM32.)

It's great when everything's nicely memory mapped, and everything just works automatically. No need to use special instructions to store data on flash only, like on AVR, for example.

On an AVR, lighting up an LED is two lines of code (DDR and PORT register writes). On an STM32, it's three lines of code - the IO port must be turned on first, then it's the same thing.

But, I agree all the details on a modern MCU can be overwhelming. A simple, small AVR gives a good initial idea how to work with microcontrollers in general, and then you can go on. But I recommend going ARM before you are on the level of understanding all the quirks and internal details of the ARM core.

But my strong personal opinion is: definitely keep the simplicity of the development flow you learn on an AVR. No need to go fancy with tools and libraries - they are mostly crap anyway.

For more complex stuff, I always write my own tools, which is very rewarding.


---

In general, it's up to what peripherals you need and which MCU provides them - the core is often the most irrelevant part. But, the peripherals tend to be exactly the strong point of modern ARM controllers, compared to an AVR. On an AVR, a 3-phase motor control output or CAN controller is a specialistic flag-ship high end thing; on STM32, they are in the cheapest entry-level part. Similarly, multiple ADCs, DACs, comparators, opamps, etc. seem to be almost a norm.

But sure, sometimes an 8-bit PIC has just the right set of peripherals for a job an STM32 with 8 UARTS and 5 SPIs and 5 IC2S and camera interface and 2 CANs and ethernet and USB high-speed and LCD interface and JPEG codec and God know what can't do as easily.

[Whales]

Q: Can anyone recommend some 32-bitters that work with simple or open-source toolchains (or similar)?  Something you can install without pain on any computer, something that doesn't need a license or GUI or gigabytes?

I'm currently sticking to ATMEGAs and STC15's because I have working toolchains for both (avrgcc+avrdude, sdcc+stcgal) that seem easy to install and get working on "other people's computers".  This has allowed me to avoid fearing project handovers -- some docs and a script are enough, as opposed to handing over a whole dev environment/machine/vm as well.

A few years back I bought some stm32's and tried to get them working.  I spiralled into toolchain doom, not realising that there were so many options (the ones of which I tried were broken).  Not to mention I was completely unprepared for the increased complexity of programming.  The 8-bit AVR world has spoiled me there. 

[xani]

Q: Can anyone recommend some 32-bitters that work with simple or open-source toolchains (or similar)?  Something you can install without pain on any computer, something that doesn't need a license or GUI or gigabytes?

Two options to consider:

Teensy - It just have an arduino plugin. Can't get much simpler than that (well, except ARM arduinos I guess)

Silicon Labs - You do need few hundred megabytes (their software is GUI based off eclipse). Their dev boards also have builtin power analyzer so pretty useful if you are playing with low power stuff. Their parts are also pretty cheap and with decent feature set.

Builtin bootloader too, altho that's (thankfully) pretty common feature

I've started playing with them because I needed something low power for tiny IoT project and their micros had both low power stuff and the hardware AES acceleration


As for software... pretty much *any* typical ARM will just compile with GCC and program with openocd and stlink clone, just that you need right header files to do so, so there is usually some messing around involved unless you get ready made template.

I generally just use *insert processor here* IDE/pinout editor to generate inital empty project, then go from there with just my usual editor and makefile

[Siwastaja]

Q: Can anyone recommend some 32-bitters that work with simple or open-source toolchains (or similar)?  Something you can install without pain on any computer, something that doesn't need a license or GUI or gigabytes

AFAIK, almost any general purpose ARM microcontroller! I use STM32 the way you describe in your question, but all "normal" stuff should work. To test if it works, try to download the datasheets and reference manuals. If not under NDA, and if readable, and if they contain all the peripheral register configuration information, etc., you are good to go.

Everyone uses GCC for compilation anyway. You can just go without front end gui crap, and install gcc-arm-none-eabi. For example, from here:
https://launchpad.net/gcc-arm-embedded

No license, no gigabytes, no GUI. The compiler doesn't even know which brand your controller is. They are all ARM!

This thing alone is the best reason to go ARM, IMO. Free open source tools guaranteed, work automatically, completely agnostic to the manufacturer - the core is the easy part. You only need to look at peripherals, and the way you can download the code to the chip, but almost every ARM brand has simple factory bootloader options (which don't exist for most 8-bitters).

What you need are some header files. You may need to download some gigabyte crap package just to extract the few .h files you need, but chances are you'll just find the definition files hanging around the 'net.

There is a caveat: you need to have an idea what you are doing. If not, you'll learn, but your first led blinker may take more than with the GUI monster. There is some learning curve involved, simply because the lack of documentation and the fragmentation of community; "step by step" instructions for simple bare-metal no-bullshit no-manufacturer-specific-bloat-gui-shit flow are nonexistent, so you are on your own. The end result is great, trust me.