8-bit uC - is there even a point?

[PCB.Wiz]

IIRC, according to Hackaday, that's not the case anymore.

https://hackaday.com/2018/04/15/rip-dip-arm/

Interesting, and no real surprise.
That was a marketing departments idea of 'attention getting' and not a practical solution for almost anything.
Even in the engine room of the 8b MCU world, 8 pin controllers are fading, with a new QFN20 being often smaller and cheaper than last year's So8...

[nctnico]

Really, entire world? Then why new parts still appear no the market?

Semiconductor MCU revenue market forecast –millions of dollars

Nice stats, which show that the 4 & 16 bitters are the ones that stagnate, but the 8b & 32b are growing at actually very similar CAGR

These kind of stats say nothing about the number of designs which is a way more interesting number. 8 bit makes sense in very high volume if cost is an issue so just looking at dollar figures gives a very incomplete picture. You can't really see where the market is going from it.

[GeorgeOfTheJungle]

4.5x times the clock speed == 9.4x times faster:

[Siwastaja]

I guess my point was that claiming 32bit CPUs are "easier to use" than 8-bit chips is a bit ... misleading

Thanks! I think no one disagrees here; I haven't seen anyone claiming this, so it makes little sense to go against such a strawman any longer.

Of course the super simple 8-bitter is going to be easier to use and understand. It's so much smaller and less complex that it has to be easier.

But by how much? And what's the end result?

If you compare a $3 AVR to a $3 STM32, you'll see the latter has about:
10x larger number of peripherals, each of which has...
about 10x more features, hence complexity; and
then, the core/bus system/memory system as a whole performs about 20-100x faster for computational tasks.

You can use it to do a completely different league of things.

It's inevitable this is going to be hundreds of times more complex, internally. If the pricing was linear wrt some kind of "capability" index, the cost for the $3 STM32 would be $300. Or the cost for the $3 AVR should be $0.03.

So, people are likely to expect this $3 STM32 to be hundreds of times more difficult to use.

Now, coupled to the fact that people see cryptic code examples where blinking an LED and reading the ADC takes 500 lines of code (autogenerated or copypasted), while the same on AVR takes 15 lines, this reinforces the assumption. The problem is, it really takes about the same 15 lines of code to do the same on the said STM32, if done sanely! Actually, everything is surprisingly similar, there just are more features, which can be mostly ignored when not needed, but they give you a slight bit of extra mental overhead anyway.

Now, my point is, a modern typical ARM MCU hides the extra complexity fairly well, behind a sane structure. Some very vendor-specific and odd requirements from the 8-bit world simply disappear, and work out straight out of the box. Having everything clearly memory mapped without strange address space limitations and workaround is a prime example. This sane architecture offsets for the extra complexity elsewhere. The end result is surprisingly easy to grasp.

Of course, if you have done a lot of work on 8-bitters, you may be expecting the same "rules" of complexity are true on a 32-bit ARM, as well. For example, you seem to be expecting that the Core-coupled memory of STM32F334 is...

you're going to end up using a relatively complex-to-use vendor-specific feature to get the job done.

I can see where you are coming from with this assumption; if there was such an extra memory section on a PIC, it would (very likely) be relatively complex-to-use and at least very vendor-specific. But you are wrong. Said CCM is utterly trivial. Actually, it just works out of the box. It doesn't even need a single enable bit. No configuration. No custom tools, no knowledge of anything vendor specific. The memory address range is given in the manual and it just works there. Put your code to this address range, and it runs fast. Took literally less than 5 minutes for me to do this first time ever, worked on the first compilation. Completely agnostic to the workflow, libraries or compiler.

Of course, if you have never looked at how to use C and/or linker to define in which memory section your code and/or variables go to (or similar in the graphical settings of your IDE of choice), you need to learn that, but it just couldn't be easier, and definitely no vendor-specific anything. I use a custom linker script and my own startup code since it seems most flexible to me and I surely know what I get, but I guess there are easier point/click ways.

On AVR, for example, you can only run instructions from flash, and reading (const) data out of the flash requires specific instructions, and AFAIK no compiler can generate this code automatically; you use specific functions/macros to read access flash:
https://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
Concepts like this just don't exist on ARM. Complex things are of course difficult, but simple things tend to be simple, which isn't always the case on the 8-bit world!

[wraper]

These kind of stats say nothing about the number of designs which is a way more interesting number. 8 bit makes sense in very high volume if cost is an issue so just looking at dollar figures gives a very incomplete picture. You can't really see where the market is going from it.

You can at least assume that 8 bitters are sold/used in significantly higher numbers. Because amount shown is in money and 8 bitters are cheaper, especially super cheap end which go into mass produced devices.

[nctnico]

Clearly, it's ST's addition, and not the "ARM's option". The name is "CCM" for core-coupled memory instead of "TCM".

Thanks for the clarification and example part.
I guess my point was that claiming 32bit CPUs are "easier to use" than 8-bit chips is a bit ... misleading,

The other way around: claiming that 8bit CPUs are easier to use is equally misleading. The peripherals in a microcontroller are a different story and you can find examples of complicated peripherals regardless the number of bits in the CPU.

[MT]

What is the thing with DIP?

Mount DIP on one side and SMT between the legs on the other side! Chop the legs of a DIP to turn it into a SMT. Aviation and Space?

[mikeselectricstuff]

The other way around: claiming that 8bit CPUs are easier to use is equally misleading. The peripherals in a microcontroller are a different story and you can find examples of complicated peripherals regardless the number of bits in the CPU.

For a simple job, most 8-bits are easier than most larger MCUs, however once you get stuck into real work, the additional processing power, ROM/RAM space and peripheral functionality can make some jobs much easier on bigger parts, as there's less need to optimise/work around the limitations of 8-bit devices

[snarkysparky]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

[rx8pilot]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I somewhat arbitrarily chose Atmel a number of years ago. It was partly based on the size and depth of information available on the internet at the time. After getting setup and dialed in for most of the basic functions I needed - I had no real interest in learning another product family - even if it was 'better'

Now, I am at a place where I am ready for more power, better peripherals, better everything. I have emotionally prepared myself for a learning curve to get that.

[mikeselectricstuff]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

It has some nice features, especially the very flexible peripheral pin mapping, good at low power, but 3.3v only ( apart from one or two), and can be more expensive than some of the PIC32 range.

[NorthGuy]

For a simple job, most 8-bits are easier than most larger MCUs, however once you get stuck into real work, the additional processing power, ROM/RAM space and peripheral functionality can make some jobs much easier on bigger parts, as there's less need to optimise/work around the limitations of 8-bit devices

I think for simple job, they're all the same. Of course, there are some peculiarities, but, in general, the process is the same. You write a code in C. There's some basic initialization done by CRT, and then you start from there. You can debug, possibly simulate. Since the job is simple, you don't really worry about the resources - you get the biggest chip in your particular series (meaning everything is the same but lots of memory etc.) and use it for prototyping. Then you watch the resources and scale your chip down for the final board. Since it's the same process, you get similar development time.  Nothing is dramatically different no matter what chip you chose, unless you select something really stupid and unsuitable.

If you have demands for something particular, things change. Say, you want to simultaneously sample 8 ADC channels. So, you get a chip with ADC module which can cycle through your channels fast enough. Or, you need to communicate with something at 50 MHz SPI, so you select a chip which can do 50 MHz SPI. Or, you need 50 MTap/s FIR, so you select a DSP chip which can do this. Or, you need to do lots of fast floating point calculations (such as inverting matrices etc.), so you select an ARM chip with hardware floating point support. There's no other way. If you select an unsuitable chip it won't work, or will make your job much more complex that it needs to be.

However, if you don't have any particular needs, but select a big chip so that you could bloat more, or if you select an ARM chip because of the marketing buzz on the Internet, there's no merit in such decisions. Unfortunately, much too often that's how the decisions are made.

[NorthGuy]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I like them too. I don't understand the low popularity.

Although Microchip screwed up with PIC24 memory big time, so if you want above 32K of RAM, things get very messy. Which certainly limits the growth. Microchip are good at screwing up with memory. They managed to fragment even PIC32MZ.

[langwadt]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I somewhat arbitrarily chose Atmel a number of years ago. It was partly based on the size and depth of information available on the internet at the time. After getting setup and dialed in for most of the basic functions I needed - I had no real interest in learning another product family - even if it was 'better'

Now, I am at a place where I am ready for more power, better peripherals, better everything. I have emotionally prepared myself for a learning curve to get that.

and if you are going to upgrade and have a learning curve why go half way and pick 16bit from a single source when
you can go all the way to 32 bit and have numerous similar choices from many sources

[coppice]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I somewhat arbitrarily chose Atmel a number of years ago. It was partly based on the size and depth of information available on the internet at the time. After getting setup and dialed in for most of the basic functions I needed - I had no real interest in learning another product family - even if it was 'better'

Now, I am at a place where I am ready for more power, better peripherals, better everything. I have emotionally prepared myself for a learning curve to get that.

and if you are going to upgrade and have a learning curve why go half way and pick 16bit from a single source when
you can go all the way to 32 bit and have numerous similar choices from many sources

This currently a strong view amongst engineering managers, and it makes no sense. Nobody has to learn much about a new core, whether its 16 or 32 bits. They program in C, and only need to know a few simple things about the actual core. Its the peripherals that provide all the power, and take all the effort to learn. There is almost no commonality of peripherals from one silicon vendor to the next.

[nctnico]

I agree. You need to know very little about the CPU core itself. Just that it is 32 bit so you can use 32 bit numbers without a performance penalty. The biggest variation are the peripherals and these can make or break the efficiency of working with a particular microcontroller. My advice would be to really dig into datasheets, user manuals and errata sheets of at least half a dozen microcontroller from various vendors before making a final choice. It is what I did when I moved to ARM microcontrollers. Heck I even made some projects to see which one worked well in a real world situation (bringing the board up, debugging, programming tools, stability, etc). Choosing something which seems popular isn't a good idea because many people look at part cost only and not at engineering time.

[mikeselectricstuff]

There is almost no commonality of peripherals from one silicon vendor to the next.

CMSIS?
I'll get my coat....

[coppice]

There is almost no commonality of peripherals from one silicon vendor to the next.

CMSIS?
I'll get my coat....

Its a good joke, but it doesn't seem like people fall for it very often. Once you get past the "we use standard ARM cores" step, and the engineering manager is happy to listen to you extol the virtues of all the unique stuff in your peripherals they know the score. They know this will require their engineers take some serious time to be fully conversant with your peripheral set. They know CMSIS will only cut it for very basic uses, loosing access to all the clever stuff in your peripherals. They know whatever clever stuff they implement with your MCU will be completely non-portable. They still insist on that ARM core, though.

[mikeselectricstuff]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I somewhat arbitrarily chose Atmel a number of years ago. It was partly based on the size and depth of information available on the internet at the time. After getting setup and dialed in for most of the basic functions I needed - I had no real interest in learning another product family - even if it was 'better'

Now, I am at a place where I am ready for more power, better peripherals, better everything. I have emotionally prepared myself for a learning curve to get that.

and if you are going to upgrade and have a learning curve why go half way and pick 16bit from a single source when
you can go all the way to 32 bit and have numerous similar choices from many sources

There is almost no difference between the PIC24 and PIC32 range from the C programming user's point of view so it's not a big curve - many of the peripherals are the same or at least back-compatible supersets on the PIC32, so code written for the PIC24 will often need minimal changes to run on the 32

[JPortici]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

I somewhat arbitrarily chose Atmel a number of years ago. It was partly based on the size and depth of information available on the internet at the time. After getting setup and dialed in for most of the basic functions I needed - I had no real interest in learning another product family - even if it was 'better'

Now, I am at a place where I am ready for more power, better peripherals, better everything. I have emotionally prepared myself for a learning curve to get that.

and if you are going to upgrade and have a learning curve why go half way and pick 16bit from a single source when
you can go all the way to 32 bit and have numerous similar choices from many sources

because arm microcontroller from different manufacturers (sources) are notoriously pin-to-pin compatible 
or if you are talking about upgrade paths, microchip has offered pin-to-pin (or almost pin to pin) upgrades since the dawn of mankind

[JPortici]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

(Early) PIC24 had lot of quirks, even in newer models the peripherals are dumb, low MIPS anyway. PIC18 K42/K83 series have far better peripherals
if you want 16bit go dsPIC.

[technix]

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.

You can live without the library and you can be better off without it, but it will take some additional brain power to understand the registers. When vendors are given gigabytes of address space to place control registers, they tend to get lazy and verbose.

[coppice]

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.

You can live without the library and you can be better off without it, but it will take some additional brain power to understand the registers. When vendors are given gigabytes of address space to place control registers, they tend to get lazy and verbose.

It seldom takes much brain power. It takes time. Often lots of it. Often patching together information from various sources, because no one source is complete. Often using the source code for the crappy library, because only the programmer of that library ever figured out some details that are not in the documentation.

[Howardlong]

PIC24 series is every bit as easy to use as 8 bit but you get vastly better chip.

I don't understand the lack of love for that series.

(Early) PIC24 had lot of quirks, even in newer models the peripherals are dumb, low MIPS anyway. PIC18 K42/K83 series have far better peripherals
if you want 16bit go dsPIC.

I think it depends on application. I'm quite a fan of the PIC24FxxKA/KL/KM devices, with wide supply voltage ranges, low power consumption and plenty of peripherals that make them well suited to small battery powered devices. You can forego voltage regulators for example in single Li cell applications.

dsPIC33 are all 3.3v parts and not very low power.

For real low power in energy harvesting, the newer PIC16(L)F1xxxx and some other manufacturers' devices fare even better in current consumption than PIC24FxxKA/KL/KM in most representative like for like comparisons, but those PIC24Fs have significantly more processing oomph than PIC16 which may be beneficial in a given application.

Sometimes the peripherals and features are a decision maker: I switched from using a PIC24F16KM202 down to a PIC16F1619 because of the PIC16F161X's math accelerator/PID controller peripheral and higher current FET driver pins, producing an even cheaper design in the process, but it was a close run thing.

As always, the devil's in the details!

[technix]

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.

You can live without the library and you can be better off without it, but it will take some additional brain power to understand the registers. When vendors are given gigabytes of address space to place control registers, they tend to get lazy and verbose.

It seldom takes much brain power. It takes time. Often lots of it. Often patching together information from various sources, because no one source is complete. Often using the source code for the crappy library, because only the programmer of that library ever figured out some details that are not in the documentation.

What I mean is reading through the chip’s manual and have a general grasp on what goes where and does what, and how the modules are associated with each other. This will take some brainpower to build up the dependency map. When coming to individual peripherals spend some time poking around it to figure out what does what, and with those understandings you can start writing your own drivers.

I had the unfortunate of having a project almost get killed by the sheer bloat of STM32CubeMX. Overcame it by skipping the libraries and cook up my own drivers.