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.

[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.

[Whales]

Thankyou for the advice, I'll give it a go.

Hearing that I mainly just need a per-device magic header makes me happy.  Entry points and everything else don't change per core design, or are they also something hacked into the header?

[SiliconWizard]

Thankyou for the advice, I'll give it a go.

Hearing that I mainly just need a per-device magic header makes me happy.  Entry points and everything else don't change per core design, or are they also something hacked into the header?

You usually also need:

• a proper linker script corresponding to the device you're using, defining memory mapping, entry points...
• the right compiler options - at least defining the correct target: ARM has many different variants

[brucehoult]

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.)

However 8 bit processors often need more instructions and more clock cycles to get your computation done than a 32 bit processor. The 32 bit processor can finish and go to a low power mode sooner, even at the same clock speed.

AVRs are good if you only have 8 bit quantities. As soon as you need even 16 bit integers you start to be better of with a Cortex M0 or SiFive E20.

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

[mikeselectricstuff]

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?

PIC32.
Install MPLABX and XC32 and it just works. As a bonus it also just works for 16 and 8 bit parts if you install XC16 and XC8 respectively.

Just #include <xc.h> and it does everything based on the part selected for the project

[brucehoult]

IoT and wearables pose a unique requirement: nanoamp sleeping while retaining RAM content. That's the place for 8-bitters and FRAM MSP430s.

A week ago Huami (part of Xiaomi) announced a new generation of smart watch (with heart irregularity detection and ECG) and a sports/health monitoring band, and the "Huangshan No. 1" AI wearable device chip which uses a SiFive "E31" 32 bit RISC-V processor running at 240 MHz with 608 KB SRAM. Huami says the processor has 38% better efficiency than a Cortex M4.

So they, at least, don't think wearables should be restricted to 8 or 16 bits.

https://riscv.org/2018/09/engadget-article-huamis-new-watch-and-bracelet-are-coming/

[glarsson]

And the Apple watch (a typical wearable) has a 64 bit dual core ARM processor.

[sokoloff]

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

I went to a few distributors' websites and priced out the cheapest 1K quantity of 8-bit AVRs and the cheapest 1K quantity of M0+ chips I could find to get the $0.30 and $0.90 figures. Do you have reference data to contradict those figures?

[NorthGuy]

However 8 bit processors often need more instructions and more clock cycles to get your computation done than a 32 bit processor. The 32 bit processor can finish and go to a low power mode sooner, even at the same clock speed.

Often you don't need any arithmetic at all, especially on critical paths. So, it's absolutely of no consequence whether your chip is 8-bit or 32-bit.

Of course, all things being equal, 32-bit is better than 8-bit, but in the real world things are not equal. The architectures which lost their battle in big computers already (ARM, MIPS) have been dragged into the embedded world, where they're even less suitable. Embedded world needs direct access commands, predictability, low latency. It doesn't need long pipelines and caches.

Google is a huge marketing force, so ARM will get more and more popular especially when light bulbs need 2048-bit RSA and AES256 encryption. And if that is not enough, they're ready to convince the world that you need 4096-bit RSA and so on, with no limits. But there's no reason to pretend that there's any sense in this.

[nctnico]

However 8 bit processors often need more instructions and more clock cycles to get your computation done than a 32 bit processor. The 32 bit processor can finish and go to a low power mode sooner, even at the same clock speed.

Often you don't need any arithmetic at all, especially on critical paths. So, it's absolutely of no consequence whether your chip is 8-bit or 32-bit.

Of course, all things being equal, 32-bit is better than 8-bit, but in the real world things are not equal. The architectures which lost their battle in big computers already (ARM, MIPS) have been dragged into the embedded world, where they're even less suitable. Embedded world needs direct access commands, predictability, low latency. It doesn't need long pipelines and caches.

Nonsense. Embedded applications grow larger and larger. Predictability and latency issues are solved by using buffers and DMA nowadays. More speed and more memory means you can make more complex software quicker with less bugs. And there are many areas where having speed just saves the day. Think about signal processing. Over the years I've created quite a few ARM microcontroller based circuits which do some hefty signal processing. Back in the old days you'd need a DSP for that and assembly programming.

[nctnico]

So they, at least, don't think wearables should be restricted to 8 or 16 bits.

Not essentially, but doesn't mean 8-bitters have no place.
As a system manager chip (power sequencing, voltage rail monitoring, etc.), 8-bitters are still better.
They can stay alive forever without consuming any meaningful current.

TI's MSP430 series is pretty good at that as well. Actually a more modern process is likely to perform better compared to an architecture (8051 for example) which wasn't designed for low power. Less bits doesn't alway mean less power. Another thing to look for when looking at low power devices is the start-up time for the oscillators. A redesign of a PIC based product using an MSP430 microcontroller ended up consuming nearly 3 times less power.

[wraper]

TI's MSP430 series is pretty good at that as well. Actually a more modern process is likely to perform better compared to an architecture (8051 for example) which wasn't designed for low power.

Process != architecture.
https://www.silabs.com/products/mcu/8-bit/efm8-sleepy-bee

Lowest MCU sleep current with supply brownout (50 nA)
Lowest MCU active current (150 μA / MHz at 24.5 MHz)
Lowest MCU wake on touch average current (< 1 μA)
Lowest sleep current using internal RTC and supply brownout (< 300 nA)
Ultra-fast wake up for digital and analog peripherals (< 2 μs)
Integrated LDO to maintain ultra-low active current at all voltages
Up to 14 capacitive sense channels

And it's 8051

[NorthGuy]

Over the years I've created quite a few ARM microcontroller based circuits which do some hefty signal processing. Back in the old days you'd need a DSP for that and assembly programming.

DSP?

$5 dsPIC33CH can do FIR at a rate of 100MTap/s (totally predictable, no reliance on cache or bus congestion)
$15 smallest Spartan-7 FPGA can do FIR at a rate of $4GTap/s (totally predictable)

Where does your ARM DSP fall in this spectrum?

[Mr. Scram]

And the Apple watch (a typical wearable) has a 64 bit dual core ARM processor.

I don't think the Apple Watch is a typical wearable. It's probably the top end of wearables, with most applications requiring a lot less power.

[Mr. Scram]

TI's MSP430 series is pretty good at that as well. Actually a more modern process is likely to perform better compared to an architecture (8051 for example) which wasn't designed for low power. Less bits doesn't alway mean less power. Another thing to look for when looking at low power devices is the start-up time for the oscillators. A redesign of a PIC based product using an MSP430 microcontroller ended up consuming nearly 3 times less power.

I keep seeing the MSP430 in relation to low power. It's it really that much better than most other solutions?

[nctnico]

Over the years I've created quite a few ARM microcontroller based circuits which do some hefty signal processing. Back in the old days you'd need a DSP for that and assembly programming.

DSP?

$5 dsPIC33CH can do FIR at a rate of 100MTap/s (totally predictable, no reliance on cache or bus congestion)
$15 smallest Spartan-7 FPGA can do FIR at a rate of $4GTap/s (totally predictable)

Where does your ARM DSP fall in this spectrum?

Wherever it is enough and ARM can do quite a lot. One of the projects for example involved an acoustic echo canceller which did part of the calculations in soft floating point; I used a small 70MHz ARM microcontroller for that. Buffering inside the serial codec interface took care of any latency issues so no worries there.

[EEVblog]

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?

They are used in the hundreds of millions. It's just that this forum is essentially dominated by hobbyists (even if they are engineering professionals, they mostly are thinking in terms of personal projects).
HCS08 and the like have never really been taken up by the hobbyist crowd which is why you never hear of them, they are used in every professional whitegood and automotive market etc.
So go on any forum or blog or open source hardware site and you'll only find PIC, ATMEL, and ARM's, the ones that have been marketed as "hobbyist friendly".

[EEVblog]

I keep seeing the MSP430 in relation to low power. It's it really that much better than most other solutions?

Not really. It's just that it was one of the first ultra low power micros and hence became the defacto standard.

[EEVblog]

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

I went to a few distributors' websites and priced out the cheapest 1K quantity of 8-bit AVRs and the cheapest 1K quantity of M0+ chips I could find to get the $0.30 and $0.90 figures. Do you have reference data to contradict those figures?

And it's not just big company commercial application. Countless one-man-bands are doing Kickstarters these days and it's trivial to sell 1000 units in a kickstarter. That 70 cents extra on the BOM cost really matters at even 1000qty. And ordering your parts pre-programmed can be a big deal too. Also, it's not uncommon to have a little cheap pre-programmed 8bit 5 pin micro in a circuit just to do one small dedicated job, rather than have the main processor care about doing that.

[FrankBuss]

And it's not just big company commercial application. Countless one-man-bands are doing Kickstarters these days and it's trivial to sell 1000 units in a kickstarter. That 70 cents extra on the BOM cost really matters at even 1000qty. And ordering your parts pre-programmed can be a big deal too. Also, it's not uncommon to have a little cheap pre-programmed 8bit 5 pin micro in a circuit just to do one small dedicated job, rather than have the main processor care about doing that.

Microchip Direct offers a flash service, which is reasonable cheap (at least for small parts, but I guess for larger parts it doesn't cost much more) and there is no lower limit for the number of parts, you could just order 10 pre-programmed chips (but shipping costs from Microship Direct would be higher than buying a PICKit from eBay ). E.g. for a client project I'm using a small PIC for the reset circuit, replacing a special dedicated >$1 reset IC, and additionally using it  for controlling the main power of the circuit in sleep mode, which all fits in one of these small, ultra low power PICs, and programming costs only a few cents:



8 bit CPUs are perfect for such applications, because they are still cheaper than 32 bit CPUs (maybe this might change in future when there are more RISC5 CPUs out there, because no license cost) and they need less power.

But I don't think it is important, even for Kickstarter projects with 1,000 units. Sure, you might save $1,000 if you use an 8 bit MCU instead of a 32 bit MCU, but then you might need some additional days development time, trying to make it run with the less powerful MCU, and this would be worth more than what you save at the usual engineering rate. And this is not only because you have to do e.g. fixed point math instead of using a hardware floating point unit (you can get MCUs with hardware FPU for as cheap as EUR 2.55 e.g. for the ATSAMD51G18A nowadays). The peripherals of modern 32 MCUs (usually) are much better as well. For example last time I checked the ADC of the Silabs Giant Gecko series, and the internal band gap reference is factory calibrated and you can do hardware oversampling with it, resulting in 16 bit effective resolution. I could measure with better than 10 mV accuracy and better than 1 mV resolution over the full range from 0 V to 3.3 V out of the box, and with very few lines of code using the HAL. So this alone might save some additional external components and calibration setup time for some applications.

Of course, if you develop a dice with 6 LEDs and one battery, use an 8 bit MCU. Development time is the same, but the MCU is cheaper and needs less power. And numbers change again, if you plan to sell millions of it.

[Mr. Scram]

And it's not just big company commercial application. Countless one-man-bands are doing Kickstarters these days and it's trivial to sell 1000 units in a kickstarter. That 70 cents extra on the BOM cost really matters at even 1000qty. And ordering your parts pre-programmed can be a big deal too. Also, it's not uncommon to have a little cheap pre-programmed 8bit 5 pin micro in a circuit just to do one small dedicated job, rather than have the main processor care about doing that.

Even if it's those 70 cents, that's 700 bucks. Depending on the circumstances I could see that easily being offset by a shorter development cycle or something similar. Or not, of course.

[PCB.Wiz]

.... E.g. for a client project I'm using a small PIC for the reset circuit, replacing a special dedicated >$1 reset IC, and additionally using it  for controlling the main power of the circuit in sleep mode, which all fits in one of these small, ultra low power PICs, and programming costs only a few cents:

 Yes, this nicely illustrates there are multiple trends today.
32b MCUs are falling in price, so useful ones are sub $1, but as this example shows, 8b MCUs are also busy replacing dedicated RST/DAC/WatchDOG/Supervisor parts, and in some cases, even displacing simple wiring (a 25c 8b MCU MCU costs less than a cable wire pair, less than a DIP sw, less than a microswitch... )

 All that means it is not so much a question of 32b or 8bit, but many systems are shipping with both 32b and 8b MCUs in them.

[james_s]

Probably packaging to some degree, or it might just be people choosing arbitrary values. No matter what pricing algorithm you choose, you will likely have situations where buying a few more parts turns out to be cheaper than buying fewer.

[Mr. Scram]

I don't see how making the price structure more complicated makes things better. This is immediately obvious, even though there are a few "blind spots".

It should be noted that there are examples of taxes being structured the exact same way. In that case there's something to be said for a more fair system. In this case, who cares?

[brucehoult]

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

I went to a few distributors' websites and priced out the cheapest 1K quantity of 8-bit AVRs and the cheapest 1K quantity of M0+ chips I could find to get the $0.30 and $0.90 figures. Do you have reference data to contradict those figures?

Any fab price list. The cost to process a wafer in a given process is fixed, therefore the more chips you can get in a reticule the cheaper they are. Effectively the cost per square mm of chip is fixed. For a given number of pads on the chip to be connected to a given number of pins in the same package the cost does not depend on what circuitry is present on the chip.

The figures you are referring to are retail prices. Those depend at least as much on perceived value and what the manufacturers think you'll pay as they do on the actual cost.

[brucehoult]

However 8 bit processors often need more instructions and more clock cycles to get your computation done than a 32 bit processor. The 32 bit processor can finish and go to a low power mode sooner, even at the same clock speed.

Often you don't need any arithmetic at all, especially on critical paths. So, it's absolutely of no consequence whether your chip is 8-bit or 32-bit.

Of course, all things being equal, 32-bit is better than 8-bit, but in the real world things are not equal. The architectures which lost their battle in big computers already (ARM, MIPS) have been dragged into the embedded world, where they're even less suitable. Embedded world needs direct access commands, predictability, low latency. It doesn't need long pipelines and caches.

Long pipelines and caches have nothing to do with the ISA.

SiFive's "E20" 32 bit RISC-V core has no caches, just instruction and data SRAMs and runs at 1 clock cycle for all instructions except taken branches, which take 2 cycles. That's pretty predictable. The Cortex M0 is similar.

[NorthGuy]

Long pipelines and caches have nothing to do with the ISA.

If you want to implement your ISA in silicon, they certainly do, or you will end up with turtle-speed ISA.

There are different ways of building processors. You can do many things in parallel, such as

Code: [Select]

MAC  W4*W5, A, [W8]+=6, W4, [W10]+=2, W5
which is an actual single-cycle instruction for dsPIC, which multiples W4 by W5, adds the result to accumulator, fethes W4 from [W8], fetches W5 from [W10] and then increments W8 by 6 and W10 by 2. In addition, such instructions can be looped without any overhead, and also W8 may be configured to wrap at any point.

Another approach to CPU design is to do very little things during a single command - such as in RISC processors, e.g. ARM, MIPS. I don't know much about RISC-V, but looks like it's of the same variety too. How many instructions would you need on ARM to replicate this behaviour? A dozen? Perhaps more?

Of course, RISC processors will fail miserably when compared to "parallel" processors on a cycle-by-cycle basis. To keep up they need to run the clock at much faster rate. Hence, you do need pipelinig, or the silicon simply won't keep up with the clock. If you want to multiply 32-bit numbers, the pipeline will be rather long.

The next thing which comes with a fast clock is cache. You simply cannot fetch things from RAM (yet alone from flash) fast enough. Hence pre-fetchers and caches. Cannot have a fast clock without them.

How does it mix with the embedded tasks? Not very well. You need to react to something fast and quickly jump to your ISR routine, but then you need to fill the pre-fetchers and caches, then you need to fill the pipeline, save the context. All this takes long time causing horrible latencies.

However, ARM marketers have an answer to this too: "we'll do everything with peripheral modules and DMA". Now even more problems are piled on the poor ARM processor, because DMA now competes with the processor for the data bus making for even longer and rather unpredictable latencies. And, of course, if you do everything with peripherals and DMA, which by-pass the CPU completely, who cares what kind of processor you have?

SiFive's "E20" 32 bit RISC-V core has no caches, just instruction and data SRAMs and runs at 1 clock cycle for all instructions except taken branches, which take 2 cycles. That's pretty predictable. The Cortex M0 is similar.

Or PIC32MM with MIPS. But these are not high performance by any means.

[FrankBuss]

BTW, instead of a simple microcontroller, these days you can get a Linux capable CPU in a TQFP package for $1:

https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solderable-processor/

If you pay $3.25 for the V3S, you get 64 MB integrated DRAM and it runs at 1.2 GHz, has video input/output, H.264 encoders/decoders, ethernet, USB etc.:

http://linux-sunxi.org/V3s

I guess this will cause some trouble for the other CPU manufacturers. For example the STM32F439BIT6 costs EUR 10 in higher quantities, but has only 256 kB RAM and runs at 180 MHz. Why would anyone buy such a CPU anymore?

Many years ago I built diskless stations, which booted Linux over ethernet (with these old BNC ethernet cards with boot sockets, and burning my own EPROM chips for it) and then running an X11 server (in X11 terminology, the "server" is just the program which receives the drawing instructions to display it). There was one server PC which ran all the programs, for a dozen stations. Each station needed only 8 MB RAM. With 64 MB you could fly to the moon.

[Mr. Scram]

BTW, instead of a simple microcontroller, these days you can get a Linux capable CPU in a TQFP package for $1:

https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solderable-processor/

If you pay $3.25 for the V3S, you get 64 MB integrated DRAM and it runs at 1.2 GHz, has video input/output, H.264 encoders/decoders, ethernet, USB etc.:

http://linux-sunxi.org/V3s

I guess this will cause some trouble for the other CPU manufacturers. For example the STM32F439BIT6 costs EUR 10 in higher quantities, but has only 256 kB RAM and runs at 180 MHz. Why would anyone buy such a CPU anymore?

Many years ago I built diskless stations, which booted Linux over ethernet (with these old BNC ethernet cards with boot sockets, and burning my own EPROM chips for it) and then running an X11 server (in X11 terminology, the "server" is just the program which receives the drawing instructions to display it). There was one server PC which ran all the programs, for a dozen stations. Each station needed only 8 MB RAM. With 64 MB you could fly to the moon.

I understand the desire for faster hardware, but is a full-blown Linux system really a good upgrade for the average AVR use case? Adding many abstraction layers isn't necessarily helping, which is why 8 bitters seem to be still viable.

[FrankBuss]

I'm sure you can run it bare-metal as well.

[rjp]

I'm sure you can run it bare-metal as well.

their is very little overlap between 8bit micros and application processors running linux... maybe the big ARM M4 and M7 micros have a more dubious argument.

you cant have a linux machine automatically boot on interrupt, do 1/4 of  a seconds work and then go back to nano amp sleep and thusly make a watch battery last for months.

imagine a tv remote control that took 1 minute to bootup on every button press, or needed charging every couple of hours

[Mr. Scram]

I'm sure you can run it bare-metal as well.

Is there a convenient, accessible and well documented IDE though?

[Kjelt]

Also, it's not uncommon to have a little cheap pre-programmed 8bit 5 pin micro in a circuit just to do one small dedicated job, rather than have the main processor care about doing that.

Indeed first a jellybean oldschool ttl/cmos solution takes up way more pcbspace than a single small micro, then it is more flexible.
Then there are these niche applications where a small 8 bit uC with AD can shine, like acting as an intelligent local sensor monitoring some or many local physical properties. Look at modern cars for example they contain more than a 100 microcontrollers each performing their specific function and reporting back to whomever is interested.

[Siwastaja]

I guess this will cause some trouble for the other CPU manufacturers. For example the STM32F439BIT6 costs EUR 10 in higher quantities, but has only 256 kB RAM and runs at 180 MHz. Why would anyone buy such a CPU anymore?

This shows a fundamental misunderstanding.

ST is not a "CPU manufacturer". STM32F439BIT6 is not a CPU. It's an MCU. Nobody buys it for its CPU core. You buy it if it offers the right combination of core, peripherals, documentation and tools to do the job. Especially the peripherals. For a typical MCU job, 256 kB RAM is just huge, and the core frequency is unimportant. Even if it processes a lot of data, the point is to use DMA to do it.

Modern ARM MCUs tend to offer advanced and plentiful peripherals, compared to old 8-bitters. This is a major argument for using them, IME. Not the core. The core "just is" what it is, and I have been happy with ARM - would be happy with many others, as well. It's unimportant.

ARM is acceptable because it hides its "silicon bloat" fairly well. It just works in a simple and understandable manner. But in a typical "modern ARM microcontroller", the ARM core is not the best or most interesting part, no way!

My current project involves STM32H743. I use it because I need all of this:
* Digital camera interface (80MHz synchronous parallel bus input with FIFO and DMA)
* HRTIM module for accurate, fast PWMs for software defined DC/DC
* Two comparators
* Two 3-phase motor drives
* All three ADCs are really needed
* Both two DACs - one creates control signals for DC/DC, other plays audio
* five SPIs
* A lot of DMA channels to serve all this.
.... AND a fast core, which can run without caches, in a predictable manner, completely from core-coupled ITCM memory, with most real-time data in core-coupled DTCM memory.

... in a single project.

It's about the big picture. The core itself is fairly unimportant, although in this case, I also need the processing power - for which, the 64-bit data bus, 64-bit memories and fairly usable set of 64-bit instructions as well as SIMD set are good to have. This being said, in many of my projects, this processing power is secondary or completely unimportant.

The cache point is quite moot. Most ARM MCUs that are high-end enough to include cache, also include core-coupled memories, typically large enough to fit all timing critical code and data (at least when you write it sanely and not overbloated), and run caches disabled. In fact, I have never enabled caches in my projects. Non-critical slow parts run off the flash directly, else from ITCM. But I guess caches are important when running a lot of bloated stuff which just doesn't fit in core-coupled memories - and when you have too many abstaction layers inbetween so that you can no longer take advantage of the heterogenous structure of a modern MCU, but need to treat everything as a single big "blob" called "CPU", measured on megabytes and megahertz. I just don't work like that with MCUs. I use as many of the features an MCU can offer, in an efficient way, and then I use an integrated single-board computer with enough resources when I want to run linux to do "computer tasks" (requiring gigabytes of memory, Internet connection, a lot of calculation on non-realtime data, etc. - in an abstract way where I don't need to think about the hardware too much).

Coming back to your "why would anyone" question. People still design in those 8-bitters and run them at 1MHz, with a few kilobytes of memory, in masses, because they are enough for so many tasks. So why would 256K and 180MHz be "too little" for anyone?

[coppice]

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

I went to a few distributors' websites and priced out the cheapest 1K quantity of 8-bit AVRs and the cheapest 1K quantity of M0+ chips I could find to get the $0.30 and $0.90 figures. Do you have reference data to contradict those figures?

At 1k quantities quoted prices are almost random numbers. Even 100k doesn't generally get you close to serious volume pricing, and you need to negotiate serious pricing. Its never quoted in price lists. Some devices can be obtained in small quantities for a modest premium over a negotiated volume price. Others are several times the volume price.

There are lots of sub 50 cent M0+ chips around now. The price ratio between an AVR chip and an M0+ one can vary a lot with the complexity of the chip, and its pin count. Lots of pins and a low complexity is a big problem for fine geometry M0+ MCUs, as the chip size ends up being defined by the I/O ring needed to fit in all the pin pads. The larger transistors in the older processes used for things like the AVR family means a design is rarely limited by the I/O ring. If you see something like an M0 part with 1k of flash, its going to use a die with a lot of flash, where most of the flash was disabled at test time. An AVR part with 1k of flash might well have only 1k on the die.

[FrankBuss]

Coming back to your "why would anyone" question. People still design in those 8-bitters and run them at 1MHz, with a few kilobytes of memory, in masses, because they are enough for so many tasks. So why would 256K and 180MHz be "too little" for anyone?

There are many applications where it needs to be faster and where you need more memory, for example for video IO (this chip has an ethernet interface and a camera input, so probably could be used as a web cam), or polyphonic realtime audio synthesis with effects (reverb needs lots of memory). And the Allwinner V3s is not just a core, it has some useful peripherals as well, see the datasheet, like DMA, PWM, SPI, I2C, UART, audio codec etc. So if you don't miss a peripheral for your application, it could be a cheap replacement for the higher priced STM32 series chips, but with more RAM and much faster. It can run slower as well, probably using not much more power then as a STM32 running at 180 MHz.

[legacy]

Many years ago I built diskless stations, which booted Linux over ethernet (with these old BNC ethernet cards with boot sockets, and burning my own EPROM chips for it) and then running an X11 server (in X11 terminology, the "server" is just the program which receives the drawing instructions to display it). There was one server PC which ran all the programs, for a dozen stations. Each station needed only 8 MB RAM. With 64 MB you could fly to the moon.

Let me understand, these ethernet cards come with a sort of PC-BIOS extension, and it's cool that every IBM-PC's BIOS scans these areas at the bootup and if it finds an extension (with a valid checksum) it jumps into it

I know the maximal size of these Ethernet card's ROM is 512Kbyte. Right? What did you put inside that ROM? sort of net-bootloader? To load the Linux kernel and the 'ram-rootfs' from the Net? Hence inside the 'ram rootfs' image, did you had X11-server with xterminal, fonts, and WindowsManager and miscellanea?

Here I am doing these things with PowerPC boards, but ... I need 32Mbyte of ram just for the kernel (5Mbyte stripped) and rootfs. X11 is now as big as a dead elephant, and it doesn't matter if you try to strip it by forcing "nano-X", these tricks don't pay in term of the Mbyte you need.

[legacy]

I also need the processing power - for which, the 64-bit data bus, 64-bit memories and fairly usable set of 64-bit instructions as well as SIMD set are good to have

why 64-bit instructions?

[Siwastaja]

There are many applications where it needs to be faster and where you need more memory, for example for video IO (this chip has an ethernet interface and a camera input, so probably could be used as a web cam), or polyphonic realtime audio synthesis with effects (reverb needs lots of memory). And the Allwinner V3s is not just a core, it has some useful peripherals as well, see the datasheet, like DMA, PWM, SPI, I2C, UART, audio codec etc. So if you don't miss a peripheral for your application, it could be a cheap replacement for the higher priced STM32 series chips, but with more RAM and much faster. It can run slower as well, probably using not much more power then as a STM32 running at 180 MHz.

I can see several points that make this no-go as a replacement for an MCU:
- No fast on-chip SRAM for predictable latency routines
- Practically no PWM - only two very basic channels, no three-phase control
- Not too many timers
- Only one SPI(!)
- No QSPI
- No ADC
- No CAN bus
- No analog comparators
...

I'm sorry but this is something that simply cannot replace an MCU in an application where an MCU is typically used. This has fewer peripherals than an absolute-lowest-cost 8-bitter - which is kind of the point.

It's a video codec CPU, not a microcontroller.

But you gave a good example what's the distinction between modern application processors and modern MCUs.

[legacy]

If you want to multiply 32-bit numbers, the pipeline will be rather long

each stage in the pipeline evolves in 1 clock cycle; multiplications, MACs, divisions, usually take more than one cycle, hence they are exceptions for which the pipeline needs to be stalled during their computation, and this "wait until ready" is usually implemented with bubbling/NOP injection

[Siwastaja]

I also need the processing power - for which, the 64-bit data bus, 64-bit memories and fairly usable set of 64-bit instructions as well as SIMD set are good to have

why 64-bit instructions?

"64-bit instructions" as: instructions that work with 64-bit data, in or out. Such SIMD instructions are numerous in the Cortex M7 instruction set. Not comparable to modern DSP instruction sets, but not to be ignored, either. Similarly, load and store instructions for 64 bit data exist, taking advantage of the 64-bit memory bus to the core-coupled SRAM. For example, in my current project, I need to load four (say, a,b,c, and d) 16-bit values next to each other in memory, and calculate c-a and d-b. I bet this will be faster on M7 with 64-bit memory bus, compared to, say, an M4 with a 32-bit bus.

[FrankBuss]

Many years ago I built diskless stations, which booted Linux over ethernet (with these old BNC ethernet cards with boot sockets, and burning my own EPROM chips for it) and then running an X11 server (in X11 terminology, the "server" is just the program which receives the drawing instructions to display it). There was one server PC which ran all the programs, for a dozen stations. Each station needed only 8 MB RAM. With 64 MB you could fly to the moon.

Let me understand, these ethernet cards come with a sort of PC-BIOS extension, and it's cool that every IBM-PC's BIOS scans these areas at the bootup and if it finds an extension (with a valid checksum) it jumps into it

I know the maximal size of these Ethernet card's ROM is 512Kbyte. Right? What did you put inside that ROM? sort of net-bootloader? To load the Linux kernel and the 'ram-rootfs' from the Net? Hence inside the 'ram rootfs' image, did you had X11-server with xterminal, fonts, and WindowsManager and miscellanea?

Here I am doing these things with PowerPC boards, but ... I need 32Mbyte of ram just for the kernel (5Mbyte stripped) and rootfs. X11 is now as big as a dead elephant, and it doesn't matter if you try to strip it by forcing "nano-X", these tricks don't pay in term of the Mbyte you need.

I don't remember the details, but I think the EPROM was smaller. There was a website where you could create the EPROM file. It loaded the Linux kernel by TFTP, then mounting a system partition with all programs read-only over NFS and a user partition over NFS.

For an embedded system with some (big) ARM microcontroller I did something similar for easier developing: first was u-boot loaded from flash. Then u-boot loaded the Linux kernel over TFTP and then mounting the system partition over NFS and Linux was started. This could be changed with the boot command in u-boot, loading from the (external) flash and mounting the system from the flash.

5 MB sounds a bit much for the Linux kernel. Did you disable everything you don't need in the Linux menuconfig? You can fit a full Linux kernel and hundreds of programs on a 1.44 MB floppy disk, at least with an older version of Linux:

http://www.linfo.org/mulinux

X11 shouldn't be that big as well. When I used it, there was no xterminal or other programs on the clients. It was just the X11 server (the "X" program), started over network from the NFS mounted filesystem, and all the other programs ran on a server PC, using the X11 server just for display. But I think I used a lightweight window manager like twm as well. Most of the time only one custom application was running on each station, written in Tcl/Tk.

[xani]

TI's MSP430 series is pretty good at that as well. Actually a more modern process is likely to perform better compared to an architecture (8051 for example) which wasn't designed for low power.

Process != architecture.
https://www.silabs.com/products/mcu/8-bit/efm8-sleepy-bee

Lowest MCU sleep current with supply brownout (50 nA)
Lowest MCU active current (150 μA / MHz at 24.5 MHz)
Lowest MCU wake on touch average current (< 1 μA)
Lowest sleep current using internal RTC and supply brownout (< 300 nA)
Ultra-fast wake up for digital and analog peripherals (< 2 μs)
Integrated LDO to maintain ultra-low active current at all voltages
Up to 14 capacitive sense channels

And it's 8051

At least compare to the equivalents, like their Cortex M0+ chips. Zero gecko for example:
https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko

    20 nA shutoff mode (0.4 µA with RTC)
    0.5 µA stop mode, including power-on-reset, brown-out detector, RAM and CPU retention
    0.9 µA deep sleep mode, including RTC with 32.768 kHz oscillator, power-on-reset, brown-out detector, RAM and CPU retention
    48 µA/MHz sleep mode
    114 µA/MHz run mode with code executed from flash


Like yes, the 8 bit part will in many cases eat less power, but in some cases the difference is tiny (or even in favour of 32 bit parts), and you usually gain a lot more flexibility for it

[MT]

I'm sure you can run it bare-metal as well.

By reading up a bit on Allwinner here and there i get the impression they are as stuck as RassberyPi when it comes to
do bare metal i.e plain C with nonexistent simple tools with no head scratch and months of investigations on why things dont work etc non dependency on other folks "hacks".etc

I dont understand why i have to learn Linux just to do embedded crap projects,  i dont want to add pain, i want to "reduce pains"!The whole point of doing MCU /SOC should be to reduce project development times but for past 10 years at least everything goes in the opposite direction, everything is ended up more complex.

Allwinner is billion company yet they seams to depend on others IP thats closed just like Rasperry.

[wraper]

At least compare to the equivalents, like their Cortex M0+ chips. Zero gecko for example:
https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko

You missed the point and they are not so much different anyway. And compared with modern MCUs in average both have very low consumption. I never said that their 8051 offering is the lowest power consumption MCU ever.

[james_s]

There are many applications where it needs to be faster and where you need more memory, for example for video IO (this chip has an ethernet interface and a camera input, so probably could be used as a web cam), or polyphonic realtime audio synthesis with effects (reverb needs lots of memory). And the Allwinner V3s is not just a core, it has some useful peripherals as well, see the datasheet, like DMA, PWM, SPI, I2C, UART, audio codec etc. So if you don't miss a peripheral for your application, it could be a cheap replacement for the higher priced STM32 series chips, but with more RAM and much faster. It can run slower as well, probably using not much more power then as a STM32 running at 180 MHz.

This is not the sort of thing that microcontrollers are typically used for. Do you really want to wait for Linux to boot and think about crashes, memory leaks, hacks, etc in your microwave oven, dishwasher, clothes washer and dryer, tv remote, alarm clock, etc? Linux SOCs and microcontrollers are two entirely different fields with some small bit of overlap in the middle. The strength of the microcontroller is in the peripherals, and the simplicity. There is effectively no boot time, there is no operating system, everything happens in real time and can be tweaked down to individual clock cycles. You can get microcontrollers in tiny packages with only a few pins, you can get ones that consume miniscule amounts of power. It is absolutely silly to suggest a Linux SOC for microcontroller applications, even if the Linux route was cheaper the end result would be inferior for the sort of applications where microcontrollers are typically used.

[kaevee]

I don't remember the details, but I think the EPROM was smaller. There was a website where you could create the EPROM file. It loaded the Linux kernel by TFTP, then mounting a system partition with all programs read-only over NFS and a user partition over NFS.

Probably you were using Etherboot http://netboot.sourceforge.net/english/index.shtml
 or
Netboot http://netboot.sourceforge.net/english/index.shtml

I used to use a Etherboot ROM in bootable floppy(did not have access to Eprom programmer) in late nineties for network booting Linux in a college lab.

[nctnico]

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.

If you have a chip with only a simple MCU and a small amount of SRAM on it then the area and therefore cost of the actual chip in modern smallish processes is completely dominated by the pads used to connect to the pins on the package. Whether your internal datapaths are 8 or 32 bits wide is way down in the noise.

I went to a few distributors' websites and priced out the cheapest 1K quantity of 8-bit AVRs and the cheapest 1K quantity of M0+ chips I could find to get the $0.30 and $0.90 figures. Do you have reference data to contradict those figures?

And it's not just big company commercial application. Countless one-man-bands are doing Kickstarters these days and it's trivial to sell 1000 units in a kickstarter. That 70 cents extra on the BOM cost really matters at even 1000qty. And ordering your parts pre-programmed can be a big deal too. Also, it's not uncommon to have a little cheap pre-programmed 8bit 5 pin micro in a circuit just to do one small dedicated job, rather than have the main processor care about doing that.

$70 cents on 1000 units is $700 dollars. On average little over 1 days worth of engineering time. One of the things I've learned over the years is to start looking at component costs at much higher volumes than 1000 units. However it is good to put a lot of thought into production. Again looking at component costs only can severely hurt your business if a product take too long to program & test.

[wraper]

$70 cents on 1000 units is $700 dollars. On average little over 1 days worth of engineering time. One of the things I've learned over the years is to start looking at component costs at much higher volumes than 1000 units. However it is good to put a lot of thought into production. Again looking at component costs only can severely hurt your business if a product take too long to program & test.

70 cents here and there. I don't think one will limit not caring about expenses to MCU only, in the end will end up up with 3-5 times more expensive BOM.

[nctnico]

$70 cents on 1000 units is $700 dollars. On average little over 1 days worth of engineering time. One of the things I've learned over the years is to start looking at component costs at much higher volumes than 1000 units. However it is good to put a lot of thought into production. Again looking at component costs only can severely hurt your business if a product take too long to program & test.

70 cents here and there. I don't think one will limit not caring about expenses to MCU only, in the end will end up up with 3-5 times more expensive BOM.

You are making the same mistake as many others: you don't care about engineering time!
I know saving a few cents from the BOM gets you an 'atta boy' quickly because it is easy to visualise. However in many projects simple costs savings end up to become huge time sinks. If you need to spend a few weeks to try and optimise code because of a silicon bug, too litle memory or lesser performance in a cheaper microcontroller you'll end up losing your bosses' money. And it is not just development time but also the sales start later. Not to mention the time could have been spend on the next product.

[langwadt]

I'm sure you can run it bare-metal as well.

I'd assume you can run a barebones binary from uboot

[donotdespisethesnake]

These threads always go round in circles seemingly forever. To summarise:

1. Generally 8 bitters are simpler and easier to code at a low level
2. You can always use a 32-bit part in place of an 8-bit, unless you are very high volume and really need to save every cent on unit cost
3. In a lot of cases 8-bitters just don't have the power so a 16 or 32 bit is needed

[Kjelt]

$70 cents on 1000 units is $700 dollars. On average little over 1 days worth of engineering time. One of the things I've learned over the years is to start looking at component costs at much higher volumes than 1000 units. However it is good to put a lot of thought into production. Again looking at component costs only can severely hurt your business if a product take too long to program & test.

70 cents here and there. I don't think one will limit not caring about expenses to MCU only, in the end will end up up with 3-5 times more expensive BOM.

You are making the same mistake as many others: you don't care about engineering time!
I know saving a few cents from the BOM gets you an 'atta boy' quickly because it is easy to visualise. However in many projects simple costs savings end up to become huge time sinks. If you need to spend a few weeks to try and optimise code because of a silicon bug, too litle memory or lesser performance in a cheaper microcontroller you'll end up losing your bosses' money. And it is not just development time but also the sales start later. Not to mention the time could have been spend on the next product.

Indeed socalled NRE costs can be huge. The problem is that the target for some manager is BOM reduction and not overall cost reduction. A lot of managers also take on a project just to keep their personell busy so their budget and fte's are not cut next budget round. Last don't forget ignorance, how much effort will it eventually be to change from lets say a PIC16 to an ST32F0 , most have absolutely no clue.

[rx8pilot]

Indeed socalled NRE costs can be huge. The problem is that the target for some manager is BOM reduction and not overall cost reduction. A lot of managers also take on a project just to keep their personell busy so their budget and fte's are not cut next budget round. Last don't forget ignorance, how much effort will it eventually be to change from lets say a PIC16 to an ST32F0 , most have absolutely no clue.

For sure - I have all sorts of functionality coded, documented, and proven solid on 8bit AVR's. My last and current projects may have benefited from more powerful chips - but it would have delayed the release by months. Opportunity costs and development costs explode and I am back to a Ramen noodle diet for 6 months. Introducing a new architecture will certainly have a time penalty. Hell, I am using a single micro to generate a 3 phase clock to sync power converters. Super easy and I have control via I2C after assembly. Cheap, easy, and the success is nearly guaranteed. I have the chips in stock and loaded into the pick_and_place because they are used in a dozen other projects for totally different tasks. I use the same chip to monitor a soft power switch and drive 2 RGB LED's, communicating over 2-wire I2C. It is easy.

For the most part - I generally prioritize speed and predictability during design. I need to do some low-priority projects with some fancier uC's to develop the skills and libraries without the time/financial pressure.

[NorthGuy]

... you don't care about engineering time!

Engineering time also depends on who's doing the job. You'll work much faster and better if you work with something you're already familiar with. From the boss' point of view - if I employed nctnico, I would make sure to give him ARM based jobs. On the other hand, Siwastaja would have zero chance of getting ARM job - all the ARM jobs would go to nctnico!

 

[nctnico]

Indeed socalled NRE costs can be huge. The problem is that the target for some manager is BOM reduction and not overall cost reduction. A lot of managers also take on a project just to keep their personell busy so their budget and fte's are not cut next budget round. Last don't forget ignorance, how much effort will it eventually be to change from lets say a PIC16 to an ST32F0 , most have absolutely no clue.

For sure - I have all sorts of functionality coded, documented, and proven solid on 8bit AVR's. My last and current projects may have benefited from more powerful chips - but it would have delayed the release by months. Opportunity costs and development costs explode and I am back to a Ramen noodle diet for 6 months. Introducing a new architecture will certainly have a time penalty. Hell, I am using a single micro to generate a 3 phase clock to sync power converters. Super easy and I have control via I2C after assembly. Cheap, easy, and the success is nearly guaranteed. I have the chips in stock and loaded into the pick_and_place because they are used in a dozen other projects for totally different tasks. I use the same chip to monitor a soft power switch and drive 2 RGB LED's, communicating over 2-wire I2C. It is easy.

For the most part - I generally prioritize speed and predictability during design. I need to do some low-priority projects with some fancier uC's to develop the skills and libraries without the time/financial pressure.

That is another problem of going for 8 bitters: they run out of steam at some point and then you have to go up the learning curve again.

-sales pitch mode- I've been messing with microcontrollers for decades and have used many different types. When the ARM based controllers started to get mainstream (not the Cortex Mx ones but the ones with the ARM7TDMI CPU) I evaluated a whole bunch of them carefully and decided to go with the LPC series from NXP. These have a serial bootloader and you can program these using a free tool (and TTL level serial port signals). This has proven to be a good choice because whether it is a 14 pin deviced or 214 pin device: I can use the same low level hardware drivers and the transition fromt ARM7TDMI core to Cortex Mx core was easy as well because NXP kept using the same peripherals. As a result nearly every project I do has a different microcontroller in it (which fits the project). I'm not stuck to a limited choice of microcontrollers.

[Kjelt]

As a result nearly every project I do has a different microcontroller in it (which fits the project). I'm not stuck to a limited choice of microcontrollers.

Yes you are since you limit yourself to NXP 
Good thing the takeover did not go through.

[FrankBuss]

I'm sure you can run it bare-metal as well.

I'd assume you can run a barebones binary from uboot

Right, this would be the easiest way. Boot time would be much less than a second as well, and you could integrate your program in u-boot itself, which then autostarts after u-boot did all the hard stuff like setting up the PLL etc. Don't know the version on the Allwinner, but usually u-boot even supports USB and network.

[FrankBuss]

There are many applications where it needs to be faster and where you need more memory, for example for video IO (this chip has an ethernet interface and a camera input, so probably could be used as a web cam), or polyphonic realtime audio synthesis with effects (reverb needs lots of memory). And the Allwinner V3s is not just a core, it has some useful peripherals as well, see the datasheet, like DMA, PWM, SPI, I2C, UART, audio codec etc. So if you don't miss a peripheral for your application, it could be a cheap replacement for the higher priced STM32 series chips, but with more RAM and much faster. It can run slower as well, probably using not much more power then as a STM32 running at 180 MHz.

This is not the sort of thing that microcontrollers are typically used for. Do you really want to wait for Linux to boot and think about crashes, memory leaks, hacks, etc in your microwave oven, dishwasher, clothes washer and dryer, tv remote, alarm clock, etc? Linux SOCs and microcontrollers are two entirely different fields with some small bit of overlap in the middle. The strength of the microcontroller is in the peripherals, and the simplicity. There is effectively no boot time, there is no operating system, everything happens in real time and can be tweaked down to individual clock cycles. You can get microcontrollers in tiny packages with only a few pins, you can get ones that consume miniscule amounts of power. It is absolutely silly to suggest a Linux SOC for microcontroller applications, even if the Linux route was cheaper the end result would be inferior for the sort of applications where microcontrollers are typically used.

I agree that it doesn't make sense to use Linux for a remote control. I was suggesting it as a replacement for the high end microcontrollers. Don't know about e.g. a clothes washer, it could monitor the clothes with a cam, then send it over ethernet Just the network stack etc. would be a hassle without an operating system on one of the conventional high end microcontrollers. On a Linux IC you could write the whole thing with a few lines of Python code.

[Kjelt]

I agree that a small Linux platform is an easy IoT starter but it is also an easy target for hackers as we have seen in the multiple compromised IP cameras , videorecorders and other IoT devices on the IoT wall of shame. So the biggest issue you face are:

1) hardening your product, shutting down each and every unused port/service etc that could pose a threat, security penetration testing by a professional organisation to check if you got it right

2)after release : security lifecycle management/maintenance of your product, having to keep track of all published vulnerabilities and update the device accordingly.

With a simple arm cortex you face less risk since you dont have the large ram, the ip stack is so limited a hacker has little options to exploit it or use it as an attack platform for the rest of the network (There are no services not even a filesystem in most cases).
So if you look at the list of exploited embedded devices they score way better than the standardized linux platforms which is not a surprise.

[Siwastaja]

Engineering time also depends on who's doing the job. You'll work much faster and better if you work with something you're already familiar with. From the boss' point of view - if I employed nctnico, I would make sure to give him ARM based jobs. On the other hand, Siwastaja would have zero chance of getting ARM job - all the ARM jobs would go to nctnico!

What the heck is an "ARM job"? If this is about designing ARM processors or MCUs/SOCs using ARM cores, I understand this.  For a PCB/software design work that only utilizes "ARM things" as components - nope, you want a broader perspective. The core is just a single detail. Complete MCU architecture (peripherals!!) is more meaningful - and how you use it. Experience on many different product families (and preferably several manufacturers - still my weakest point, I mostly know about AVR, STM32 and Altera FPGAs) really helps here. OTOH, you can't be deeply experienced in too many different things. It's a trade-off.

This is exactly why I love to work in a fairly small startup, where I can be in the "CTO" role as well, and be employed by my own company. In-depth knowledge and ability to bring results matter, and we have basically no cargo cult on technical matters, which is absolutely great. Small engineering team of about four people is easy to work with, and everybody trusts me 100% on matters regarding electronics and low-level software. I can choose who I play with, and I have a lot to say to who gets hired. So, simply put, I don't need to be hired by people like you, and I don't need to play your office games.

I rather take the business uncertainty and risks of a small startup.

The perspective-less belief in "getting things done quickly" by using trend tools - typically chosen with Powerpoints, by people who are not actually writing the code - and reusing other's code as much as possible works on a small timescale.

This is the inevitable way to work when the engineers don't have the skills to do it otherwise, and it always seems like the right choice - short term. It also works on larger corporations with established tradition to bring out mediocre mass products where large engineering costs (by using ineffective design practices and teams too large) do not matter.

Long term, and when you want to develop something really ground-breaking (not just a new coffee maker), it's well worth investing some years of time so that the engineers learn. For me, it happened during two decades of  "hobby / enterpreneur hybrid", and thanks to me being able to insist on not listening those who tell me how I "should" be doing things. According to masses, I have always been "wrong". Funnily, during that time, the way things "should" be done changed so many times that you never learn any of those ways properly, anyway. Also, no one remembers those "right ways" of doing things after a decade.

Suddenly, I was able to start saying "yes" for complex work on projects involving other people. And suddenly, I could say "yes" on taking the leading role.

Gain experience on real projects, always do it your own way. Believe in your skills and your intuition, even if it goes wrong sometimes - that way you learn, and after a decade of doing it like this, you suddenly realize you are not going too wrong anymore, and can make fairly good estimates of the project timeline, cost, and communicate with others, using their terms as well - while still doing it your way.

Don't be arrogant.

Would I hire you or nctnico? I don't know. I don't see too many problems in your or nctnico's posts, and see a lot of good points, most of which I totally agree with. But this kind of forum babble doesn't give enough information about how you would really succeed in a complex, real world project, with real-world constraints.

Also, I trust that a real team doesn't need to agree on everything; but instead of arguing, or even worse, compromising trying to find the "middle road", they should be all doing things in a way which they are most productive; summing their (different) skills.

[nctnico]

I'm sure you can run it bare-metal as well.

I'd assume you can run a barebones binary from uboot

Right, this would be the easiest way. Boot time would be much less than a second as well, and you could integrate your program in u-boot itself, which then autostarts after u-boot did all the hard stuff like setting up the PLL etc. Don't know the version on the Allwinner, but usually u-boot even supports USB and network.

True. Some of the bootloaders (u-boot isn't the only one) have turned into mini-OSses with a lot of functionality. So if you need a lot of processing power / memory in a microcontroller-ish application I would see this method as an option.

[GeorgeOfTheJungle]

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

Absolutely, don't waste your time with 8 bitters, ARM is the way to go.

http://infocenter.arm.com/help/index.jsp







Also in arduino form:

[Mr. Scram]

Absolutely, don't waste your time with 8 bitters, ARM is the way to go.

http://infocenter.arm.com/help/index.jsp







Also in arduino form:

With zero arguments you're not exactly making a strong case, especially considering there's a thread's worth of arguments why 8 bit chips are relevant.

[GeorgeOfTheJungle]

With zero arguments you're not exactly making a strong case, especially considering there's a thread's worth of arguments why 8 bit chips are relevant.

The OP: "[...] I'm trying to select a (µC) chip to learn [...]".

Had he said "I'm trying to learn electronics", you'd recommend to begin with thermionic valves? No.

There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?

Eight bitters are obsolete, a thing of the past, "not recommended for new designs".

Both Apple and Microsoft are working to migrate their products from Intel to ARM-based processors developed in-house.

[wraper]

There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?

Eight bitters are obsolete, a thing of the past, "not recommended for new designs".

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

Semiconductor MCU revenue market forecast –millions of dollars

[rx8pilot]

The OP: "[..] I'm trying to select a (µC) chip to learn [..]".

Had he said "I'm trying to learn electronics", you'd recommend to begin with thermionic valves? No.

There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?

Eight bitters are obsolete, a thing of the past, "not recommended for new designs".

8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures. They also provide a CRITICAL understanding of system efficiency. When a developer or programmer is using completely overkill hardware - it promotes sloppy and inefficient programming/development techniques.

Sloppy design and coding require more physical resources, more parts, more RAM, more pins, more costs, etc. In the use case of learning - the limitation of 8 bit is not a limitation. They provide a problem big enough to learn, but small enough to tackle. They also force the student to pay attention to the details when they are pushing the limits of the part.

[GeorgeOfTheJungle]

8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures.

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

[nctnico]

Eight bitters are obsolete, a thing of the past, "not recommended for new designs".

8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures. They also provide a CRITICAL understanding of system efficiency. When a developer or programmer is using completely overkill hardware - it promotes sloppy and inefficient programming/development techniques.

IMHO this is wrong. There is absolutely no reason you can't learn to program efficiently on an ARM. Just give a student an assignment for which the C compiler can't do it's optimising magic. If necessary the knowledge can be applied to 8 bit as well but in today's situation not learning ARM means someone is behind. And anyone who is claiming ARM is more complicated than 8 bit clearly has never really looked at a simple ARM controller. These do exist and are easier to understand compared to a 8051.

[Kjelt]

but in today's situation not learning ARM means someone is behind. And anyone who is claiming ARM is more complicated than 8 bit clearly has never really looked at a simple ARM controller. These do exist and are easier to understand compared to a 8051.

You lost me here.
OR you learn the ARM core and read the thousands of pages, study registers and opcodes/assembly instructions   It sure is more complicated than 8 bit cores.
But almost no-one using Arms does that, hell almost no-one using 8 bitters look at the core, how many registers it has, hardware or sw multiplier etc, they just code C and let the compiler figure it out.
So probably you mean the other features the ARM core has such as DMA , clocks etc.

If you mean the peripherals that has 0 to do with ARM but I know you know that so that is not what you meant, so what exactly did you mean to say ?

[rx8pilot]

IMHO this is wrong. There is absolutely no reason you can't learn to program efficiently on an ARM.

Fair enough.....
People learning application programming on 64bit systems with massive RAM and Storage resources have absolutely no reason they cannot learn efficient programming either, yet many do not.

[nctnico]

but in today's situation not learning ARM means someone is behind. And anyone who is claiming ARM is more complicated than 8 bit clearly has never really looked at a simple ARM controller. These do exist and are easier to understand compared to a 8051.

You lost me here.
OR you learn the ARM core and read the thousands of pages, study registers and opcodes/assembly instructions   It sure is more complicated than 8 bit cores.

If you mean the peripherals that has 0 to do with ARM but I know you know that so that is not what you meant, so what exactly did you mean to say ?

Just take a low end ARM controller from NXP like the LPC1111 as an example. These don't have many fancy features and don't need a single line of assembly to get going. Also you don't need to study thousands of pages about the ARM core. Where did you get that idea from? System integrators who design microcontrollers and SoCs may want to know all the ins&outs but I for sure don't need to know all that. If you want to program using assembly then all the opcodes for the ARM fit on two (or three) pages. Even better: it has less addressing modes and memory areas compared to the 8051 so less to worry about.

AFAIK the only thing I ever looked up in the ARM Cortex manual is the order in which the registers are saved onto the stack before an interrupt so I can print a stack trace in case of a memory fault.

[Kjelt]

I agree but if you look at it from that perspective there is not that much difference programming C between Arm or STM8 for instance, you just code C. So why would someone be behind? If you learn Arm you learn the core how many registers etc. You could argue the high speed busses, i would agree.

If you need  writing some part of the code in assembly because for instance you need the speed of a multiply with carry that C does not support, you need to know how many registers there are where they are used for and where you can safely put your results. In that sense an Arm is hugely different many more registers from an Stm8.

[Mr. Scram]

The OP: "[...] I'm trying to select a (µC) chip to learn [...]".

Had he said "I'm trying to learn electronics", you'd recommend to begin with thermionic valves? No.

There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?

Eight bitters are obsolete, a thing of the past, "not recommended for new designs".

Both Apple and Microsoft are working to migrate their products from Intel to ARM-based processors developed in-house.

The world hasn't moved on to ARM and eight bitters aren't obsolete or a thing of the past. Plenty of reasons have been given for why that is, and your claims of the opposite still don't come with arguments.

As a sidenote, what Apple and Microsoft do doesn't seem to be relevant to the world of microcontrollers. It's two kettles of fish.

[Mr. Scram]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

[nctnico]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Jack Ganssle is just an old fart. Remember: Those who can, do; those who can't, teach. From my own experience ARM assembly is as easy or difficult like assembly for the Z80, ADSP2180, x86, 8051, MIPS, ARM, 68000 and a few others I have probably already forgotten about.

[coppice]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.

[langwadt]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

I don't think ARM is terribly complicated, the reference card is a single page, but there is seldom reason to use it, compilers are is most cases good enough or better

[nctnico]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.

Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.

[Mr. Scram]

Jack Ganssle is just an old fart. Remember: Those who can, do; those who can't, teach. From my own experience ARM assembly is as easy or difficult like assembly for the Z80, ADSP2180, x86, 8051, MIPS, ARM, 68000 and a few others I have probably already forgotten about.

I'll trust the old fart over the random forum guy. Besides, not teaching doesn't automatically mean being in the "can" group.

[coppice]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.

Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.

I neither mentioned nor intended to refer to peripheral complexity.

[nctnico]

Jack Ganssle is just an old fart. Remember: Those who can, do; those who can't, teach. From my own experience ARM assembly is as easy or difficult like assembly for the Z80, ADSP2180, x86, 8051, MIPS, ARM, 68000 and a few others I have probably already forgotten about.

I'll trust the old fart over the random forum guy. Besides, not teaching doesn't automatically mean being in the "can" group.

I hate it when other people say something is hard because they failed or are not inclined to make the effort to learn. It doesn't say anything about something being hard or easy to do for someone else. Idolising a person is the worst thing to do. Always go from your own strength and let nobody tell you are unable to do this or that. History is littered with people who succeeded where many others failed.

[nctnico]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.

Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.

I neither mentioned nor intended to refer to peripheral complexity.

Actually you did because every microcontroller has the CPU start executing code from the default start address after power up. ARM microcontrollers are no exception to that rule.

[rx8pilot]

I have spent the last few hours listening/watching an ARM introduction and tutorial series. It looks just like developing for 8bit. Just faster and much bigger numbers. If you are a sloppy coder.....you may never know with really fast clock speeds. For most applications, who cares I guess.

The cost of the hardware is silly cheap too.

[coppice]

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.

Few people bother with any assembly language in MCUs. They use C. ARM chips are generally a lot more complicated than 8 bit chips, but its nothing to do with the instruction set. Its the complexity of getting them configured to the point where they can run any useful code which makes them more complicated to get started with.

Again: that depends entirely on what kind of microcontroller you are using. There are 8 bit microcontrollers which are hard to configure as well. Don't confuse the CPU core for peripheral complexity.

I neither mentioned nor intended to refer to peripheral complexity.

Actually you did because every microcontroller has the CPU start executing code from the default start address after power up. ARM microcontrollers are no exception to that rule.

Are you considering the clock, interrupt control, power system, and so on to be peripherals? Those things take considerable effort to set up on most ARM MCUs before any actual application code can run, and do anything useful with the real peripherals. In most 8 bit MCUs you might need a couple of operations to get the clock up to speed.

[Mr. Scram]

I hate it when other people say something is hard because they failed or are not inclined to make the effort to learn. It doesn't say anything about something being hard or easy to do for someone else. Idolising a person is the worst thing to do. Always go from your own strength and let nobody tell you are unable to do this or that. History is littered with people who succeeded where many others failed.

I agree with the last bit, but not with the assumptions before it.

[westfw]

[Simple ARM chips exist]

Such as?  I mean, it's not really awful, but I don't think I've run across an ARM yet that isn't: "oh, you want to run at the rated maximum clock speed?  That means you'll have to start by configuring our complicated clock system!  (Don't worry; you can use the 1kbyte library function instead.)"

ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it.

ARM assembly language is ... unpleasant, designed to be output by a compiler rather than written by a human.That's especially true of the Cortex-M0 used on the low-end ARM MCUs.  "Supports the ARM instruction set.   No, not that instruction. Not that register.  And not that mode of THAT instruction, and ... the range of operands for THIS instruction is a bit limited on CM0."  Sigh.Even on a well-behaved ARM, it's still three instructions, a literal pool constant, and two registers trashed to write a value to a peripheral register.

[maginnovision]

I will say my personal experience is that the ARM MCU's I've used finding a lot of the details of the core, which matter for a time constrained program, was not easy and not in the datasheets. The datasheets were mostly about peripherals, which is normal for an ARM MCU as far as I can tell. I was forced(or I could just not know I guess) to look up the data in the ARM manuals. That isn't pleasant for me and feels like searching through a large garbage bin for a lost check. The 8-bit MCUs I've used had that data in the datasheet. If you don't care that's fine but that was my experience. I still use 8 bit and 32 bit MCUs, ARM and not, but it's definitely not as easy to find some data that you might need.

[brucehoult]

8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures.

There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.

Many of the 8 bitters do have horrid ISAs. 8080/Z80, 8051, 6800, 6502, PIC. A few however are actually pretty pleasant: 6809 and AVR, for example.

I do love ARM, and it's simpler than x86, but its gained a lot of cruft over the years and is much more complex than MIPS or RISC-V. Both RISC-V (with 16 and 32 bit instructions) and the latest nanoMIPS encoding (with 16, 32 and 48 bit instructions) come in very code size competitive with Thumb2, while still being much simpler.

[rx8pilot]

Many of the 8 bitters do have horrid ISAs. 8080/Z80, 8051, 6800, 6502, PIC. A few however are actually pretty pleasant: 6809 and AVR, for example.

I do love ARM, and it's simpler than x86, but its gained a lot of cruft over the years and is much more complex than MIPS or RISC-V. Both RISC-V (with 16 and 32 bit instructions) and the latest nanoMIPS encoding (with 16, 32 and 48 bit instructions) come in very code size competitive with Thumb2, while still being much simpler.

Are there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.

[westfw]

time constrained program

Were the ARM manuals sufficient?  When it comes to timing, it seems to all fall apart when you get to the not-full-speed flash memory, which usually has some sort of "accelerator" or cache in front of it, which is usually a vendor feature that is not very well documented :-(

Are there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.

Z80 - yes.  There's a whole line Zilog microcontrollers (on-chip RAM and code memory, plus peripherals), plus some of the Renesas chips are pretty much Z80-like (with bells, whistles, an kludges.)
The 8051 was always a microcontroller.  There are now oodles of variants with up to a full address space (or more) of program flash, although RAM is usually a bit on the weak side.   Any number of special purpose chips (MP3 player chip, USB Flash Controller Chip, etc) turn out to be 8051 cores with some special purpose hardware attached.
I don't know if there are any 6800 microcontrollers, but the 6805 line (which is quite similar architecturally) spurred several microcontroller families, including S08 and S12 families that are still labeled as current, rather than "legacy."
I don't know of any 6502-like microcontrollers.

[petert]

Jack Ganssle is just an old fart.

I find it that this kind of personal attack is unnecessary, especially with that type of wording, even if I may agree about the advantage of modern µCs. It's just an unpleasant kind of interaction, and quickly derails.

[maginnovision]

time constrained program

Were the ARM manuals sufficient?  When it comes to timing, it seems to all fall apart when you get to the not-full-speed flash memory, which usually has some sort of "accelerator" or cache in front of it, which is usually a vendor feature that is not very well documented :-(

Are there 8bit microcontrollers based on 8080/Z80, 8051, 6800, 6502? I thought they were simply CPU's.

Z80 - yes.  There's a whole line Zilog microcontrollers (on-chip RAM and code memory, plus peripherals), plus some of the Renesas chips are pretty much Z80-like (with bells, whistles, an kludges.)
The 8051 was always a microcontroller.  There are now oodles of variants with up to a full address space (or more) of program flash, although RAM is usually a bit on the weak side.   Any number of special purpose chips (MP3 player chip, USB Flash Controller Chip, etc) turn out to be 8051 cores with some special purpose hardware attached.
I don't know if there are any 6800 microcontrollers, but the 6805 line (which is quite similar architecturally) spurred several microcontroller families, including S08 and S12 families that are still labeled as current, rather than "legacy."
I don't know of any 6502-like microcontrollers.

The ARM manuals told me what I needed to know. They were not easy to find or use though. Even before cache and flash issues the interrupt overhead was already too high to bother.

[Kjelt]

I don't know of any 6502-like microcontrollers.

IIRC the ST7 and also STM8 have evolved from the 6502.
They use the same registers but have expanded on some, from stm8 to st7 another expanion

It has the same six registers (A, X, Y, SP, PC, CC) as the ST7, but the index registers X and Y have been expanded to 16 bits, and the program counter has been expanded to 24 bits.

[GeorgeOfTheJungle]

Even before cache and flash issues the interrupt overhead was already too high to bother.

https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

For comparison, here's a famous 8 bitter:

http://6502.org/tutorials/interrupts.html#a
http://6502.org/tutorials/interrupts.html#1.3

A copy-paste of a table from there (clearly biased):

1802	RCA	? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs).  2.5MHz @ 5V.
8080	Intel	? (still waiting for information)
8088	Intel	10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information)
8086	Intel	WDC says 182 clocks max total latency. * * * * *  (still waiting for information)
Z8	Zilog	IRET (E) takes 16 execution cycles.  I don't know how many clock cycles per execution cycle.  8MHz?
Z80	Zilog	11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz.  RETI (E) is 14 clocks, or 3.5μs @ 4MHz.
Z8000	Zilog	IRET (E) takes 13  cycles in non-segmented mode, and 16 in segmented mode.  I don't know if that's instruction cycles or clock cycles.
8048	Intel	(?) return (E) is 2.7μs @ 11MHz
8051	Dallas	1.5μs @ 33MHz (52 clocks) latency
8051	Intel	1.8μs (C) min @ 20MHz.  5.4μs (A)+(C) max total latency @ 20MHz.  (3-9μs @ 12MHz.) Interrupt sequence (C) and return (E) take 4.6μs @ 20MHz  ST
80C51XA	Philips	2.25μs for interrupt+return (C)+(E) @ 20MHz.  ST Instructions 2-24 cy, or 0.1-1.2μs.  Avg 5-6 cy, or around 0.27μs.
KS88	Samsung	3μs for interrupt+return (C)+(E) @ 8MHz  ST Instructions 6-28 cy, or 0.75-2.5μs.  Avg 11 cy, or 1.38μs.
78K0	NEC	4.3μs for interrupt+return (C)+(E) @ 10MHz  ST Instructions 4-50 cy, or 0.4-5.0μs.  Avg 15 cy, or 1.5μs.
COP8	National	70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles).  (7μs & 5μs @ 10MHz)
μPD78C05	NEC	RETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz)
μPD70008/A	NEC	sequence (C) takes 13 or 19 clocks.  Return (E) takes 14 clocks. Instructions take 4-23 clocks each.  6MHz in '87 book.
V20	NEC	RETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book. Instruction set is a superset of that of 8086/8088.
V25	NEC	?  (still waiting for information)
68000	Motorola	46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?.  Has a very complex interrupt system.
6800	Motorola	(C)=13 clocks, including pushing the index register and both accumulators.  RTI (E) takes 10 clocks.  2MHz.
6809	Motorola	(C)=19 clocks.  Stacks all registers.  RTI (E) 15 clocks.  2MHz (8MHz/4). FIRQ-RTI take 10 & 6 clocks, & work more like 6502 IRQ-RTI.
68HC05	Motorola	16 clocks typ (8μs @ 2MHz)
68HC08	Motorola	Instructions 1-9 cy, or 0.125-1.125μs.  Avg 4-5 cy, or around 0.55μs.
68HC11	Motorola	(C)=14 clocks.  RTI (E)=12 clocks.  Total for interrupt+return=8.75μs @ 4MHz (16MHz/4).  ST Instructions 2-41 cy, or 0.5-10.25μs.  Avg 6-7 cy, or around 1.6μs.
68HC12	Motorola	2.63μs for interrupt+return (C)+(E) @ 8MHz.  ST Instructions 1-13 cy, or 0.125-1.625μs.  Avg 3-4 cy, or 0.45μs.
68HC16	Motorola	2.25μs for interrupt+return (C)+(E) @ 16MHz.  ST Instructions 2-38 cy, or 0.125-2.375μs.  Avg 6-7 cy, or around 0.4μs.
PIC16	Microchip	(C)=8 clocks (2 instruction cycles), and RETFIE (E) is also 8 clocks; but this doesn't even include saving and restoring the status register.  That's an extra, rather mickey-mouse operation.  20MHz  Most instructions 4 cy, or 0.2μs.
TMS370	TI	15 cycles (3μs) min (C), 78 (15.6μs) max (A)+(C), and a cycle is 4 clocks (200ns min)!  20MHz. RTI (E) is 12 cy (48 clocks or 2.4μs).
TMS7000	TI	(C)=19 cycles min (17 if from idle status) 5MHz, 400ns min cycle time (IOW, interrupt sequence is 7.6μs min, 6.8 from idle.)  RETI (E) is 9 cycles, or 3.6μs @ 5MHz.
ST6	STM	78 clocks min, or 9.75μs @ 8MHz to fetch interrupt vector.  More to reach first ISR instruction. RETI is 26 clocks, or 3.25μs.
ST7	STM	3μs for interrupt+return @ 8MHz.  ST Instructions 2-12 cy, or 0.25-1.5μs.  Avg 4-5 cy, or around 0.55μs.
ST9	STM	External IRQ best case: 1.08μs @ 24MHz. NMI best case: 0.92μs.  internal interrupts best case: 1.04μs.  2.25μs @ 24MHz for interrupt and return ST  Instructions 6-38 instruction cy, or 0.5-3.67μs.  Avg 17 cy, or around 1.4μs.
ST9+	STM	1.84μs @ 25MHz for interrupt and return, ST Instructions 2-26 instruction cy, or 0.16-1.04μs.  Avg 11 cy, or around 0.9μs
H8/300	Hitachi	8/16-bit: 2.1μs @ 10MHz for interrupt and return ST Instructions 2-24 cy, or 0.2-3.4μs.  Avg 5-6 cy, or around 0.55μs.
M16C M30218	Mitsubishi Renesas	18 cy min (C), or 1.125μs @ 16MHz w/ 16-bit data bus.  50 cy max (A)+(C).  REIT is 6 cy, or 0.375μs. Dual register sets like the Z80.  Max instruction length 30 cy.
CIP-51	Silicon Labs    Cygnal	μC p/n C8051F2xx)  total latency 5-18 cy or 0.2-0.72μs @ 25MHz.  RETI takes 5 cy, or 0.2μs. This is the only one I have data on here that gives the 6502 below any competition.
65C02	WDC	Normal latency (C) 7 clocks (0.35μs) min, 14 clocks (0.7μs) max (A)+(C).  RTI 6 cy (0.3μs).  20MHz. Instructions 2-7 cy, or 0.1-0.35μs.  Avg 4 cy, or 0.2μs. Special case:  IRQ from WAIt instrucion with interrupt-disable bit I set:  no more than 1 cy (0.05μs!)

[Siwastaja]

1) Caches are a moot point. They tend to be disabled by default. Just don't enable them. I've never enabled them. Use RAM, especially core-coupled memories for fast instructions and data. Enjoy simple, predictable operation. The caches are there because some people want to use them when developing in a "non-microcontrollerish" style - for example, running a massive UI program from flash - or from an SD card - directly. The caches don't magically mess up your timings when you don't locate timing-critical code and data in cached regions.

2) Getting an STM32 blink an LED requires one (1) register write more than an AVR - 3 instead of 2: a simple enable bit on a well-documented register to turn the relevant GPIO port on. I think the same is true for most ARM microcontrollers. The difference is small: AVR has "power reduction registers" you use to turn peripherals off. STM32 has registers to enable what you need.

3) An ADC on STM32 combined with DMA, while sounding fancy, may be easier to understand for a beginner, since you write about 6-7 lines of this-makes-sense initialization code, and then just read the latest readings directly from the variables - no need to write ISRs to store values and switch analog MUXes.

4) Clock control on an STM32 is not much more complex than on AVR - but instead of calculating some strange separate things called "fuses", which can brick your system preventing reprogramming, you just simply write the config in standard C in your init function. I think this is simpler.

5) With STM32, I don't need a specific programming tool. A standard USB serial cable works.

6) I opened ARM reference manual first time after about 3 years of professional work on ARM MCUs. I have spent about 0.00001% of my time on ARM reference manual, after that. I think I have opened it twice.

7) I sometimes look at the instruction set, and sometimes need to write custom assembly. AVR instruction set is OK, but ARM is very good, simple, and easy to understand.

8 ) ARM architecture is easy to understand, what comes to the interrupt vector table, how the interrupts work, and how to use them. Also register pushing on interrupt entry. I find all this simpler than on AVR, although AVR is quite simple as well. Having prioritized interrupts that can pre-empt others, IMO, makes everything easier. You can write longer ISRs with lower priorities, and make timing critical ISRs pre-empt them; you have more tools in your box to work different ways case-by-case. Using two lines of code to set the interrupt priority and enable it is not complex.

9) I think one of the best points in AVR or PIC is that the existing community mostly develops code in a style what I call "sane". Simple, efficient way. While you can do the same on ARM, it's not trivial because the community is so fragmented, and "everybody" seems to be using bloated ways - dozens of different code autogeneration tools, dozens of different libraries that are complex to use and fail at doing real hardware abstaction - which is understandable, since totally generic (written by others) hardware abstraction is not easy on microcontrollers.

People who have developed for AVR or PIC, often say they miss that "old" style when going ARM. What we need to tell them is: you can go on with exactly that, there's nothing wrong - ARM cores and the peripherals in a typical modern ARM MCU are not that much more complicated than on AVR! It's just that the 1000-line bloated inits autogenerated or copypasted make them look very complex. But if you choose it, you have the freedom to go on in the classical MCU style, and I strongly recommend it to anyone. The problem is, while I'm not alone, our viewpoint won't get enough exposure.

10) Previous point tldr: With AVR, every beginner has a clear and simple route to follow. On ARM MCUs, everybody's teaching different way, it's hard to know what to do, and it often looks difficult and complex - many code examples are long just to blink an LED.

11) Once more: the biggest issue I see on learning ARM MCUs is lack of simple, easy to understand, lightweight examples, and tutorials to do sane, sustainable development.

12) Finally, sometimes a cheap small 8-bitter offers exactly what you need. Use it. Especially, if you are experienced on using the PIC, and don't need the fancy-pancy stuff on current generation ARM controllers, use the 8-bitter to save time. Not everyone needs to learn every new skill. Concentrate on what you find important yourself. Be an expert on something, it hasn't to be ARM.

[nctnico]

Jack Ganssle is just an old fart.

I find it that this kind of personal attack is unnecessary, especially with that type of wording, even if I may agree about the advantage of modern µCs. It's just an unpleasant kind of interaction, and quickly derails.

Sometimes you need to make a bold statement to get a point across to wake people up. Look at Jack's bio. He clearly is a systems designer and not a programmer.

[nctnico]

I will say my personal experience is that the ARM MCU's I've used finding a lot of the details of the core, which matter for a time constrained program, was not easy and not in the datasheets. The datasheets were mostly about peripherals, which is normal for an ARM MCU as far as I can tell. I was forced(or I could just not know I guess) to look up the data in the ARM manuals. That isn't pleasant for me and feels like searching through a large garbage bin for a lost check. The 8-bit MCUs I've used had that data in the datasheet. If you don't care that's fine but that was my experience. I still use 8 bit and 32 bit MCUs, ARM and not, but it's definitely not as easy to find some data that you might need.

This depends on the manufacturer. NXP has an extensive section on the processor core (including instruction set) in the user manual.

[Mr. Scram]

Sometimes you need to make a bold statement to get a point across to wake people up. Look at Jack's bio. He clearly is a systems designer and not a programmer.

It would probably be naive to think his experience and preference only applies to him personally being behind a keyboard or writing code. This would also have been the moment to concede it may not have been the best way of expressing yourself, rather than doubling down on it.

[nctnico]

Sometimes you need to make a bold statement to get a point across to wake people up. Look at Jack's bio. He clearly is a systems designer and not a programmer.

It would probably be naive to think his experience and preference only applies to him personally being behind a keyboard or writing code. This would also have been the moment to concede it may not have been the best way of expressing yourself, rather than doubling down on it.

You are still idolising. If someone tells me something is extremely hard to do I already close one ear. I'm not going to get useful information from that person other than he/she can't and doesn't know people who can. I keep one ear open for clues on how not to tackle a problem but that is sketchy because maybe the approach was good but the execution was wrong.

[legacy]

ARM architecture is easy to understand, what comes to the interrupt vector table, how the interrupts work, and how to use them. Also register pushing on interrupt entry. I find all this simpler than on AVR, although AVR is quite simple as well. Having prioritized interrupts that can pre-empt others, IMO, makes everything easier. You can write longer ISRs with lower priorities, and make timing critical ISRs pre-empt them; you have more tools in your box to work different ways case-by-case. Using two lines of code to set the interrupt priority and enable it is not complex.

In avionics we have constraints and ISRs pre-empt is extremely bad for us, hence strictly prohibited.
I don't want to give you a "no-go", simply a hint: I would put extra careful in abusing of this feature.

[coppice]

I don't know if there are any 6800 microcontrollers, but the 6805 line (which is quite similar architecturally) spurred several microcontroller families, including S08 and S12 families that are still labeled as current, rather than "legacy."

The 6801 was an MCU built around the 6800 core. Later on, the 6805 MCUs used a stripped down version of the 6800 core, and the 6811 MCUs  used an enhanced version of the 6800 core. There were other variants, some from Hitachi and ST.

I don't know of any 6502-like microcontrollers.

I believe WDC and others put the 6502 core in some MCUs.

[langwadt]

ARM architecture is easy to understand, what comes to the interrupt vector table, how the interrupts work, and how to use them. Also register pushing on interrupt entry. I find all this simpler than on AVR, although AVR is quite simple as well. Having prioritized interrupts that can pre-empt others, IMO, makes everything easier. You can write longer ISRs with lower priorities, and make timing critical ISRs pre-empt them; you have more tools in your box to work different ways case-by-case. Using two lines of code to set the interrupt priority and enable it is not complex.

In avionics we have constraints and ISRs pre-empt is extremely bad for us, hence strictly prohibited.
I don't want to give you a "no-go", simply a hint: I would put extra careful in abusing of this feature.

so no OS allowed?

[legacy]

so no OS allowed?

no-go for nested interrupts, no-go for preempted interrupts. Our directives are simple: interrupts are allowed but! when an interrupt happens it MUST not be interrupted.

[langwadt]

so no OS allowed?

no-go for nested interrupts, no-go for preempted interrupts. Our directives are simple: interrupts are allowed but! when an interrupt happens it MUST not be interrupted.

a preemptive OS is basically a preempted interrupt

[maginnovision]

Even before cache and flash issues the interrupt overhead was already too high to bother.

[url]https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors[/url]

For comparison, here's a famous 8 bitter:

[url]http://6502.org/tutorials/interrupts.html#a[/url]
[url]http://6502.org/tutorials/interrupts.html#1.3[/url]

A copy-paste of a table from there (clearly biased):

1802	RCA	? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs).  2.5MHz @ 5V.
8080	Intel	? (still waiting for information)
8088	Intel	10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information)
8086	Intel	WDC says 182 clocks max total latency. * * * * *  (still waiting for information)
Z8	Zilog	IRET (E) takes 16 execution cycles.  I don't know how many clock cycles per execution cycle.  8MHz?
Z80	Zilog	11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz.  RETI (E) is 14 clocks, or 3.5μs @ 4MHz.
Z8000	Zilog	IRET (E) takes 13  cycles in non-segmented mode, and 16 in segmented mode.  I don't know if that's instruction cycles or clock cycles.
8048	Intel	(?) return (E) is 2.7μs @ 11MHz
8051	Dallas	1.5μs @ 33MHz (52 clocks) latency
8051	Intel	1.8μs (C) min @ 20MHz.  5.4μs (A)+(C) max total latency @ 20MHz.  (3-9μs @ 12MHz.) Interrupt sequence (C) and return (E) take 4.6μs @ 20MHz  ST
80C51XA	Philips	2.25μs for interrupt+return (C)+(E) @ 20MHz.  ST Instructions 2-24 cy, or 0.1-1.2μs.  Avg 5-6 cy, or around 0.27μs.
KS88	Samsung	3μs for interrupt+return (C)+(E) @ 8MHz  ST Instructions 6-28 cy, or 0.75-2.5μs.  Avg 11 cy, or 1.38μs.
78K0	NEC	4.3μs for interrupt+return (C)+(E) @ 10MHz  ST Instructions 4-50 cy, or 0.4-5.0μs.  Avg 15 cy, or 1.5μs.
COP8	National	70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles).  (7μs & 5μs @ 10MHz)
μPD78C05	NEC	RETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz)
μPD70008/A	NEC	sequence (C) takes 13 or 19 clocks.  Return (E) takes 14 clocks. Instructions take 4-23 clocks each.  6MHz in '87 book.
V20	NEC	RETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book. Instruction set is a superset of that of 8086/8088.
V25	NEC	?  (still waiting for information)
68000	Motorola	46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?.  Has a very complex interrupt system.
6800	Motorola	(C)=13 clocks, including pushing the index register and both accumulators.  RTI (E) takes 10 clocks.  2MHz.
6809	Motorola	(C)=19 clocks.  Stacks all registers.  RTI (E) 15 clocks.  2MHz (8MHz/4). FIRQ-RTI take 10 & 6 clocks, & work more like 6502 IRQ-RTI.
68HC05	Motorola	16 clocks typ (8μs @ 2MHz)
68HC08	Motorola	Instructions 1-9 cy, or 0.125-1.125μs.  Avg 4-5 cy, or around 0.55μs.
68HC11	Motorola	(C)=14 clocks.  RTI (E)=12 clocks.  Total for interrupt+return=8.75μs @ 4MHz (16MHz/4).  ST Instructions 2-41 cy, or 0.5-10.25μs.  Avg 6-7 cy, or around 1.6μs.
68HC12	Motorola	2.63μs for interrupt+return (C)+(E) @ 8MHz.  ST Instructions 1-13 cy, or 0.125-1.625μs.  Avg 3-4 cy, or 0.45μs.
68HC16	Motorola	2.25μs for interrupt+return (C)+(E) @ 16MHz.  ST Instructions 2-38 cy, or 0.125-2.375μs.  Avg 6-7 cy, or around 0.4μs.
PIC16	Microchip	(C)=8 clocks (2 instruction cycles), and RETFIE (E) is also 8 clocks; but this doesn't even include saving and restoring the status register.  That's an extra, rather mickey-mouse operation.  20MHz  Most instructions 4 cy, or 0.2μs.
TMS370	TI	15 cycles (3μs) min (C), 78 (15.6μs) max (A)+(C), and a cycle is 4 clocks (200ns min)!  20MHz. RTI (E) is 12 cy (48 clocks or 2.4μs).
TMS7000	TI	(C)=19 cycles min (17 if from idle status) 5MHz, 400ns min cycle time (IOW, interrupt sequence is 7.6μs min, 6.8 from idle.)  RETI (E) is 9 cycles, or 3.6μs @ 5MHz.
ST6	STM	78 clocks min, or 9.75μs @ 8MHz to fetch interrupt vector.  More to reach first ISR instruction. RETI is 26 clocks, or 3.25μs.
ST7	STM	3μs for interrupt+return @ 8MHz.  ST Instructions 2-12 cy, or 0.25-1.5μs.  Avg 4-5 cy, or around 0.55μs.
ST9	STM	External IRQ best case: 1.08μs @ 24MHz. NMI best case: 0.92μs.  internal interrupts best case: 1.04μs.  2.25μs @ 24MHz for interrupt and return ST  Instructions 6-38 instruction cy, or 0.5-3.67μs.  Avg 17 cy, or around 1.4μs.
ST9+	STM	1.84μs @ 25MHz for interrupt and return, ST Instructions 2-26 instruction cy, or 0.16-1.04μs.  Avg 11 cy, or around 0.9μs
H8/300	Hitachi	8/16-bit: 2.1μs @ 10MHz for interrupt and return ST Instructions 2-24 cy, or 0.2-3.4μs.  Avg 5-6 cy, or around 0.55μs.
M16C M30218	Mitsubishi Renesas	18 cy min (C), or 1.125μs @ 16MHz w/ 16-bit data bus.  50 cy max (A)+(C).  REIT is 6 cy, or 0.375μs. Dual register sets like the Z80.  Max instruction length 30 cy.
CIP-51	Silicon Labs    Cygnal	μC p/n C8051F2xx)  total latency 5-18 cy or 0.2-0.72μs @ 25MHz.  RETI takes 5 cy, or 0.2μs. This is the only one I have data on here that gives the 6502 below any competition.
65C02	WDC	Normal latency (C) 7 clocks (0.35μs) min, 14 clocks (0.7μs) max (A)+(C).  RTI 6 cy (0.3μs).  20MHz. Instructions 2-7 cy, or 0.1-0.35μs.  Avg 4 cy, or 0.2μs. Special case:  IRQ from WAIt instrucion with interrupt-disable bit I set:  no more than 1 cy (0.05μs!)

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example. I'm not trying to submit proof that 8bit can be quick or ARM slow. In this case the ARM was worse than the 8 bit and it was much more troublesome to find the data.

[Mr. Scram]

You are still idolising. If someone tells me something is extremely hard to do I already close one ear. I'm not going to get useful information from that person other than he/she can't and doesn't know people who can. I keep one ear open for clues on how not to tackle a problem but that is sketchy because maybe the approach was good but the execution was wrong.

I'm prioritising the experience of a well known and respected industry icon over the self assessment of a random guy on the Internet. You can tell yourself that's idolising, but that only seems to prove my point.

[nctnico]

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example.

One thing to consider here is that (unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine. On most other microcontrollers the software has to push the registers onto the stack by itself before being able to do something useful. The latter adds to the total latency of the interrupt handling.

[Howardlong]

Add also that you may have to save even more on the stack if you use floating point. It gets very painful, very fast, and it’s not unusual to have to start disassembling and massaging the ISR code or modifiers accordingly. One problem with this approach is that your well meaning fiddling makes the code less maintainable when someone comes along withiut knowledge of your assumptions.

On the wider point, I use the most appropriate device for the problem at hand, whether that’s a PIC10F or an LPC4370, and everything in between, and sometimes beyond. I will also admit to having a strong bias to devices and toolchain I have a good knowledge of, not least because leaning a new family of parts (including their peripherals and toolchain) is very expensive in terms of man hours.

As a quick example, try making an RF powered ARM RFID transponder. It’s hard, whereas with a PIC10LF, and many other 8 bitters, life’s often easier, due to lower power, wider voltage ranges etc.

[nctnico]

Add also that you may have to save even more on the stack if you use floating point. It gets very painful, very fast, and it’s not unusual to have to start disassembling and massaging the ISR code or modifiers accordingly. One problem with this approach is that your well meaning fiddling makes the code less maintainable when someone comes along withiut knowledge of your assumptions.

Personally I try hard to avoid being dependant on software when it comes down to nanosecond timing on a regular microcontroller because it is hard to achieve and hard to maintain. I guess these situations are likely originating from a hardware designer thinking 'they can fix this in software for sure'.

[maginnovision]

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example.

One thing to consider here is that (unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine. On most other microcontrollers the software has to push the registers onto the stack by itself before being able to do something useful. The latter adds to the total latency of the interrupt handling.

Yes, we actually didn't need to save or restore anything because we kept the registers from the compiler. Bit of an edge case. The ARM manuals did specify the registers automatically saved and restored. If you use floating point hardware it saved and restored all of those registers which more than doubles the overhead if I remember right. It's good because you don't have to worry, bad because you can't do anything about it. In our case the AVR worked except we had no time to manage UI and user IO stuff. After testing we decided that wasn't ideal to require a reset to change modes and things. The ARM would have worked better there but the interrupt time wouldn't work. It's likely we could have found the perfect ARM MCU but we fell back on our goto MCU instead.

[langwadt]

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example.

One thing to consider here is that (unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine. On most other microcontrollers the software has to push the registers onto the stack by itself before being able to do something useful. The latter adds to the total latency of the interrupt handling.

Yes, we actually didn't need to save or restore anything because we kept the registers from the compiler. Bit of an edge case. The ARM manuals did specify the registers automatically saved and restored. If you use floating point hardware it saved and restored all of those registers which more than doubles the overhead if I remember right. It's good because you don't have to worry, bad because you can't do anything about it. In our case the AVR worked except we had no time to manage UI and user IO stuff. After testing we decided that wasn't ideal to require a reset to change modes and things. The ARM would have worked better there but the interrupt time wouldn't work. It's likely we could have found the perfect ARM MCU but we fell back on our goto MCU instead.

afair an M4 is 12 or 29 cycles with/without fpu, and with lazy stacking the hardware itself figures if an interrupt
uses the FPU

[maginnovision]

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example.

One thing to consider here is that (unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine. On most other microcontrollers the software has to push the registers onto the stack by itself before being able to do something useful. The latter adds to the total latency of the interrupt handling.

Yes, we actually didn't need to save or restore anything because we kept the registers from the compiler. Bit of an edge case. The ARM manuals did specify the registers automatically saved and restored. If you use floating point hardware it saved and restored all of those registers which more than doubles the overhead if I remember right. It's good because you don't have to worry, bad because you can't do anything about it. In our case the AVR worked except we had no time to manage UI and user IO stuff. After testing we decided that wasn't ideal to require a reset to change modes and things. The ARM would have worked better there but the interrupt time wouldn't work. It's likely we could have found the perfect ARM MCU but we fell back on our goto MCU instead.

afair an M4 is 12 or 29 cycles with/without fpu, and with lazy stacking the hardware itself figures if an interrupt
uses the FPU

Our reference was http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16366.html
I didn't do the calculations but it's the data we have. You could be right that it's 12in 12 out, so 24. Slightly better than the AVR, but not by enough for our purposes.

[langwadt]

The AVR we were considering had 5 cycles latency in, 4 cycles out and ran at 20MHz. I believe the total overhead for the ARM based MCU was ~30 and clocked at 48MHz. It didn't work out. Believe the ARM was an M4 core. Neither ended up being selected but it's just an example.

One thing to consider here is that (unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine. On most other microcontrollers the software has to push the registers onto the stack by itself before being able to do something useful. The latter adds to the total latency of the interrupt handling.

Yes, we actually didn't need to save or restore anything because we kept the registers from the compiler. Bit of an edge case. The ARM manuals did specify the registers automatically saved and restored. If you use floating point hardware it saved and restored all of those registers which more than doubles the overhead if I remember right. It's good because you don't have to worry, bad because you can't do anything about it. In our case the AVR worked except we had no time to manage UI and user IO stuff. After testing we decided that wasn't ideal to require a reset to change modes and things. The ARM would have worked better there but the interrupt time wouldn't work. It's likely we could have found the perfect ARM MCU but we fell back on our goto MCU instead.

afair an M4 is 12 or 29 cycles with/without fpu, and with lazy stacking the hardware itself figures if an interrupt
uses the FPU

Our reference was http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16366.html
I didn't do the calculations but it's the data we have. You could be right that it's 12in 12 out, so 24. Slightly better than the AVR, but not by enough for our purposes.

out is only 10 cycles, so with 20MHz vs. 48MHz it is exactly the same time as the AVR

[westfw]

(unlike most other microcontrollers) an ARM Cortex has already saved a whole bunch of register on the stack when you enter the interrupt routine.

The ARM is somewhat inflexible when it comes to interrupts.  On an AVR, you can potentially write 4 types of ISR (actual details are based on AVR-GCC; other compilers may vary):
1) everything handled at the vector address.  You've got one instruction, plus the reti, and can't touch anything used by the mainline code, including the PSW.  Response time is ~4 cycles in, and 4 cycles out.

2) The single instruction from (1) is a jump to an ISR routine.   The ISR routine is carefully hand-crafted "naked" or ASM code that saves the bare minimum context and restores it with maximum efficiency (this can be zero - the AVR has some instructions that don't modify the PSW.)  Adds at least 3 cycles to entry.  Usually more like 8 (push r, get psw, push psw)  Call it 12 cycles total.

2a) The AVR has 32 registers, and you can configure the compiler to NEVER USE some of them, so this hand-crafted code may be able to get away without using the stack at all...

3) Like 2, only the ISR is C code and the compiler uses a default prologue that saves more than might be necessary, but keeps careful track of what registers are used and doesn't save any extras.  (This is the "usual" case.)  The prologue looks like:

Code: [Select]

  push    r1
  push    r0
  in      r0, 0x3f        ; PSR
  push    r0
  eor     r1, r1 (assembly language programmers complain about the save/setup of "known zero" R1.) We're up to about 15 cycles, which is more than ARM CM0-4 takes ALL THE TIME.

4) Like (3), only now the ISR calls other C functions.  This means that the compiler has to save 12 more registers (at 2 cycles each) that C functions are allowed to modify without saving them.  And restore them.  This is also the only way to get a C ISR that can be changed at runtime (using pointers to functions), since the vector table is in flash.   So the "latency" is up to about 40 cycles, with a similar exit time.  (note that these extra registers all get saved at the beginning of the ISR, not "just before the call actually occurs", so you don't get the opportunity to cleverly handle SOME situations more efficiently.  Not with gcc, anyway.


So, comparing that to an ARM with up to 15 cycles latency, plus some more IFF you use floating point IN your ISR, it seems more like "AVR had some flexibility that makes me comfortable, even though I never use it."

[Howardlong]

Add also that you may have to save even more on the stack if you use floating point. It gets very painful, very fast, and it’s not unusual to have to start disassembling and massaging the ISR code or modifiers accordingly. One problem with this approach is that your well meaning fiddling makes the code less maintainable when someone comes along withiut knowledge of your assumptions.

Personally I try hard to avoid being dependant on software when it comes down to nanosecond timing on a regular microcontroller because it is hard to achieve and hard to maintain. I guess these situations are likely originating from a hardware designer thinking 'they can fix this in software for sure'.

Possibly, but C-O-S-T is a biggie in many implementations. As I said already, you choose the best solution you can given a set of criteria. We all like the most artistically pleasing result, well most of us do, but sometimes if it’s a go or no-go decision, the go decision will always make it. Engineers, like it or not, have to be pragmatic. Energy harvesting is another area where every cycle can count.

[westfw]

Quote

1) Caches are a moot point. They tend to be disabled by default. Just don't enable them.

You think so, eh?  I'm talking less about formal "cache memory that you need to enable" and more about things like the "2*64bit prefetch buffer" (stm32f1xx) or the "Enhanced flash memory accelerator" (LPC176x)Your lovely single-cycle 120MHz RISC CPU isn't going to run so well if every instruction takes 5 additional cycles to fetch from the flash program memory (SAMD51.  But 50ns access times for flash seem to be "typical.")

[mikeselectricstuff]

10) Previous point tldr: With AVR, every beginner has a clear and simple route to follow. On ARM MCUs, everybody's teaching different way, it's hard to know what to do, and it often looks difficult and complex - many code examples are long just to blink an LED.

11) Once more: the biggest issue I see on learning ARM MCUs is lack of simple, easy to understand, lightweight examples, and tutorials to do sane, sustainable development.

Another problem is the mistake of lumping all ARMs together.
Especially from the POV of a beginner where the biggest hurdle is learning a toolchain and getting programming working.
An STM32 is as different to a NXP ARM as it is to a PIC. It's all about the peripherals and the tools.

[westfw]

    2) Getting an STM32 blink an LED requires one (1) register write more than an AVR

I wasn't complaining only about needing to enable peripherals in initialization before you can use them.(I'm not doing so well on clarity, it seems.)More about the three instruction sequence to write any pin:

Code: [Select]

   ldr r1, =IOPORT_BASE  ;; load address of ioport registers. (48bits!)
   mov r0, #(1<<pinno)  ;; load bit that needs set (assumes that pinno<=7, on CM0.)
                      ;; 32bits on v7m, for all single-bit values.
            ;; needs to be another 48bit "ld r0,=b" on v6m, or maybe
            ;;   a mov followed by a shift.
   str r0, [r1, IOPORT_SET] ;; write to the SETABIT register. (1 word)

That's at least 2 registers used, 5 words of flash,and 4 cycles (not counting wait states on the flash, or on the frequently-not-single-cycle APB where the IOPORT peripheral probably lives.)  (I'm assuming that the ARM has PINSET/PINCLR operations, or it gets worse.   Most ARM "Microcontrollers" do have these (and only some 8bit CPUs.)

This compared to the 2-cycle best-case "sbi PORT, pinno" for an AVR (with similar capabilities in most 8bit CPUs.)  It's certainly true that the ARM case is a lot more "general" - The 8bit case changes dramatically if you want to use PORTL, or a variable for the port or pin, while the ARM case stays about the same.
In the end, that's probably the complaint: "The ARM CPU does not have special case features for embedded-like things I think I want to do!"

[westfw]

ARM assembly is easy peasy

Pay no attention to the 4 possible instruction encodings for loading a constant into a register, that range from 16 to 48 bits of flash space, and half of which are not available on a CM0...  It's a RISC CPU and RISC always has completely regular instructions!

[coppice]

Another problem is the mistake of lumping all ARMs together.
Especially from the POV of a beginner where the biggest hurdle is learning a toolchain and getting programming working.
An STM32 is as different to a NXP ARM as it is to a PIC. It's all about the peripherals and the tools.

There is currently a strange pattern of behaviour when offering MCUs to customers:

• For engineers: MCUs mostly sell for their peripheral and memory content, and the core doesn't matter a lot. Even the speed of the core doesn't matter a lot, because most MCUs aren't run at their full speed.
• For managers: If it doesn't have an ARM core they aren't interested. If it does have an ARM core, they will happily sit through a sales pitch for a device that is a horrible mismatch for their needs.

[nctnico]

ARM assembly is easy peasy

Pay no attention to the 4 possible instruction encodings for loading a constant into a register, that range from 16 to 48 bits of flash space, and half of which are not available on a CM0...  It's a RISC CPU and RISC always has completely regular instructions!

Well usually you'd use an LDR Rx,[PC+y] instruction to load a constant into a register on ARM.

[legacy]

(One 16bit constant per instruction on MIPS. A 32bit constant needs two load instructions)

[NorthGuy]

There is currently a strange pattern of behaviour when offering MCUs to customers:

• For engineers: MCUs mostly sell for their peripheral and memory content, and the core doesn't matter a lot. Even the speed of the core doesn't matter a lot, because most MCUs aren't run at their full speed.
• For managers: If it doesn't have an ARM core they aren't interested. If it does have an ARM core, they will happily sit through a sales pitch for a device that is a horrible mismatch for their needs.

For marketers: Our device is powered by cutting-edge 2-core ARM processor.

[wraper]

There is currently a strange pattern of behaviour when offering MCUs to customers:

• For engineers: MCUs mostly sell for their peripheral and memory content, and the core doesn't matter a lot. Even the speed of the core doesn't matter a lot, because most MCUs aren't run at their full speed.
• For managers: If it doesn't have an ARM core they aren't interested. If it does have an ARM core, they will happily sit through a sales pitch for a device that is a horrible mismatch for their needs.

For marketers: Our device is powered by cutting-edge 2-core ARM processor.

http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  .

[westfw]

usually you'd use an LDR Rx,[PC+y] instruction to load a constant into a register on ARM.

Yep.  48bits.  (And how does the PC-relative load work out timing-wise, WRT flash wait-states, flash accelerators, or caches I've been complaining about?  I dunno.)

"MOV" can load an 8-bit constant from a 16bit instruction, and on thumb-2 capable chips you can load 12bit constants, or assorted shifted and/or duplicated 8ish-bit constants, with a 32bit instruction. (on pure Thumb-1 you can do the 8-bit load and a shift in the same space, only using two instructions.)  It's not awful, but it does rather burst the "elegance" of the instruction set...
And it does tend to throw a damper on "typical" instruction sequences like

Code: [Select]

if ((PORTB & SWITCHMASK) == MY_SWITCH_COMBO ...
It's sort of like "ARM does everything faster and better except for dealing with peripheral registers", overlooking the factor that a lot of embedded code does very little BUT "deal with peripheral registers.  :-(

[richardman]

Code: [Select]

if ((PORTB & SWITCHMASK) == MY_SWITCH_COMBO ...
It's sort of like "ARM does everything faster and better except for dealing with peripheral registers", overlooking the factor that a lot of embedded code does very little BUT "deal with peripheral registers.  :-(

"A lot of code" does not equate a lot of execution time spent ;-)

In a 300K+ firmware that I am helping a client on, the peripheral register accessing code amounts to... not a whole lot. Less than 5% for sure.

[rjp]

some folks do runs of thousands  of products with bare minimum mcu's and lots of   assembler to maximize performance and minimize cost

other folks do bespoke and small production runs with fat HAL's and chip price means nothing, but developer time is expensive, so get the big one with most libraries and avoid stuffing around.

its always fun to watch those 2 groups shout at each other

[Kjelt]

concerning ISR delays, for "real time" applications the most important factor is consistency/predictability.
In the end it does not matter if there is an ISR delay of 1us or 3us as long as you can get the job done within the time, you can use RMA if your controller can handle the task. If not you need a faster or different controller, that is all there is to it.
The biggest problem for real time is an unpredictable delay for instance with cache miss penalties, there is where you can really get headaches, in my experience that is. That is why I am not very fond of caches in embedded controllers.

[Siwastaja]

Quote

1) Caches are a moot point. They tend to be disabled by default. Just don't enable them.

You think so, eh?  I'm talking less about formal "cache memory that you need to enable" and more about things like the "2*64bit prefetch buffer" (stm32f1xx) or the "Enhanced flash memory accelerator" (LPC176x)Your lovely single-cycle 120MHz RISC CPU isn't going to run so well if every instruction takes 5 additional cycles to fetch from the flash program memory (SAMD51.  But 50ns access times for flash seem to be "typical.")

As said earlier, run timing-critical routines from core coupled instruction memory, and put the stack on core coupled data memory.

In a typical mid-scale MCU project, I may have 30-50K of program total, out of which about 2-3K is timing critical, and always fit in ITCM, even on small/cheap devices.

Absolutely smallest and cheapest won't have core-coupled RAMs, of course.

12-cycle interrupt latency including register push, happening at at least 48MHz, possibly even at 400MHz-500MHz on more expensive ARM MCUs, is way faster than a 5-cycle interrupt latency + about 2-4 cycles of software latency for minimum stack push (1-2 registers) in most actual ISRs, run at 20MHz, on AVR.

Both are quick enough for most situations.

Also, interrupt latency needs to be to calculated to the point where the execution has provided you the actual result you need quickly. Sometimes it's the first instruction in ISR (e.g., safety turn-off of a single signal, responding to an analog comparator event), sometimes it may be 10-20 instructions later (e.g., checking for the actual reason of the interrupt, then turning off several signals). Overall quick execution really helps here, as do more flexible GPIOs allowing resetting and setting any arbitrary number of bits on a PORT with a single register access, typical to modern ARM controllers.

[ogden]

http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  .

Complex RGB LED blinking patterns needs lots of fast PWM channels, CPU resources and memory  Also it seems that 21st century programming and regression testing culture requires firmware update for everything including LED lamps. True story: Logitech managed to release G613 keyboard and MK850 combo with very serious keyboard bug (lost Ctrl+keypress on wake-up). Only firmware update saved them from recall.

[GeorgeOfTheJungle]

What's wrong with DIP? Why there's no ARMs in DIP? Damn it.

[Mr. Scram]

http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  .

Not to mention that having excess resources on the microcontroller means more room for nefarious people to play with. Manipulating the keyboard firmware can be very interesting.

[coppice]

What's wrong with DIP? Why there's no ARMs in DIP? Damn it.

There are a few M0 parts with a DIP package option. Not many, but look around and you'll find some aimed at the white good market. Look hard enough and there might be the odd M3 or M4 part, aimed at the motor control market, offered in a DIP package.

[GeorgeOfTheJungle]

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

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

[rjp]

Cheap gumstick modules with all thr supporting passives appear to be the diy replacement.

[mariush]

There's some available in SOIC footprints, which have the pins spaced wide enough (1.27mm, half the regular 0.1" on proto boards) that you can even solder them directly on prototyping boards, or you can use very cheap SOIC to DIP adapter boards. They can be easily soldered by hand.

See for example SAM D10 series from Microchip ( https://www.digikey.com/product-detail/en/microchip-technology/ATSAMD10C13A-SSNT/ATSAMD10C13A-SSNTDKR-ND/5956614 )  or this Cypress stuff: https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8C4014SXI-420T/428-4129-6-ND/7401243

[ogden]

Cheap gumstick modules with all thr supporting passives appear to be the diy replacement.

Exactly. Bare DIP chip is not ready to run out of the box, the same apply to LQFP/SOIC ARM soldered on adapter. Apart from dirt-cheap & popular stm32 Blue Pill, there are many other breadboardable ARM boards:

https://os.mbed.com/platforms/?form-factor=6

[wraper]

http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  .

Complex RGB LED blinking patterns needs lots of fast PWM channels, CPU resources and memory  Also it seems that 21st century programming and regression testing culture requires firmware update for everything including LED lamps. True story: Logitech managed to release G613 keyboard and MK850 combo with very serious keyboard bug (lost Ctrl+keypress on wake-up). Only firmware update saved them from recall.

Well, You may need a beefy MCU. However it does not matter if it's 8051 or ARM or clock used as long as such product woks as intended. It's not like it gives more FPS on PC. About G613, I have it, they could not fix it for more than half a year since release. And when they released it, mine died during firmware update  . BTW it's not like it lost key press, any first press was registered as press- immediate release, thus key combinations failed.

[mikeselectricstuff]

Cheap gumstick modules with all thr supporting passives appear to be the diy replacement.

Exactly. Bare DIP chip is not ready to run out of the box, the same apply to LQFP/SOIC ARM soldered on adapter. Apart from dirt-cheap & popular stm32 Blue Pill, there are many other breadboardable ARM boards:

https://os.mbed.com/platforms/?form-factor=6

There are PIC32's in DIP with interla oscilator that just need power and a couple of caps to work.

[nctnico]

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

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

NXP still makes one with 28 pins!
https://www.nxp.com/part/LPC1114FN28
Actually this is quite a capable microcontroller. I'm using the QFN version in one of the projects I've done recently. And yes, these have an internal oscillator as well so with some bypass caps you are ready to roll.

[mikeselectricstuff]

Complex RGB LED blinking patterns needs lots of fast PWM channels,

No it doesn't - PWM doesn't scale well so you use use binary code modulation instead, all you need is the ability to turn on for a precise time - trivial if using external drivers using a compare peripheral, but also doable entirely in software with a little care

[Howardlong]

Add also that you may have to save even more on the stack if you use floating point. It gets very painful, very fast, and it’s not unusual to have to start disassembling and massaging the ISR code or modifiers accordingly. One problem with this approach is that your well meaning fiddling makes the code less maintainable when someone comes along withiut knowledge of your assumptions.

Personally I try hard to avoid being dependant on software when it comes down to nanosecond timing on a regular microcontroller because it is hard to achieve and hard to maintain. I guess these situations are likely originating from a hardware designer thinking 'they can fix this in software for sure'.

It’s not necessarily time critical scenarios, latency also has a significant overhead in repeatedly invoked ISRs, such as servicing a USB HS device  for example.

[FrankBuss]

NXP still makes one with 28 pins!
https://www.nxp.com/part/LPC1114FN28
Actually this is quite a capable microcontroller. I'm using the QFN version in one of the projects I've done recently. And yes, these have an internal oscillator as well so with some bypass caps you are ready to roll.

0 in stock at Digikey. This is a no-no. And I agree, easy to solder SOIC chips on cheap adapters.

[Kjelt]

Better to design your own small adapter board and add all the local jellybean stuff to get it working properly.

[ogden]

Complex RGB LED blinking patterns needs lots of fast PWM channels,

No it doesn't

Sure! Didn't I add ROFL smiley at the end of that quite obviously sarcastic sentence?

[ogden]

Exactly. Bare DIP chip is not ready to run out of the box, the same apply to LQFP/SOIC ARM soldered on adapter.

There are PIC32's in DIP with interla oscilator that just need power and a couple of caps to work.

Exactly - you still need power (plug + regulator), caps and so on. IMHO AVR is also such kind of animal and most likely there are other such MCU's as well. Anyway this is not as ready to run out of the box as boards in this list I mentioned before.

[GeorgeOfTheJungle]

NXP still makes one with 28 pins!
https://www.nxp.com/part/LPC1114FN28

Thanks nctnico, but what the $&%... can't find/buy it anywhere, must be made of unobtanium! :-)

[nctnico]

NXP still makes one with 28 pins!
https://www.nxp.com/part/LPC1114FN28

Thanks nctnico, but what the $&%... can't find/buy it anywhere, must be made of unobtanium! :-)

Newark says they have it available in the near future. Given the component shortages it doesn't surprise me. Try to buy 100nf 0603 capacitors... 

[langwadt]

NXP still makes one with 28 pins!
https://www.nxp.com/part/LPC1114FN28

Thanks nctnico, but what the $&%... can't find/buy it anywhere, must be made of unobtanium! :-)

Newark says they have it available in the near future. Given the component shortages it doesn't surprise me. Try to buy 100nf 0603 capacitors... 

digikey has plenty

[coppice]

What is the thing with DIP? Are they still being used by any mass produced products?
The only DIP chips I can still think of are DIP4 optocouplers and DIP8 integrated flyback SMPS chips.
For the sake of love, I've not used a DIP for years, literally years, besides student teaching projects.

PS. Also why TSSOP? They are harder to hand solder than DFN/QFN. The gull wing sucks and stores solder, so bridging happens all the time with short pad extension. With QFN, I can do 0.2mm extension per side and they still don't bridge.

If you want to use a single sided SRBP PCB, as many whites goods makers still do, DIPs are the prefered package.

[Mechatrommer]

What is the thing with DIP? Are they still being used by any mass produced products?
The only DIP chips I can still think of are DIP4 optocouplers and DIP8 integrated flyback SMPS chips.

besides SMPS PSU you mentioned that alone can count in millions, DIP are in gazillions in home appliances such as heater shower, water heater, refrigerator, air conditioning, toaster everything but highly densed electronics/computing related stuffs.

[nctnico]

If you want to use a single sided SRBP PCB, as many whites goods makers still do, DIPs are the prefered package.

Just use an SOP as a DIP. Fan out the pins and it's virtually a DIP, without the high package material cost and manual part insertion cost.

DIPs can be placed automatically for decades.

[wraper]

Modern single layer PCBs usually consist of largish SMT parts glued on the bottom including ICs and through hole parts and jumpers on the top. Like electrolytic capacitors, power semiconductors, optocouplers. All of it is wave soldered, no reflow. If it's simple circuit, it may be through hole only as well.

[wraper]

DIPs can be placed automatically for decades.

Don't think that's true for China, or maybe I'm wrong.
In my mind, automatic THT placement is expensive and prone to failure, way more expensive than SMT.

Automated through hole placement is slow and easy to screw up. I don't think it 100% of parts are automated even at places with machine placement.

[wraper]

Like here at 4:30, they machine place TH capacitors but other stuff is placed by hand.

https://youtu.be/ylk6VMBLrvM

[langwadt]

Modern single layer PCBs usually consist of largish SMT parts glued on the bottom including ICs and through hole parts and jumpers on the top. Like electrolytic capacitors, power semiconductors, optocouplers. All of it is wave soldered, no reflow. If it's simple circuit, it may be through hole only as well.

if it has bunch of big connectors you might have to do wave solder any way so going all through hole might same a few steps

[wraper]

Modern single layer PCBs usually consist of largish SMT parts glued on the bottom including ICs and through hole parts and jumpers on the top. Like electrolytic capacitors, power semiconductors, optocouplers. All of it is wave soldered, no reflow. If it's simple circuit, it may be through hole only as well.

if it has bunch of big connectors you might have to do wave solder any way so going all through hole might same a few steps

Nobody does reflow soldering on single layer phenolic PCBs to begin with. There is additional assembly step but PCB goes through soldering only one time.

[nctnico]

DIPs can be placed automatically for decades.

Don't think that's true for China, or maybe I'm wrong.
In my mind, automatic THT placement is expensive and prone to failure, way more expensive than SMT.

Automated through hole placement is slow and easy to screw up. I don't think it 100% of parts are automated even at places with machine placement.

I visited a TV manufacturing plant from Nokia in Germany in the early 90's and even back then they placed all through-hole components automatically. The machines would even detect a failure, pull the part back out (bin it) and re-insert a new one. I'd say those through hole placement machines where more impressive than those newfangled SMT p&p machines 
The SMT parts where glued to the solder side and the whole PCB would then go through the wave soldering machine.

[wraper]

I visited a TV manufacturing plant from Nokia in Germany in the early 90's and even back then they placed all through-hole components automatically. The machines would even detect a failure, pull the part back out (bin it) and re-insert a new one. I'd say those through hole placement machines where more impressive than those newfangled SMT p&p machines 
The SMT parts where glued to the solder side and the whole PCB would then go through the wave soldering machine.

That's probably one of the reasons why Nokia TVs are not made since 1996.

[coppice]

DIPs can be placed automatically for decades.

Don't think that's true for China, or maybe I'm wrong.
In my mind, automatic THT placement is expensive and prone to failure, way more expensive than SMT.

There are many automated THT lines in China.

THT placement has been cheap and highly reliable since DIP devices first appeared. That is why the design of the DIP package has the legs splayed. That was specifically so the machines could flex them in and they would spring back enough to secure the device until it reached the wave soldering station. Its why resistors and capacitors come on taped reels. The placement machines clip them out of the reel, form the legs, and stuff them into the board. In most cases the legs are left long. After the wave soldering step a really brutal looking machine slashes off the excess length of all these overly long legs in one operation.

For many years THT placement was much more reliable than SMT placement, as SMT placement is prone to things getting shaken out of place. The industry went through several generations of glue spot/don't glue spot/glue spot and other techniques before settling down to modern practices.This kind of thing is rarely a problem with automated THT lines.

[westfw]

Absolutely smallest and cheapest won't have core-coupled RAMs, of course.

If you meant the "Tightly Coupled Memory" (TCM) feature provided by ARM, that's an OPTION in CM7, not available at all in CM0 through CM4.  (According to the wikipedia table.  OTOH, the SAMD51 claims to have TCM, and the WP table also claims that M0, M3, M4 don't have cache, either.  While several data sheets claim to have simple caches.  (I assume that this is the difference between implementing the cache in the vendor-provided memory system vs using the ARM-provided IP.  In which case I don't know what Atmel/Microchip means by "TCM"...)
So, a very small number of ARM chips have TCM.Many ARM have RAM that is faster than their flash, and you can put code there if you want faster execution.  But we were talking more about determinism than raw speed, I thought.  (and "just put your critical code in executable RAM" is right up there with "just use bank select of you need more than 64k of data" - possible, but a bit contradictory with the the "simple" claims.)

[ogden]

Absolutely smallest and cheapest won't have core-coupled RAMs, of course.

If you meant the "Tightly Coupled Memory" (TCM) feature provided by ARM, that's an OPTION in CM7, not available at all in CM0 through CM4.

Indeed he did mean Core Coupled Memory (CCM). CCM is additional small RAM segment with own bus interface. STM32 F3 series have 8KB CCM RAM. Don't know about other manufacturers/chips. Actually useful for busy MCU's - CPU can fetch instruction or do whatever it pleases with CCM RAM while (during same clock cycle) DMA is doing transfers using main RAM.

More info about stm32 CCM here

[richardman]

Well, this post certainly wanders all over the place ;-)

[KL27x]

What is the thing with DIP? .... For the sake of love, I've not used a DIP for years, literally years, besides student teaching projects.

I bet by the time you used your first SMD chip, other people had been using them for years, literally years.

The reason, as far as the manufacturers are concerned, is because of branding/marketing/education. If some n00b chooses TI over Maxim IC because it comes in DIP, he might end up buying hundreds of thousands of (SMD) TI parts in the future, just because that's what he is familiar with. 

PS. Also why TSSOP? They are harder to hand solder than DFN/QFN. The gull wing sucks and stores solder, so bridging happens all the time with short pad extension. With QFN, I can do 0.2mm extension per side and they still don't bridge.

At least one practical reason is that QFN are more culpable to cracked solder joints due to board flex and/or thermal expansion/cycling. The difference has been tested. And regarding deep thermal cycling, apparently gull wing chips can be more than an order of magnitude better in some of these tests.

[ogden]

Well, this post certainly wanders all over the place ;-)

If you think something is wrong in that particular post - then provide correct information.

[edit] If you have problems using internet search engines to check keywords I did provide, you are welcome to read this document.

[Siwastaja]

Absolutely smallest and cheapest won't have core-coupled RAMs, of course.

If you meant the "Tightly Coupled Memory" (TCM) feature provided by ARM, that's an OPTION in CM7, not available at all in CM0 through CM4.

I don't know what any table says, and I'm not always exactly correct. But, I have been happily using fast core-coupled RAMs for timing critical and deterministic interrupt stuff in MCUs with CM3 and CM4 cores, and being non-existing or imaginary, I have measured them working remarkably well!

STM32F334 being one such example I can remember*. Clearly, it's ST's addition, and not the "ARM's option". The name is "CCM" for core-coupled memory instead of "TCM". This terminology is similarly irrelevant as is the classical discussion on "who's fault the bug is". I buy real MCU's based on what they offer and how they perform. An actual $3 ARM MCU offering me way better performance than a $3 8-bitter (including real-world interrupt latency, measured on real-world terms; I use oscillosscope to measure from trigger to result) and way better peripherals offloading the CPU even further, is the fact of reality, and as I have stated earlier, it has quite little to do with ARM exactly. IMHO, ARM core is boring enough not to be fanboy'ed over.

*) I did something similar on STM32F205 on its another extra SRAM, but it shares the bus and hence, heavy DMA traffic can cause a few clock cycles of jitter on interrupt latency during stack push, which is guaranteed 50% of bus arbitration cycles. Whether this is important, when the actual interrupt processing latency at 120MHz is still likely to be faster than on almost any 8-bitter, is up to you decide.

But yeah, I have also put a single quickly-needed instruction on the AVR's interrupt table directly, avoiding the delay of the jump. At 20MHz, this is very fast as well, and indeed will outperform a cheap M0 stacking registers through a bus also used by DMA. But most of the time, the timing-critical interrupts are longer than that, and the important result happens later than at the first machine instruction.

I mostly use the very cheapest 8-bitters only, but I guess most share this viewpoint nowadays; the "large $5 AVRs" make even less sense today than they made a decade ago.

[Mr. Scram]

I bet by the time you used your first SMD chip, other people had been using them for years, literally years.

The reason, as far as the manufacturers are concerned, is because of branding/marketing/education. If some n00b chooses TI over Maxim IC because it comes in DIP, he might end up buying hundreds of thousands of (SMD) TI parts in the future, just because that's what he is familiar with. 

At least one practical reason is that QFN are more culpable to cracked solder joints due to board flex and/or thermal expansion/cycling. The difference has been tested. And regarding deep thermal cycling, apparently gull wing chips can be more than an order of magnitude better in some of these tests.

I understood that QFN is actually one of the most reliable packages from a mechanical point of view. I think I read about this in a paper somewhere, but I don't think I'd be able to find that again. I stand to be corrected.

[Rerouter]

QFN is reliable, so long as you have soldermask spacing, e.g. not pad flat to copper with no gap for the solder, this gives it some distance to keep forces inside the elastic zone of deformation. similar to BGA, if you didn't have the balls at the right height they just rip pads off either the chip of the board when flexed,

Though I still see the center pad of QFN's a right pain to get right every time, you have to generally get weird with your paste masks to get better than 99.9% yields, which generally leads me to fitting a dot when its needed, vs a full pad,

[coppice]

PS. Also why TSSOP? They are harder to hand solder than DFN/QFN. The gull wing sucks and stores solder, so bridging happens all the time with short pad extension. With QFN, I can do 0.2mm extension per side and they still don't bridge.

At least one practical reason is that QFN are more culpable to cracked solder joints due to board flex and/or thermal expansion/cycling. The difference has been tested. And regarding deep thermal cycling, apparently gull wing chips can be more than an order of magnitude better in some of these tests.

The reliability of QFN mounting is quite variable. If people take the thermal stress issues seriously during soldering, as people normally do with BGA packages, results can be very good. if you fail to get things evenly heated during the soldering process you can get very poor results. So, don't expect most hand soldered QFNs to achieve wonderful reliability. The thermal expansion of the QFN package material has been chosen to be close to that of FR4. If you tried to use any other PCB material you might find reliability problems with QFNs.

[Nauris]

I visited a TV manufacturing plant from Nokia in Germany in the early 90's and even back then they placed all through-hole components automatically. The machines would even detect a failure, pull the part back out (bin it) and re-insert a new one. I'd say those through hole placement machines where more impressive than those newfangled SMT p&p machines 
The SMT parts where glued to the solder side and the whole PCB would then go through the wave soldering machine.

Yes, they are truly impressive, like the Panasonic AV132 puts components in like good old chip-shooter places chips at 30000 per hour or thereabout. They just appear on the board faster than eye can see!


These days there is also very much interest and growing market in the odd-form flexible thru-hole placement machines capable of placing anything from axial resistor on tape&reel to loose connectors or big transformers.
Like the new one from Fuji:
http://smt.fuji.co.jp/e/datas/movie/smartfab/Insertion(2).mp4
Or the Cencorp (Chinese-owned company by the way):

[wraper]

I visited a TV manufacturing plant from Nokia in Germany in the early 90's and even back then they placed all through-hole components automatically. The machines would even detect a failure, pull the part back out (bin it) and re-insert a new one. I'd say those through hole placement machines where more impressive than those newfangled SMT p&p machines 
The SMT parts where glued to the solder side and the whole PCB would then go through the wave soldering machine.

Yes, they are truly impressive, like the Panasonic AV132 puts components in like good old chip-shooter places chips at 30000 per hour or thereabout. They just appear on the board faster than eye can see!

It's nowhere near to fully automated TH component placement. All it places are axial parts with 2 leads like resistors.

[Bassman59]

Though I still see the center pad of QFN's a right pain to get right every time, you have to generally get weird with your paste masks to get better than 99.9% yields, which generally leads me to fitting a dot when its needed, vs a full pad,

The data sheets for QFN-with-pad parts recommend a pattern of small square holes in the paste mask for the pad instead of filling the whole pad. For example, Silicon Labs' Si5344 data sheet says to use a 3x3 array of 1.25 mm square cut-outs on 1.8 mm pitch. The pad itself is 5.2 mm square.

[Nauris]

Yes, they are truly impressive, like the Panasonic AV132 puts components in like good old chip-shooter places chips at 30000 per hour or thereabout. They just appear on the board faster than eye can see!

It's nowhere near to fully automated TH component placement. All it places are axial parts with 2 leads like resistors.

It needs bit more explanation, it seems. Automated thru-hole line consist of three kinds of machines. Typically there is first the axial component inserting machine (ex. AV132), after that comes the radial inserting machine placing radial components, like small electrolytics, film caps and such. Then at last there is one or usually more odd-form machines placing rest of components, like connectors, transformers, big electrolytics and such. That kind of line you would be using, if you were making thru-hole only boards.

Of course that is rarely case today, you usually have also smd machines inline and often no axial or radial inserter, but only a few odd-form machines handling the thru-hole component placement.

[westfw]

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, if you're going to end up using a relatively complex-to-use vendor-specific feature to get the job done.  On the other hand, writing timing-critical "needs every cycle" code for an 8bit chip isn't an easy task, either.  Just ... different.

[PCB.Wiz]

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

[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.

[JPortici]

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

dsPIC33EV is a 5V part, i use it in a lot of projects.. It needs 2 to 5 jumpers (depending on how may pins you are willing to sacrifice) to make it compatible with PIC18s, if you care about that.
But that doesn't matter, most new projects are going to be dsPIC33CH. sweet sweet dual core

About the PIC24 (KA)... I may still have PTSD, they were my very first 16bitter in high school and to this day i still have problems with them. And they are really "dumb" compared to the newer 8bitters, as you saw yourself.
Sure you have a core that's easier to deal with but the peripherals are just meh (to me)

[Howardlong]

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

dsPIC33EV is a 5V part, i use it in a lot of projects.. It needs 2 to 5 jumpers (depending on how may pins you are willing to sacrifice) to make it compatible with PIC18s, if you care about that.
But that doesn't matter, most new projects are going to be dsPIC33CH. sweet sweet dual core

About the PIC24 (KA)... I may still have PTSD, they were my very first 16bitter in high school and to this day i still have problems with them. And they are really "dumb" compared to the newer 8bitters, as you saw yourself.
Sure you have a core that's easier to deal with but the peripherals are just meh (to me)

Yes, you're right there a 5V parts too, but they need voltage regulators too, my point was around the additional BOM requirements for that: in single cell Li devices, you can forego that with these PIC24FxxKA/KL/KM devices. I regularly use the KM devices which are pretty well set up with peripherals, both analogue and digital. If you need to do a bit of number crunching, they are a reasonable solution, PIC16s are almost all weak in that area. A bonus was differential ADC, and dual DAC with external outputs: there are plenty of use cases for that dual output DAC, and no many microcontrollers offer them, especially with external outputs. I had discounted the PIC16 as I didn't think it would have the number crunching horse power, but with the PID accelerator my view changed. The math accelerator is a real PITA to learn how to use though!

[technix]

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

dsPIC33EV is a 5V part, i use it in a lot of projects.. It needs 2 to 5 jumpers (depending on how may pins you are willing to sacrifice) to make it compatible with PIC18s, if you care about that.
But that doesn't matter, most new projects are going to be dsPIC33CH. sweet sweet dual core

About the PIC24 (KA)... I may still have PTSD, they were my very first 16bitter in high school and to this day i still have problems with them. And they are really "dumb" compared to the newer 8bitters, as you saw yourself.
Sure you have a core that's easier to deal with but the peripherals are just meh (to me)

Yes, you're right there a 5V parts too, but they need voltage regulators too, my point was around the additional BOM requirements for that: in single cell Li devices, you can forego that with these PIC24FxxKA/KL/KM devices. I regularly use the KM devices which are pretty well set up with peripherals, both analogue and digital. If you need to do a bit of number crunching, they are a reasonable solution, PIC16s are almost all weak in that area. A bonus was differential ADC, and dual DAC with external outputs: there are plenty of use cases for that dual output DAC, and no many microcontrollers offer them, especially with external outputs. I had discounted the PIC16 as I didn't think it would have the number crunching horse power, but with the PID accelerator my view changed. The math accelerator is a real PITA to learn how to use though!

Single cell Li-po and 3.3V parts... That is a pain to design. So far my best bet is actually abusing a battery bank chip TP5410 into pushing out 4.7V regardless whether the power is connected or not (by default it switches the output off when external power is applied) then regulate it down to 3.3V using AMS1117, SPX3819 or TPS52200. I am not completely sure about those buck-boost chips and their current capability.

[SiliconWizard]

Single cell Li-po and 3.3V parts... That is a pain to design.

Yeah. I usually try and select parts that work down to 3V or below, and regulate the battery to this voltage with an LDO. (If you don't need your main 3V as a reference, you may even not regulate it at all, but in this case you have to use parts that can handle up to 4.2V, and 3.3V parts usually can't operate at above 3.6V, so that severly limits your options.) Most of my battery-operated designs are powered at 3V or even lower (if I can), such as 2.7V or 2.5V. So no need for a step-up regulator, which has two drawbacks: reduced efficiency obviously (especially at low currents) and a current draw on the battery that increases as the battery empties - which is often bad for the battery's life and may even damage it if not protected properly.

[westfw]

I don't understand the lack of love for that series [PIC24]

I think that in general, 16bit microcontrollers didn't get a lot of traction because the first "resource" that people were running out of was memory - either program memory or flash memory.  And the 16bit chips tended to have the same sorts of memory sizes and awkward bank switching schemes as the 8bit chips.  The sort of 256k/64k flash/ram configurations you can commonly get for cheap with a 32bit CPU is practically unheard of in the 8bit world (and somewhat unpleasant to use if you can find it.)
("because kids today write bloated code with bloated libraries to implemented bloated GUIs.   I remember when WordStar and MINCE would ...")

[maginnovision]

I used an avr8 with extra 128k sram to get 256k/64k(120k)rom/ram and with the XMM I/F it was completely transparent other than extra cycle to read/write to it.

[technix]

Single cell Li-po and 3.3V parts... That is a pain to design.

Yeah. I usually try and select parts that work down to 3V or below, and regulate the battery to this voltage with an LDO. (If you don't need your main 3V as a reference, you may even not regulate it at all, but in this case you have to use parts that can handle up to 4.2V, and 3.3V parts usually can't operate at above 3.6V, so that severly limits your options.) Most of my battery-operated designs are powered at 3V or even lower (if I can), such as 2.7V or 2.5V. So no need for a step-up regulator, which has two drawbacks: reduced efficiency obviously (especially at low currents) and a current draw on the battery that increases as the battery empties - which is often bad for the battery's life and may even damage it if not protected properly.

The battery bank chipset I used comes with both a linear charger (similar to TP4056) and a fixed 5V step-up regulator in one SOIC8-1EP package, I just need to give it a charge current control resistor, a power inductor and a Schottky diode to make it all work. It is rated for 1A maximum output current.

[Howardlong]

Single cell Li-po and 3.3V parts... That is a pain to design. So far my best bet is actually abusing a battery bank chip TP5410 into pushing out 4.7V regardless whether the power is connected or not (by default it switches the output off when external power is applied) then regulate it down to 3.3V using AMS1117, SPX3819 or TPS52200. I am not completely sure about those buck-boost chips and their current capability.

This was actually one of my applications: use the PIC as a switch mode charge regulator and low current power supply, as there wasn't a single device off the shelf that did what I wanted: gas gauge, charger, power supply. Having a device with a reasonably wide voltage range (2.0 to 5.5V for PIC24FV, 2.3 to 5.5V for PIC16F1xxx well suited to 5V (USB) Li charging, and running off the Li battery without external regulators. It did mean external MOSFETs though. The PIC16F161x has a pair of 100mA drive outputs, useful in lieu of gate drivers. I use a Cuk topology to allow an output voltage higher or lower than the Li source.

[Fungus]

So my question is - what are 8-bit uC still used for (in new designs).

Anything that runs off 5V.

As a hobbyst, is there still a point in using them

Of course. It's not all about price. 8 bits is still overkill for many, many jobs and can really simplify life.

[technix]

This was actually one of my applications: use the PIC as a switch mode charge regulator and low current power supply, as there wasn't a single device off the shelf that did what I wanted: gas gauge, charger, power supply. Having a device with a reasonably wide voltage range (2.0 to 5.5V for PIC24FV, 2.3 to 5.5V for PIC16F1xxx well suited to 5V (USB) Li charging, and running off the Li battery without external regulators. It did mean external MOSFETs though. The PIC16F161x has a pair of 100mA drive outputs, useful in lieu of gate drivers. I use a Cuk topology to allow an output voltage higher or lower than the Li source.

TP5410 is a combo charger and power supply, the only thing missing would be the gas gauge. That chip is actually a bit wasteful as it is a linear charger and a fixed 5V output non-synchronous boost converter combo, but for low cost applications there is little other options than TP5410 + resistor + inductor + two diodes.

Attached is the board photo of that power section: the SO-8 chip in the middle is TP5410, that and a few components around it makes the 3.3V power delivery section. The Li-po is on the back of the board. The input voltage to the AMS1117 is 4.V for USB power and 5V for battery power.

[GeorgeOfTheJungle]

Of course. It's not all about price. 8 bits is still overkill for many, many jobs and can really simplify life.

And 4 bits better yet...

[coppice]

Of course. It's not all about price. 8 bits is still overkill for many, many jobs and can really simplify life.

And 4 bits better yet...

4 bitters aren't so easy to get outside Japan these days.

[Fungus]

Of course. It's not all about price. 8 bits is still overkill for many, many jobs and can really simplify life.

And 4 bits better yet...

If it's enough, then, sure...

I don't know of many 4 bit chips though. Even the tiniest uC are 8 bits these days.

eg. https://www.microchip.com/wwwproducts/en/ATtiny4

[legacy]

16bit ... 68HC16 ... never seen, never used 

[coppice]

16bit ... 68HC16 ... never seen, never used 

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

[langwadt]

16bit ... 68HC16 ... never seen, never used 

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

they also have (had?) the coldfire which was also ~68k and the m.core which afair was very similar what ARM became with cortex and thumb2

[chickenHeadKnob]

Anything that runs off 5V.

Turning that around and looking at starting requirements from the other end of the telescope, what if you want true 5V outputs and not just 5V tolerant and must have 32 bit core?
I know of:
  Cypress PSOC4 arm cortex m0
  Cypress PSOC5 arm cortex m3
  Atmel/Microchip SAMC20 and 21     automotive series cortex m0+ these  additionally are one of the few mcu that have CAN FD

Are there any others? including obscure non-arm 32 bitters?

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

moto HC05. Yuck. Any youngling that still yearns for the 8 bit era should be forced, as I was, to program these register starved memory deficient craptastic things. That will cure you.

[coppice]

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

moto HC05. Yuck. Any youngling that still yearns for the 8 bit era should be forced, as I was, to program these register starved memory deficient craptastic things. That will cure you.

The HC05 was one of the most successful MCU families. It was a key part of what made Motorola the biggest MCU maker in the world.

[langwadt]

Anything that runs off 5V.

Turning that around and looking at starting requirements from the other end of the telescope, what if you want true 5V outputs and nott just 5V tolerant and must have 32 bit core?
I know of:
  Cypress PSOC4 arm cortex m0
  Cypress PSOC5 arm cortex m3
  Atmel/Microchip SAMC21     automotive series cortex m0 these are nice because additionally they are one of the few mcu that have CAN FD

Are there any others? including obscure non-arm 32 bitters?

afaik Freescale, now NXP, has a bunch of Cortex-M and PowerPC for automotive that are 5V supply and IO

[chickenHeadKnob]

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

moto HC05. Yuck. Any youngling that still yearns for the 8 bit era should be forced, as I was, to program these register starved memory deficient craptastic things. That will cure you.

The HC05 was one of the most successful MCU families. It was a key part of what made Motorola the biggest MCU maker in the world.

Oh I have first hand experience with the popularity part as well. Some time after Moto bought or merged with GM-Hughes the auto sector snarfed up all available supply and they went on allocation. Couldn't get one for love or money, almost sank/bankrupted  the small manufacturer I was working for.

[coppice]

Motorola developed two cores - the CPU16 (the core in the 68HC16) and the CPU32 (based on the 68000 core) - at the same time, intending to mix and match a set of modular peripherals and these two cores to suit a wide range of needs. It turned out most people were either OK with Motorola's existing HC05/HC08 or HC11 cores, or needed the performance of the CPU32.

moto HC05. Yuck. Any youngling that still yearns for the 8 bit era should be forced, as I was, to program these register starved memory deficient craptastic things. That will cure you.

The HC05 was one of the most successful MCU families. It was a key part of what made Motorola the biggest MCU maker in the world.

Oh I have first hand experience with the popularity part as well. Some time after Moto bought or merged with GM-Hughes the auto sector snarfed up all available supply and they went on allocation. Couldn't get one for love or money, almost sank/bankrupted  the small manufacturer I was working for.

That would have been around 1994 or 1995, right? The issue wasn't acquisitions. They badly screwed up resource allocation across the board. Sales grew faster than they could scale their factories. Efforts to use outside fabs hit many stumbling blocks. Combine this with the fact that the needs of Motorola communications always came first, and everything else a poor second. They had a lot of angry customers who really liked a Motorola chip but were suddenly unable to get quantities of it as they reached mass production. The backlash from this is a big part of why Motorola fell from their number 2 position in the semiconductor world.

[legacy]

[..] HC11 cores, or needed the performance of the CPU32.

Indeed all the boards I have seen in micro-robotics are boards are either hc11 (e.g. HB by MIT) or 683xx (e.g. MR by MIT); never seen hc16, but I know it existed. The question is ... who used it? And for what?

HC12 comes with a fuzzy-engine that is missing on both HC11 and 683XX, but the HC16 has it.

[chickenHeadKnob]

That would have been around 1994 or 1995, right? The issue wasn't acquisitions. They badly screwed up resource allocation across the board. Sales grew faster than they could scale their factories. Efforts to use outside fabs hit many stumbling blocks. Combine this with the fact that the needs of Motorola communications always came first, and everything else a poor second. They had a lot of angry customers who really liked a Motorola chip but were suddenly unable to get quantities of it as they reached mass production. The backlash from this is a big part of why Motorola fell from their number 2 position in the semiconductor world.

No a decade earlier, 1984-85. Not long after the plastic dip one-time programmable 6805 first came out. There were actually many boom-bust shortages with motorola, but the one that I was remembering was caused by auto makers starting to use  the parts big time.

[GeorgeOfTheJungle]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

[chickenHeadKnob]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

Only sort of contemporaneous, there were already  ECUs designed in 82 or so. Typically either an 8051 or intel 8096. I am reasonably certain the 8096 was designed initially for a Robert Bosch ECU. The first 8051 ECUs were not fast enough for control loop every revolution, instead had averaged control. I don't think anyone used a 6805 for engine control but could be wrong. It was the start of a massive influx of mcu's in other secondary control circuits, from radios to what-ever. The first antilock brakes were already common but the first generation was not done with digital control. It was some type of analog mechanical mechanism. Then Motorola came out with the 68xxx around 1986, can't remember the part number but it was the initial mcu that offered the crazy complicated 4 channel timer control unit,  before the first coldfires. The motorola  app-engineer taunted us in a seminar "guess what application and customer those timer channels are for"

[langwadt]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

Only sort of contemporaneous, there were already  ECUs designed in 82 or so. Typically either an 8051 or intel 8096. I am reasonably certain the 8096 was designed initially for a Robert Bosch ECU. The first 8051 ECUs were not fast enough for control loop every revolution, instead had averaged control. I don't think anyone used a 6805 for engine control but could be wrong. It was the start of a massive influx of mcu's in other secondary control circuits, from radios to what-ever. The first antilock brakes were already common but the first generation was not done with digital control. It was some type of analog mechanical mechanism. Then Motorola came out with the 68xxx around 1986, can't remember the part number but it was the initial mcu that offered the crazy complicated 4 channel timer control unit,  before the first coldfires. The motorola  app-engineer taunted us in a seminar "guess what application and customer those timer channels are for"

I think Motorola and GM did an ECU sometime in the mid 70's based on 6502

[coppice]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

Only sort of contemporaneous, there were already  ECUs designed in 82 or so. Typically either an 8051 or intel 8096. I am reasonably certain the 8096 was designed initially for a Robert Bosch ECU. The first 8051 ECUs were not fast enough for control loop every revolution, instead had averaged control. I don't think anyone used a 6805 for engine control but could be wrong. It was the start of a massive influx of mcu's in other secondary control circuits, from radios to what-ever. The first antilock brakes were already common but the first generation was not done with digital control. It was some type of analog mechanical mechanism. Then Motorola came out with the 68xxx around 1986, can't remember the part number but it was the initial mcu that offered the crazy complicated 4 channel timer control unit,  before the first coldfires. The motorola  app-engineer taunted us in a seminar "guess what application and customer those timer channels are for"

I think Motorola and GM did an ECU sometime in the mid 70's based on 6502

I doubt that Motorola used a 6502. Using any NMOS in the mid 70s was a big problem for a car engine. NMOS would only operate a few degrees below zero. It didn't take much cooling to make MPUs of the time, like the 6800 and 8085, crash. TI and others put a lot of effort into IIL versions of their processors, because it was a technology that worked over a wide temperature range. Eventually, the temperature range of MOS processes improved, but only a few suppliers, like Motorola and Hitachi, really got to grips with the qualification needs of the automotive industry. The cost structure of IIL was never really sorted out, and it quickly faded away.

[langwadt]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

Only sort of contemporaneous, there were already  ECUs designed in 82 or so. Typically either an 8051 or intel 8096. I am reasonably certain the 8096 was designed initially for a Robert Bosch ECU. The first 8051 ECUs were not fast enough for control loop every revolution, instead had averaged control. I don't think anyone used a 6805 for engine control but could be wrong. It was the start of a massive influx of mcu's in other secondary control circuits, from radios to what-ever. The first antilock brakes were already common but the first generation was not done with digital control. It was some type of analog mechanical mechanism. Then Motorola came out with the 68xxx around 1986, can't remember the part number but it was the initial mcu that offered the crazy complicated 4 channel timer control unit,  before the first coldfires. The motorola  app-engineer taunted us in a seminar "guess what application and customer those timer channels are for"

I think Motorola and GM did an ECU sometime in the mid 70's based on 6502

I doubt that Motorola used a 6502. Using any NMOS in the mid 70s was a big problem for a car engine. NMOS would only operate a few degrees below zero. It didn't take much cooling to make MPUs of the time, like the 6800 and 8085, crash. TI and others put a lot of effort into IIL versions of their processors, because it was a technology that worked over a wide temperature range. Eventually, the temperature range of MOS processes improved, but only a few suppliers, like Motorola and Hitachi, really got to grips with the qualification needs of the automotive industry. The cost structure of IIL was never really sorted out, and it quickly faded away.

6802

http://www.chipsetc.com/computer-chips-inside-the-car.html

[coppice]

That's the birth of ECUs, when cars were moving from carburetor to EFI.

Only sort of contemporaneous, there were already  ECUs designed in 82 or so. Typically either an 8051 or intel 8096. I am reasonably certain the 8096 was designed initially for a Robert Bosch ECU. The first 8051 ECUs were not fast enough for control loop every revolution, instead had averaged control. I don't think anyone used a 6805 for engine control but could be wrong. It was the start of a massive influx of mcu's in other secondary control circuits, from radios to what-ever. The first antilock brakes were already common but the first generation was not done with digital control. It was some type of analog mechanical mechanism. Then Motorola came out with the 68xxx around 1986, can't remember the part number but it was the initial mcu that offered the crazy complicated 4 channel timer control unit,  before the first coldfires. The motorola  app-engineer taunted us in a seminar "guess what application and customer those timer channels are for"

I think Motorola and GM did an ECU sometime in the mid 70's based on 6502

I doubt that Motorola used a 6502. Using any NMOS in the mid 70s was a big problem for a car engine. NMOS would only operate a few degrees below zero. It didn't take much cooling to make MPUs of the time, like the 6800 and 8085, crash. TI and others put a lot of effort into IIL versions of their processors, because it was a technology that worked over a wide temperature range. Eventually, the temperature range of MOS processes improved, but only a few suppliers, like Motorola and Hitachi, really got to grips with the qualification needs of the automotive industry. The cost structure of IIL was never really sorted out, and it quickly faded away.

6802

http://www.chipsetc.com/computer-chips-inside-the-car.html

That page says they deployed the ECU in 1981. That was about the time when MOS parts specified down to -40C or -55C were getting to volume production.

[PCB.Wiz]

Turning that around and looking at starting requirements from the other end of the telescope, what if you want true 5V outputs and not just 5V tolerant and must have 32 bit core?
I know of:
  Cypress PSOC4 arm cortex m0
  Cypress PSOC5 arm cortex m3
  Atmel/Microchip SAMC20 and 21     automotive series cortex m0+ these  additionally are one of the few mcu that have CAN FD

Are there any others? including obscure non-arm 32 bitters?

Sure, but not nearly as wide a choice as 3v.
Fujitsu  (now part of Cypress)  had some 5V ARM, Freescale do a few 5V ARM, and Nuvoton have a wide selection, including 5v M4 parts, Infineon have 5V in M0 parts, and numerous Asian vendors have 5V ARMs in their stables.

Nuvoton also do one of the best-value/cheapest 8 bitters in the N76E003  ~ 25c, for 18k Flash, 1KRAM 12b ADC  16MHz

[Psi]

If there's still a need for 4 bit micros in cheap electronics (which there is) then there's definitely still a need for faster 8 bit micros. 

[Kjelt]

Sure in toys costing $2 sales price or perhaps some chinese dimmable ledlamps, they have 4 bit uC in them costing $0,08 in large quantities.
Silly but yes every micro you can buy in the official retail chain today still has its market somewhere, if not it will dissapear.

[Fungus]

Anything that runs off 5V.

Turning that around and looking at starting requirements from the other end of the telescope, what if you want true 5V outputs and not just 5V tolerant and must have 32 bit core?

I really don't see the relevance of the number of bits in the core.   

Has it got enough pins/timers/serial/I2c/whatever? Use it.

[nctnico]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

[wraper]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

If you mix analog and digital, or for directly driving MOSFET gates it can be quite useful. Or when directly powered from lithium battery.

[analogo]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

The whole world because of USB?

[coppice]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

For noisy environments, like automotive, white goods and motor control, 3.6V and lower voltage designs are much less robust that a similar 5V design would be. Most new designs do use lower voltages, because the designers have little choice. They don't like it, though, and they end up with longer design cycles trying to get their designs rock solid.

[nctnico]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

The whole world because of USB?

But you wouldn't use 5V USB power directly anyway because the cables and connectors can have a significant voltage drop. Using an LDO to get to 3.3V is a much safe bet.

[wraper]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

The whole world because of USB?

But you wouldn't use 5V USB power directly anyway because the cables and connectors can have a significant voltage drop. Using an LDO to get to 3.3V is a much safe bet.

Most modern "5V" MCUs can work in wide voltage range. Therefore it's a non issue.

[Fungus]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

"5V" AVR chips (for example) work down to 1.8V, no problem. Use 3.3V if you want to. 

[KL27x]

I understood that QFN is actually one of the most reliable packages from a mechanical point of view. I think I read about this in a paper somewhere, but I don't think I'd be able to find that again. I stand to be corrected.

Wraper might have more info on this. I googled it after he claimed that you want to "float" a QFN off the board while hand-soldering on a specific thickness of solder because of thermal cycling. The first study/paper I found showed that QFN could have MTF of only 3000 cycles of going from something stupid like -30C to 100C. QFP might have MTF of 30,000 in same test. Also it was dependent on how big the die is compared to the package size, since the epoxy in the chip has a coefficient of expansion fairly similar to FR-4. So a tiny die would be better able to withstand flex from temp change in a given package size. And if you follow that logic, any QFN available in two different sizes, the larger might be more robust in this regard.

QFN is reliable, so long as you have soldermask spacing, e.g. not pad flat to copper with no gap for the solder, this gives it some distance to keep forces inside the elastic zone of deformation. similar to BGA, if you didn't have the balls at the right height they just rip pads off either the chip of the board when flexed

The study I read about it said the exact opposite at least for thermal expansion/contraction. Any soldermask under the chip will expand/contract at a different rate and will put stress on the joints, shortening MTF from thermal cycles.

As far as board flex, maybe you are right. That the more the solder thickness/height the better, and soldermask would not be an issue in absence of extreme temp cycling.

[nctnico]

@Fungus:
Did you actually try to use a 1.8V Atmel device at 1.8V? I know for a fact it won't work reliable because it is the absolute minimum voltage. A few tens of millivolts less and you'll see devices starting to fail in subtile ways. Also do you want to run a microcontroller circuit from a wildly varying supply voltage? Sounds like a recipy for dissaster to me.

From my experience a very good design rule is not to use external voltages directly for supplying (digital) circuits because you never know what may happen to them. Better generate all supply voltages on the same board.

[Fungus]

@Fungus:
Did you actually try to use a 1.8V Atmel device at 1.8V? I know for a fact it won't work reliable because it is the absolute minimum voltage.

Never done it myself but I've run plenty of them off CR2032s (which can easily dip down to 2.0V under any load).

A few tens of millivolts less and you'll see devices starting to fail in subtile ways.

Are you sure you had the 'V' designated chips? If it's really a problem then aim for 1.9V, sorted.

My only point was that calling it a 5V part is incorrect. That's only the maximum.

[wraper]

@Fungus:
Did you actually try to use a 1.8V Atmel device at 1.8V? I know for a fact it won't work reliable because it is the absolute minimum voltage. A few tens of millivolts less and you'll see devices starting to fail in subtile ways. Also do you want to run a microcontroller circuit from a wildly varying supply voltage? Sounds like a recipy for dissaster to me.

First of all, it's not that "wildly varying" and secondly there is a huge margin on the bottom side.

[nctnico]

@Fungus:
Did you actually try to use a 1.8V Atmel device at 1.8V? I know for a fact it won't work reliable because it is the absolute minimum voltage. A few tens of millivolts less and you'll see devices starting to fail in subtile ways. Also do you want to run a microcontroller circuit from a wildly varying supply voltage? Sounds like a recipy for dissaster to me.

First of all, it's not that "wildly varying" and secondly there is a huge margin on the bottom side.

Wiggle a poor/bad connector a little bit and you'll see a lot of spikes on the supply. What will happen with the logic levels between two chips on that board?

[wraper]

@Fungus:
Did you actually try to use a 1.8V Atmel device at 1.8V? I know for a fact it won't work reliable because it is the absolute minimum voltage. A few tens of millivolts less and you'll see devices starting to fail in subtile ways. Also do you want to run a microcontroller circuit from a wildly varying supply voltage? Sounds like a recipy for dissaster to me.

First of all, it's not that "wildly varying" and secondly there is a huge margin on the bottom side.

Wiggle a poor/bad connector a little bit and you'll see a lot of spikes on the supply. What will happen with the logic levels between two chips on that board?

What about spikes on data pins? Power is at least decoupled.

[PCB.Wiz]

BTW: who is still making 5V designs nowadays anyway? Seems more like an old habit than a necessity.

Those little guys, called Car Manufacturers ?
Anyone who needs to drive a Power MOSFET to a decent low resistance ?
Everyone plugging into USB, as mentioned above...

As above, note all the MCUs released these days are not '5V' but Wide Vcc and they include 5V because there is significant demand for it.

eg XMEGA were 3v3 only, and that was a serious drawback in the generic MCU space. Thus XMEGA has faded.

[Mr. Scram]

I guess that after 14 paged the conclusion is that there is a point to 8 bit microcontrollers.

[brucehoult]

I guess that after 14 paged the conclusion is that there is a point to 8 bit microcontrollers.

For sufficiently low-performance applications (of which there are untold number), what reasonable person could say otherwise?

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

In any *other* bitness for CPUs -- 16, 32, 64, 128 -- the reference number is the size of the directly-accessible address space and therefore of any registers that hold addresses, including the Program Counter.

The traditional 1970s "8 bit" processors *all* had at least some 16 bit registers internally and almost all brought out a full 16 bit address bus on their packages e.g. 2650, 8080, z80, 6800, 6502, 8051. The SC/MP only brought out a 12 bit address bus but it had a 16 bit PC and three 16 bit pointer registers and A12-A15 were multiplexed onto the data bus. The RCA 1802 had 16 registers of 16 bits each and a 16 bit address space, and it multiplexed the 16 bit addresses onto two phases of an 8 bit address bus.

[coppice]

I guess that after 14 paged the conclusion is that there is a point to 8 bit microcontrollers.

For sufficiently low-performance applications (of which there are untold number), what reasonable person could say otherwise?

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

In any *other* bitness for CPUs -- 16, 32, 64, 128 -- the reference number is the size of the directly-accessible address space and therefore of any registers that hold addresses, including the Program Counter.

The traditional 1970s "8 bit" processors *all* had at least some 16 bit registers internally and almost all brought out a full 16 bit address bus on their packages e.g. 2650, 8080, z80, 6800, 6502, 8051. The SC/MP only brought out a 12 bit address bus but it had a 16 bit PC and three 16 bit pointer registers and A12-A15 were multiplexed onto the data bus. The RCA 1802 had 16 registers of 16 bits each and a 16 bit address space, and it multiplexed the 16 bit addresses onto two phases of an 8 bit address bus.

Even 4 bit processors have at least 10 bits of program counter. The key thing is the software can only count to 15.

[brucehoult]

I guess that after 14 paged the conclusion is that there is a point to 8 bit microcontrollers.

For sufficiently low-performance applications (of which there are untold number), what reasonable person could say otherwise?

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

In any *other* bitness for CPUs -- 16, 32, 64, 128 -- the reference number is the size of the directly-accessible address space and therefore of any registers that hold addresses, including the Program Counter.

The traditional 1970s "8 bit" processors *all* had at least some 16 bit registers internally and almost all brought out a full 16 bit address bus on their packages e.g. 2650, 8080, z80, 6800, 6502, 8051. The SC/MP only brought out a 12 bit address bus but it had a 16 bit PC and three 16 bit pointer registers and A12-A15 were multiplexed onto the data bus. The RCA 1802 had 16 registers of 16 bits each and a 16 bit address space, and it multiplexed the 16 bit addresses onto two phases of an 8 bit address bus.

Even 4 bit processors have at least 10 bits of program counter. The key thing is the software can only count to 15.

As long as you've got either AND or OR plus NOT (possibly combined e.g. NAND), or the ability to test and branch based on a bit, even a 1-bit ALU lets software count to or add/sub/mul/div as large numbers as there are bits of memory to store.

Slowly.

But you still need a decent address space, especially for the program.

[NorthGuy]

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

PIC10F320

[Mr. Scram]

For sufficiently low-performance applications (of which there are untold number), what reasonable person could say otherwise?

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

In any *other* bitness for CPUs -- 16, 32, 64, 128 -- the reference number is the size of the directly-accessible address space and therefore of any registers that hold addresses, including the Program Counter.

The traditional 1970s "8 bit" processors *all* had at least some 16 bit registers internally and almost all brought out a full 16 bit address bus on their packages e.g. 2650, 8080, z80, 6800, 6502, 8051. The SC/MP only brought out a 12 bit address bus but it had a 16 bit PC and three 16 bit pointer registers and A12-A15 were multiplexed onto the data bus. The RCA 1802 had 16 registers of 16 bits each and a 16 bit address space, and it multiplexed the 16 bit addresses onto two phases of an 8 bit address bus.

Are we going for the "No true Schotsman" now?

[brucehoult]

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

PIC10F320

11 bit program address space, and the PC itself is 9 bits within a page. That's architecture. True, that particular chip only has 256 words of program space implemented, but you could always do that with an 8080 or 6502 too, if you wanted (and it was common to do so with the 1802).

Going back further, the PDP8 of course had a 12 bit address space and crude banking to extend it, very similar to PIC.

[NorthGuy]

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

PIC10F320

11 bit program address space, and the PC itself is 9 bits within a page. That's architecture. True, that particular chip only has 256 words of program space implemented, but you could always do that with an 8080 or 6502 too, if you wanted (and it was common to do so with the 1802).

Going back further, the PDP8 of course had a 12 bit address space and crude banking to extend it, very similar to PIC.

You mean ISA address bus? I wouldn't single out 8-bitters. The mismatch is rather common:

16-bit 8086 had 20-bit address bus, PIC24 has 23-bit address bus.

Or the other way around:

32-bit MIPS has 29-bit address bus, 64-bit ARM has 48-bit address bus, x64 has 48-bit address bus.

[brucehoult]

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

PIC10F320

11 bit program address space, and the PC itself is 9 bits within a page. That's architecture. True, that particular chip only has 256 words of program space implemented, but you could always do that with an 8080 or 6502 too, if you wanted (and it was common to do so with the 1802).

Going back further, the PDP8 of course had a 12 bit address space and crude banking to extend it, very similar to PIC.

You mean ISA address bus? I wouldn't single out 8-bitters. The mismatch is rather common:

16-bit 8086 had 20-bit address bus, PIC24 has 23-bit address bus.

Or the other way around:

32-bit MIPS has 29-bit address bus, 64-bit ARM has 48-bit address bus, x64 has 48-bit address bus.

No, not address bus. That's irrelevant and changes frequently between software compatible processors. It's the size of the registers that counts, in particular the PC and registers used as data pointers.

[westfw]

Usually architectures are ranked by the apparent size of their ALU.  ("apparent", because it seems like the Z80 had a 4bit ALU, and just always did at least two operations...)
I'd rate the 8bit PICs (PIC16f...) as true 8bit architectures.  8bit ALU, 8bit register(s), less than 8bit address space for data (until you add the banking.)  The PC and instruction word are wider, but "Harvard architecture", so those are pretty separate from everything else.  (and the baseline PICs with essentually 9bit PCs (plus another bank) and only 8 bits of address in a "call" instruction!)

5V designs

not been mentioned yet: Toshiba has some pretty substantial CM3 ARM chips that will run on 5V.
The NXP ones are the "Kinetis E" series.So they're not uncommon.  I think the surprising bit is that none of the "hobbyist" vendors (Arduino, Adafruit, Sparkfun, PJRC, etc) seems to have jumped on any of the 5V 32bit cpus...

[JPortici]

i bet that's because you can't get them for peanuts in china

[technix]

Usually architectures are ranked by the apparent size of their ALU.  ("apparent", because it seems like the Z80 had a 4bit ALU, and just always did at least two operations...)
I'd rate the 8bit PICs (PIC16f...) as true 8bit architectures.  8bit ALU, 8bit register(s), less than 8bit address space for data (until you add the banking.)  The PC and instruction word are wider, but "Harvard architecture", so those are pretty separate from everything else.  (and the baseline PICs with essentually 9bit PCs (plus another bank) and only 8 bits of address in a "call" instruction!)

How would you call a configurable soft processor that has 16-bit registers and program counter but selectable 8-bit or 16-bit ALU? (SBT-16 core)

How would you call a processor with aligned 64-bit registers and program counter, fixed 32-bit instruction length, registers that are addressable down to byte level, and an ALU that has control signals allowing it to be broken into shorter units for SIMD? (for example add.q b1,b2,b3 treats data in registers q2 and q3 each as 8 individual bytes, and put the 8 separate sums into q1.)

5V designs

not been mentioned yet: Toshiba has some pretty substantial CM3 ARM chips that will run on 5V.
The NXP ones are the "Kinetis E" series.So they're not uncommon.  I think the surprising bit is that none of the "hobbyist" vendors (Arduino, Adafruit, Sparkfun, PJRC, etc) seems to have jumped on any of the 5V 32bit cpus...

[coppice]

I guess that after 14 paged the conclusion is that there is a point to 8 bit microcontrollers.

For sufficiently low-performance applications (of which there are untold number), what reasonable person could say otherwise?

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

In any *other* bitness for CPUs -- 16, 32, 64, 128 -- the reference number is the size of the directly-accessible address space and therefore of any registers that hold addresses, including the Program Counter.

The traditional 1970s "8 bit" processors *all* had at least some 16 bit registers internally and almost all brought out a full 16 bit address bus on their packages e.g. 2650, 8080, z80, 6800, 6502, 8051. The SC/MP only brought out a 12 bit address bus but it had a 16 bit PC and three 16 bit pointer registers and A12-A15 were multiplexed onto the data bus. The RCA 1802 had 16 registers of 16 bits each and a 16 bit address space, and it multiplexed the 16 bit addresses onto two phases of an 8 bit address bus.

Even 4 bit processors have at least 10 bits of program counter. The key thing is the software can only count to 15.

As long as you've got either AND or OR plus NOT (possibly combined e.g. NAND), or the ability to test and branch based on a bit, even a 1-bit ALU lets software count to or add/sub/mul/div as large numbers as there are bits of memory to store.

Slowly.

But you still need a decent address space, especially for the program.

4 bit MCUs were an excellent choice for many early MCU applications, because so many applications wanted them to behave as decimal machines (e.g. in calculators). They only really needed to count up to nine. If you've ever had access to much source code for applications on the TMS1000 (the first successful MCU), its surprising how often applications like shower heaters, and toaster controllers, where there was no decimal UI, made the chip mimic a BCD machine.

Single bit cores were an excellent choice for high throughput machines, like the MPP, when you could distribute a single program to a huge number of 1 bit cores. As propagation delays began to dominate over switching times, that no longer really worked.

[Fungus]

Usually architectures are ranked by the apparent size of their ALU.  ("apparent", because it seems like the Z80 had a 4bit ALU, and just always did at least two operations...)
I'd rate the 8bit PICs (PIC16f...) as true 8bit architectures.  8bit ALU, 8bit register(s), less than 8bit address space for data (until you add the banking.)  The PC and instruction word are wider, but "Harvard architecture", so those are pretty separate from everything else.  (and the baseline PICs with essentually 9bit PCs (plus another bank) and only 8 bits of address in a "call" instruction!)

How would you call a configurable soft processor that has 16-bit registers and program counter but selectable 8-bit or 16-bit ALU? (SBT-16 core)

If it has 16-bit registers and a 16-bit ADD instruction then it's 16 bit.

[NorthGuy]

I do note however that I never saw what I would call a true 8 bit processor -- they are all 8/16 hybrid designs with 8 bit ALUs and some 8 bit and some 16 bit registers.

PIC10F320

11 bit program address space, and the PC itself is 9 bits within a page. That's architecture. True, that particular chip only has 256 words of program space implemented, but you could always do that with an 8080 or 6502 too, if you wanted (and it was common to do so with the 1802).

Going back further, the PDP8 of course had a 12 bit address space and crude banking to extend it, very similar to PIC.

You mean ISA address bus? I wouldn't single out 8-bitters. The mismatch is rather common:

16-bit 8086 had 20-bit address bus, PIC24 has 23-bit address bus.

Or the other way around:

32-bit MIPS has 29-bit address bus, 64-bit ARM has 48-bit address bus, x64 has 48-bit address bus.

No, not address bus. That's irrelevant and changes frequently between software compatible processors. It's the size of the registers that counts, in particular the PC and registers used as data pointers.

PIC10F320 has 8-bit PC (PCL register @0x02) and 8-bit data pointer (FSR register @0x04).

The only way where there might be some extra space is the code for GOTO instruction, which has room for 11 bits, bit only 8 bits are used.

[brucehoult]

Usually architectures are ranked by the apparent size of their ALU.  ("apparent", because it seems like the Z80 had a 4bit ALU, and just always did at least two operations...)
I'd rate the 8bit PICs (PIC16f...) as true 8bit architectures.  8bit ALU, 8bit register(s), less than 8bit address space for data (until you add the banking.)  The PC and instruction word are wider, but "Harvard architecture", so those are pretty separate from everything else.  (and the baseline PICs with essentually 9bit PCs (plus another bank) and only 8 bits of address in a "call" instruction!)

How would you call a configurable soft processor that has 16-bit registers and program counter but selectable 8-bit or 16-bit ALU? (SBT-16 core)

If it has 16-bit registers and a 16-bit ADD instruction then it's 16 bit.

z80 has some 16 bit registers and 16 bit add instructions.  Specifically, you can add any of BC/DE/SP to any of HL/IX/IY, or add HL/IX/IY to themselves.

And yet the z80 is commonly referred to as an 8 bit processor. Which is my original point: the so-called 8 bit processors were all 8/16 bit hybrids. (except the very smallest PICs. I'll give them that)

[Fungus]

z80 has some 16 bit registers and 16 bit add instructions.  Specifically, you can add any of BC/DE/SP to any of HL/IX/IY, or add HL/IX/IY to themselves. And yet the z80 is commonly referred to as an 8 bit processor.

What you're describing is what we call "CISC" - the Z80 was a "Complex Instruction Set" design, not a "hybrid".

The clue is in the fact that "ADD A,L" takes 4 clock cycles but "ADD HL,DE" takes 15.

Internally it's all 8 bits but it can perform a sequence of operations for a single instruction.

The Z80 even has instructions that enter an internal loop and repeat a sequence a specified number of times while counting down a register, that's pure CISC.

(and, yes, you can unroll those loops for speed...  )

Bottom line: The Z80 is 8-bit.

the so-called 8 bit processors were all 8/16 bit hybrids. (except the very smallest PICs. I'll give them that)

There was nothing 16-bit about (eg.) a MOS 6502.

[brucehoult]

z80 has some 16 bit registers and 16 bit add instructions.  Specifically, you can add any of BC/DE/SP to any of HL/IX/IY, or add HL/IX/IY to themselves. And yet the z80 is commonly referred to as an 8 bit processor.

What you're describing is what we call "CISC" - the Z80 was a "Complex Instruction Set" design, not a "hybrid".

The clue is in the fact that "ADD A,L" takes 4 clock cycles but "ADD HL,DE" takes 15.

Internally it's all 8 bits but it can perform a sequence of operations for a single instruction.

That's one particular implementation. You could build a new implementation of the z80 instruction set today that did both 8 bit and 16 bit operations in 1 clock cycle.

The common z80 chip is an implementation of an 8/16 bit instruction set that internally uses an 8 bit ALU. (Someone in this thread said it actually uses a 4 bit ALU! Maybe .. I really don't know.)

the so-called 8 bit processors were all 8/16 bit hybrids. (except the very smallest PICs. I'll give them that)

There was nothing 16-bit about (eg.) a MOS 6502.

Addresses are 16 bits. The PC is 16 bits. You can store 16 bit pointers in two consecutive memory locations in zero page and with a single LDA (zp),Y instruction fetch them into an internal unnamed 16 bit register, add the Y register to that register (*with* carry between pages), and use that register as the address of a byte to load (or store, or add etc).

[Fungus]

Internally it's all 8 bits but it can perform a sequence of operations for a single instruction.

That's one particular implementation. You could build a new implementation of the z80 instruction set today that did both 8 bit and 16 bit operations in 1 clock cycle.

It's the implementation that we all used, and the chips that we did it with were 8-bit chips.

There was nothing 16-bit about (eg.) a MOS 6502.

Addresses are 16 bits. The PC is 16 bits. You can store 16 bit pointers in two consecutive memory locations in zero page and with a single LDA (zp),Y instruction fetch them into an internal unnamed 16 bit register, add the Y register to that register (*with* carry between pages), and use that register as the address of a byte to load (or store, or add etc).

16-bit PC doesn't mean 16 bit processing. The "LDA (zp),Y" instruction is a bit of CISC.

nb. Nobody used "LDA (zp),Y" because it was too slow, we preferred self-modifying code instead (modify an "LDA absolute,Y" instruction).

[brucehoult]

nb. Nobody used "LDA (zp),Y" because it was too slow, we preferred self-modifying code instead (modify an "LDA absolute,Y" instruction).

Woz used the (zp),Y addressing mode five times in SWEET16, widely acknowledged as some of the best 300 bytes of 6502 code (not to mention one of the best bytecode interpreters) you'll find anywhere.

http://www.6502.org/source/interpreters/sweet16.htm#The_Story_of_Sweet_Sixteen

Self-modifying code was useful for memcpy() or something like that. Not for normal programs.

[technix]

Usually architectures are ranked by the apparent size of their ALU.  ("apparent", because it seems like the Z80 had a 4bit ALU, and just always did at least two operations...)
I'd rate the 8bit PICs (PIC16f...) as true 8bit architectures.  8bit ALU, 8bit register(s), less than 8bit address space for data (until you add the banking.)  The PC and instruction word are wider, but "Harvard architecture", so those are pretty separate from everything else.  (and the baseline PICs with essentually 9bit PCs (plus another bank) and only 8 bits of address in a "call" instruction!)

How would you call a configurable soft processor that has 16-bit registers and program counter but selectable 8-bit or 16-bit ALU? (SBT-16 core)

If it has 16-bit registers and a 16-bit ADD instruction then it's 16 bit.

SBT-16 has 16-bit registers which are byte addressable for narrower instructions, and its ALU instruction can do 16-bit single, 8-bit single or 8-bit x2 SIMD. Is it 8-bit or is it 16-bit?

SBT-64 has 64-bit registers which are aligned 4-byte, 2-byte or byte addressable for narrower instructions , and its ALU instructions can do 64-bit single, 32-bit single, 16-bit single, 8-bit single, 32bit x2 SIMD, 16-bit x2 SIMD, 16-bit x4 SIMD, 8-bit x2 SIMD, 8-bit x4 SIMD or 8-bit x8 SIMD. Is it 8-bit 16-bit, 32-bit or 64-bit?

[Fungus]

Woz used the (zp),Y addressing mode five times in SWEET16, widely acknowledged as some of the best 300 bytes of 6502 code (not to mention one of the best bytecode interpreters) you'll find anywhere.

Argument from authority? 

a) It fits the job really well in that instance, and
b) It was in ROM - no self-modifying code possible! 
c) Note that it's a "solution to the problem of handling 16 bit data, notably pointers, with an 8 bit microprocessor" )

PS: I met Woz a couple of years back. 

[Fungus]

SBT-16 has 16-bit registers which are byte addressable for narrower instructions, and its ALU instruction can do 16-bit single, 8-bit single or 8-bit x2 SIMD. Is it 8-bit or is it 16-bit?

Figure it out by yourself! There's enough information in this thread for you to do so. 

[brucehoult]

Woz used the (zp),Y addressing mode five times in SWEET16, widely acknowledged as some of the best 300 bytes of 6502 code (not to mention one of the best bytecode interpreters) you'll find anywhere.

Argument from authority? 

a) It fits the job really well in that instance, and
b) It was in ROM - no self-modifying code possible! 
c) Note that it's a "solution to the problem of handling 16 bit data, notably pointers, with an 8 bit microprocessor" )

PS: I met Woz a couple of years back. 

Pretty sure Woz was capable of copying a small loop into RAM in ZP or page 3 if he wanted to.

This whole thread started with the observation that by modern definitions as N-bit ISA is one which has N-bit pointers and the only exception to this is that the so-called 8 bit processors actually had 16 bit pointers.

I have a card (ticket for a breakfast at which they were the star guests) Woz and Hertzfeld signed for me in Wellington NZ in 1986.

[technix]

SBT-16 has 16-bit registers which are byte addressable for narrower instructions, and its ALU instruction can do 16-bit single, 8-bit single or 8-bit x2 SIMD. Is it 8-bit or is it 16-bit?

Figure it out by yourself! There's enough information in this thread for you to do so. 

To my eyes SBT-16 is a genuine 16-bit processor, and SBT-64 is a genuine 64-bit processor. What I feel here is that people is getting program counter length, data register length and ALU length confused, so I threw those SIMD-heavy processors to get some clarifications.

[legacy]

=
confused

oh, well, confusion is the white noise background I have got with every MIPS64 support packages I have worked on, where I have always had to understand *what* they meant with "pointer" since sometimes they were defined 64bit in the doc of the BSP, but sometimes 32bit in the definition files, a complete mess 

[Fungus]

This whole thread started with the observation that by modern definitions as N-bit ISA is one which has N-bit pointers and the only exception to this is that the so-called 8 bit processors actually had 16 bit pointers.

That wouldn't be my definition at all. To me it's about the ALU and data processing, not the width of the address bus.

Having less wires going into the ALU directly affects processing power and speed of execution, having more or less address lines makes no difference at all.

the only exception to this is that the so-called 8 bit processors actually had 16 bit pointers.

Not true. The 8086/80286 had 16-bit registers, 16-bit ALU and 20-bit pointers (22-bit pointers on the 80286 IIRC).

Plus: Many, many 32 and 64 bit processors don't have the same number of address lines as bits in the address registers. eg. Are the Motorola 68000 and Intel 80386 24-bit processors? I don't think you'll find many people arguing that case.

[Fungus]

There's another argument that it should be the size of the data bus but there's quite a few chips that had a half-size data bus to make the system cheaper to build.

eg. Intel 8088, Motorola 68008.

Those chips need to do two separate reads for every 16-bit memory access that the "full-width" versions do.

Both those chips are classed as 16-bit so that's not it, either.

[technix]

There's another argument that it should be the size of the data bus but there's quite a few chips that had a half-size data bus to make the system cheaper to build.

eg. Intel 8088, Motorola 68008.

Those chips need to do two separate reads for every 16-bit memory access that the "full-width" versions do.

Both those chips are classed as 16-bit so that's not it, either.

And Intel 80386SX too, a full 32-bit processor choked to a 16-bit data bus and 24-bit address bus.

(Somehow I have the feeling that 80386SX can make a better 32-bit retrocomputing processor than MC68SEC000 since that chip has internal MMU, easier to find compiler and existing OS. 80386SL even more since that is a 80386SX based SoC. 80386SL + SeaBIOS + TianoCore + Linux 2.6 = win?)

[Fungus]

(Somehow I have the feeling that 80386SX can make a better 32-bit retrocomputing processor than MC68SEC000 since that chip has internal MMU, easier to find compiler and existing OS. 80386SL even more since that is a 80386SX based SoC. 80386SL + SeaBIOS + TianoCore + Linux 2.6 = win?)

Maybe you want this: https://en.wikipedia.org/wiki/Intel_80386EX

[glarsson]

To me it's about the ALU and data processing, not the width of the address bus.

Don't forget the Z80. I don't think anyone will argue that is something other than an 8-bit microprocessor, but its ALU is only 4 bits wide.

[SiliconWizard]

N-bit processors are usually called that based on their internal data bus width, but for marketing reasons and architectural choices, some manufacturers have played with the concept a little.
The 68k for instance was indeed a mix of 16-bit and 32-bit internally, independantly of the external data bus which was also 16-bit. The details of this "mix" (what was 16-bit and what was 32-bit) were a decision of Motorola and not based on any kind of standard AFAIK, so obviously there's no formal definition. The 68008 had an 8-bit external data bus but was still the same 16-bit/32-bit mix inside. It was sometimes called 8/16/32-bit.

[Fungus]

The 68k for instance was indeed a mix of 16-bit and 32-bit internally

The "ST" of Atari ST stands for "Sixteen Thirty-two".

(officially)

[Fungus]

To me it's about the ALU and data processing, not the width of the address bus.

Don't forget the Z80. I don't think anyone will argue that is something other than an 8-bit microprocessor, but its ALU is only 4 bits wide.

Viewed as a black box: The Z80 ALU has 8 wires leading into it and 8 wires leading out.

[SiliconWizard]

To me it's about the ALU and data processing, not the width of the address bus.

Don't forget the Z80. I don't think anyone will argue that is something other than an 8-bit microprocessor, but its ALU is only 4 bits wide.

Viewed as a black box: The Z80 ALU has 8 wires leading into it and 8 wires leading out.

Yeah, and it had a couple 16-bit registers.
Now was it a 4/8/16-bit CPU? 

[Fungus]

Yeah, and it had a couple 16-bit registers.
Now was it a 4/8/16-bit CPU? 

Wikipedia lists it as 8-bit: https://en.wikipedia.org/wiki/8-bit

Can't argue with that. 

[legacy]

oh, Arise-v2 (my softcore) comes with 32 registers of 32bit each, plus four coprocessors, and one of these (the Cordic UNIT) cops is 24bit, but the DSP engine is 60bit, and the TLB is 64bit address space(1), and the external bus there are only 24 bit(2), hence ...

... is it  23bit? 32bit? 60bit? 64bit? does it have an identity crisis and need a psychotherapy to sort it out? 


(1) cause I wanted to research an idea I had to implement a sort of malloc in hardware
(2) cause it only needs to handle ~16Mbyte of DRAM, and 8Mbyte of static NVRAM

[SiliconWizard]

oh, Arise-v2 (my softcore) comes with 32 registers of 32bit each, plus four coprocessors, and one of these (the Cordic UNIT) cops is 24bit, but the DSP engine is 60bit, and the TLB is 64bit address space(1), and the external bus there are only 24 bit(2), hence ...

... is it  23bit? 32bit? 60bit? 64bit? does it have an identity crisis and need a psychotherapy to sort it out? 

 

To make matters worse, what is now often perceived as "32-bit" or "64-bit" in the popular language has more to do with the addressing width than the data bus width.

[glarsson]

Viewed as a black box: The Z80 ALU has 8 wires leading into it and 8 wires leading out.

The published block diagrams of the Z80 are simplified. Where are the muxes needed to swap DE and HL quickly? 8 bit access to the low and upper halves of IX and IY?

Here is an article describing the Z80 ALU:

http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html

[coppercone2]

its probably more reliable and easier to categorize from HF interference ETC then larger bit ones

It's probably a good idea to use the most simple slowest processor possible for a job, so long you know how to code it.

If you are doing direct sampling on some slow ADC just to get telemetry there is no point in using a complex processor. More transistors to break down. Weirder failure modes can develop.

[technix]

(Somehow I have the feeling that 80386SX can make a better 32-bit retrocomputing processor than MC68SEC000 since that chip has internal MMU, easier to find compiler and existing OS. 80386SL even more since that is a 80386SX based SoC. 80386SL + SeaBIOS + TianoCore + Linux 2.6 = win?)

Maybe you want this: https://en.wikipedia.org/wiki/Intel_80386EX

I can actually tie a 80387SX to this too if I need FPU, and the 64MB RAM address space does allow for some curiosities. (Still for a i386 retrocomputer I would much prefer a Am486DX4-100 on a 50MHz bus tied to a XC6SLX16, which allows me full 4GB address space and the use of 1GB of DDR3 SDRAM.)

oh, Arise-v2 (my softcore) comes with 32 registers of 32bit each, plus four coprocessors, and one of these (the Cordic UNIT) cops is 24bit, but the DSP engine is 60bit, and the TLB is 64bit address space(1), and the external bus there are only 24 bit(2), hence ...

... is it  23bit? 32bit? 60bit? 64bit? does it have an identity crisis and need a psychotherapy to sort it out? 

 

To make matters worse, what is now often perceived as "32-bit" or "64-bit" in the popular language has more to do with the addressing width than the data bus width.

In most current computers data registers and address registers has the same length. As of bus width... even today most amd64 processors doesn't implement full 64-bit address space, while back in P5 days x86 is already in 64-bit external data bus. While AArch64 does have full 64-bit AXI interface, my search for aarch4 chips has led me to a few too many Cortex-A53 choked to a 32-bit AXI and ended up capped at 3GB RAM.

[Fungus]

for a i386 retrocomputer I would much prefer a Am486DX4-100 on a 50MHz bus tied to a XC6SLX16, which allows me full 4GB address space and the use of 1GB of DDR3 SDRAM.

Is that much RAM legal in a 'retro'computer?

[SiliconWizard]

In most current computers data registers and address registers has the same length. As of bus width... even today most amd64 processors doesn't implement full 64-bit address space, while back in P5 days x86 is already in 64-bit external data bus. While AArch64 does have full 64-bit AXI interface, my search for aarch4 chips has led me to a few too many Cortex-A53 choked to a 32-bit AXI and ended up capped at 3GB RAM.

If we only consider registers, that's yet another story.
Intel processors have had 128-bit and even 256-bit data registers for a long time now. Even though those registers can't be used with quite all the same operations than the 64-bit ones, you can still do a great deal. In just one clock cycle. So are Intel processors 256-bit?

[coppice]

In most current computers data registers and address registers has the same length. As of bus width... even today most amd64 processors doesn't implement full 64-bit address space, while back in P5 days x86 is already in 64-bit external data bus. While AArch64 does have full 64-bit AXI interface, my search for aarch4 chips has led me to a few too many Cortex-A53 choked to a 32-bit AXI and ended up capped at 3GB RAM.

If we only consider registers, that's yet another story.
Intel processors have had 128-bit and even 256-bit data registers for a long time now. Even though those registers can't be used with quite all the same operations than the 64-bit ones, you can still do a great deal. In just one clock cycle. So are Intel processors 256-bit?

If you are measuring only the longest register visible to a programmer, there were 16384 bit processors in the 70s.

[technix]

In most current computers data registers and address registers has the same length. As of bus width... even today most amd64 processors doesn't implement full 64-bit address space, while back in P5 days x86 is already in 64-bit external data bus. While AArch64 does have full 64-bit AXI interface, my search for aarch4 chips has led me to a few too many Cortex-A53 choked to a 32-bit AXI and ended up capped at 3GB RAM.

If we only consider registers, that's yet another story.
Intel processors have had 128-bit and even 256-bit data registers for a long time now. Even though those registers can't be used with quite all the same operations than the 64-bit ones, you can still do a great deal. In just one clock cycle. So are Intel processors 256-bit?

Well we are talking integer registers. FPU is a whole another beast usually and they are usually excluded.

[Fungus]

If you are measuring only the longest register visible to a programmer, there were 16384 bit processors in the 70s.

A Turing machine is infinite bits. 

[technix]

Is that much RAM legal in a 'retro'computer?

Using the internal DRAM controller of XC6SLX16-2CSG256C I can implement a DDR3 memory controller with a 32-bit interface. Now connect that to two 256M x16 DDR3 chips and there goes the 1GB RAM.

Since I am reimplementing the entire motherboard chipset using an FPGA, there is little limitation on what I can do.

p.s. It would be a curiosity if the Am486DX4-100 is hooked to a Zynq instead of a Spartan 6. The 486 can be given the same cached memory, system bus and peripheral access as the ARM cores as if it is a multiprocessor system, but the cores uses drastically different instruction sets and architecture.

[brucehoult]

This whole thread started with the observation that by modern definitions as N-bit ISA is one which has N-bit pointers and the only exception to this is that the so-called 8 bit processors actually had 16 bit pointers.

That wouldn't be my definition at all. To me it's about the ALU and data processing, not the width of the address bus.

Having less wires going into the ALU directly affects processing power and speed of execution, having more or less address lines makes no difference at all.

So by your argument the IBM 360 Models 30, 40, 50, 60, 62, and 70 which were announced on the same day in 1964 are completely different 8, 16, and 32 bit computers, despite the fact they all run exactly the same programs? Indeed, the higher-end ones have 64 bit data busses to memory.

Having more or fewer bits in address registers directly affects what programs you can run.

Having different widths of ALU only affects the speed at which programs run, a comparatively trivial matter which can be compensated for (or exaggerated) by varying the clock speed.

the only exception to this is that the so-called 8 bit processors actually had 16 bit pointers.

Not true. The 8086/80286 had 16-bit registers, 16-bit ALU and 20-bit pointers (22-bit pointers on the 80286 IIRC).

Plus: Many, many 32 and 64 bit processors don't have the same number of address lines as bits in the address registers. eg. Are the Motorola 68000 and Intel 80386 24-bit processors? I don't think you'll find many people arguing that case.

The 8086/286 have 16 bit pointer registers. The total address space is 20 bits because of a segmentation scheme. Such schemes were used at least as far back as the PDP11, which let you put a lot of RAM (megabytes) in a computer but gave each program (convenient) access to 64 KB of it at a time. It is still a 16 bit machine.

The number of address lines coming out of the chip is irrelevant. It can be smaller than the size of a pointer (e.g. all x86_64 machines so far) or larger than the size of a pointer (e.g. 8086, bigger PDP-11).

The relevant thing is the address space a program can conveniently use. That determines the size of problem a program can solve without doing gymnastics.

[brucehoult]

oh, Arise-v2 (my softcore) comes with 32 registers of 32bit each, plus four coprocessors, and one of these (the Cordic UNIT) cops is 24bit, but the DSP engine is 60bit, and the TLB is 64bit address space(1), and the external bus there are only 24 bit(2), hence ...

... is it  23bit? 32bit? 60bit? 64bit? does it have an identity crisis and need a psychotherapy to sort it out? 

 

To make matters worse, what is now often perceived as "32-bit" or "64-bit" in the popular language has more to do with the addressing width than the data bus width.

Forget popular language ... address register length is how computer architects classify them.

All computers that can run the same binary programs are the same bit-ness. 68008, 68000, 68040 can all run the same program (if you avoid 68040-specific instructions). They are all the same bit-ness, and that is 32 regardless of the width of the ALU or how many pins are brought out on the address or data busses.

Bit-ness is a characteristic of the Instruction Set, not of its implementation.

[brucehoult]

In most current computers data registers and address registers has the same length. As of bus width... even today most amd64 processors doesn't implement full 64-bit address space, while back in P5 days x86 is already in 64-bit external data bus. While AArch64 does have full 64-bit AXI interface, my search for aarch4 chips has led me to a few too many Cortex-A53 choked to a 32-bit AXI and ended up capped at 3GB RAM.

If we only consider registers, that's yet another story.
Intel processors have had 128-bit and even 256-bit data registers for a long time now. Even though those registers can't be used with quite all the same operations than the 64-bit ones, you can still do a great deal. In just one clock cycle. So are Intel processors 256-bit?

Exactly right. That would be ridiculous.

They are 64 bit, the size of pointers in registers.

[NorthGuy]

Intel processors have had 128-bit and even 256-bit data registers for a long time now. Even though those registers can't be used with quite all the same operations than the 64-bit ones, you can still do a great deal. In just one clock cycle. So are Intel processors 256-bit?

The SIMD registers are not really registers, but a combination of smaller largely independent registers. Even though they have 512-bit SIMD registers now, the longest addition or multiplication you can perform is still only 64-bit. And that's what determines the "bitness" of the CPU.

[Fungus]

The 8086/286 have 16 bit pointer registers. The total address space is 20 bits because of a segmentation scheme. Such schemes were used at least as far back as the PDP11, which let you put a lot of RAM (megabytes) in a computer but gave each program (convenient) access to 64 KB of it at a time. It is still a 16 bit machine.

Is this the same person who just argued that combining two 8-bit registers (H and L) into a single pointer made the Z80 a 16 bit device?

[Fungus]

The relevant thing is the address space a program can conveniently use.

Most of the world would disagree with you, including the people who manufacture the chips.

[brucehoult]

The relevant thing is the address space a program can conveniently use.

Most of the world would disagree with you, including the people who manufacture the chips.

I work for a small company that designs and manufactures CPUs, mostly at the moment ones in the 32 or 64 bit "microcontroller" class. Mostly I write compilers for them, but I also get a little involved in design of new instructions and hardware implementing them.

Before that I worked for a gigantic company that also designs and manufactures CPUs, also mostly writing compilers, but also being sometimes involved in the CPU design.

[Fungus]

The relevant thing is the address space a program can conveniently use.

Most of the world would disagree with you, including the people who manufacture the chips.

I work for a small company that designs and manufactures CPUs, mostly at the moment ones in the 32 or 64 bit "microcontroller" class. Mostly I write compilers for them, but I also get a little involved in design of new instructions and hardware implementing them.

Before that I worked for a gigantic company that also designs and manufactures CPUs, also mostly writing compilers, but also being sometimes involved in the CPU design.

So?

At some point you have to put a label on things and put them in a category. You can't call every single chip a "hybrid 8/16/20/32/64-bit CPU" just because it has a single edge case for each of those somewhere in the instruction set.

You can 'conveniently use' CPUs with paged memory via bios calls, etc. All the swapping can be completely transparent to users. Many computers do this, eg. swapping RAM for system ROM. Does that make the 6502-based BBC Micro or Z80-based MSX a 17 or 18-bit computer? Nope.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

[coppice]

You can 'conveniently use' CPUs with paged memory via bios calls, etc.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     

I like the use of quote marks there. I don't think I've ever seen as much loathing of a computer design as you get when you push a paged solution, or as much relief as you get when you tell people you're going to stretch the address registers to solve their memory constraints.

[brucehoult]

You can 'conveniently use' CPUs with paged memory via bios calls, etc.

I like the use of quote marks there. I don't think I've ever seen as much loathing of a computer design as you get when you push a paged solution, or as much relief as you get when you tell people you're going to stretch the address registers to solve their memory constraints.

Exactly.

Using more memory than the natural hardware size of your memory addresses (16 bits in the case of the 6502, z80 etc) requires absolute contortions on the part of the programmer.

[Fungus]

Using more memory than the natural hardware size of your memory addresses (16 bits in the case of the 6502, z80 etc) requires absolute contortions on the part of the programmer.

Maybe true but it doesn't mean you get to change the commonly understood definition of "8-bit" or "16-bit" because of it.

[Siwastaja]

The relevant thing is the address space a program can conveniently use.

Most of the world would disagree with you, including the people who manufacture the chips.

I wouldn't; while the classification to the bit number classes isn't never going to work perfectly, the "address space a program can conveniently use" sounds quite fair to me.

Of course, like most classification problems, this is only interesting on the "academic coffee table discussion" level.

In reality, a 8-bit CPU is what the manufacturer calls a "8-bit CPU", and a 32-bit CPU is what the manufacturer decides to call a "32-bit CPU". This can be more arbitrary than we want to think. It's up to the marketing to decide.

And the coffee table discussion on how "pure" those numbers are goes on, and people try to come up with criteria to maximize the "pureness" of existing products. And others say that all CPU's are "hybrids". Nothing wrong with that either. Classification, after all, is always by arbitrary rules, and there is no need to come up with the "Official Truth" on coffee table discussions. It doesn't exist.

[Fungus]

The relevant thing is the address space a program can conveniently use.

Most of the world would disagree with you

I wouldn't

So you'd say the chips on this page are more than 8-bits?

https://en.wikipedia.org/wiki/8-bit

Like I said, most of the world disagrees with that.

[SiliconWizard]

Quite frankly isn't this bitness thing running in circles? As most of us have debated, there is no formal definition that I know of, and it tends to vary according to time, type of processor, market, etc. And who cares. As I said above, the most commonly seen use amongst a lot of different kinds and generations of processors seems to be the internal data bus width, at least IMO. There are so many counter-examples concerning the registers width, address bus width or ALU that it doesn't seem quite as relevant, all the more that modern ALUs can be structurally pretty different from what they were 30 or 40 years ago. It may seem common that most registers and the ALU width will match the internal data bus width, but there can be variants/extensions of that.

Only a closer look to a specific processor will allow you to determine if it fits your requirements or not. Not just a simple figure that turns into a marketing gimmick.
To get back to the topic, all 8-bit processors are not equal by any means. Some will even get you more effective performance and lower power draw than some 16-bit processors, whereas other 8-bit processors are usable only for the simplest tasks and actually draw more power than even a lot of more recent 32-bit ones. Then the memory models can vary substantially as well, leading to different performance levels and ease of programming.

Only if you target a very specific architecture (such as the ARM Cortex Mx) - then it becomes possible to compare processors. It's easier in the 32-bit world for MCUs, since there are very few different architectures on the market. For 8-bitters and 16-bitters, that's a different story. There are many different architectures that are difficult to really compare.

[SiliconWizard]

The SIMD registers are not really registers, but a combination of smaller largely independent registers. Even though they have 512-bit SIMD registers now, the longest addition or multiplication you can perform is still only 64-bit. And that's what determines the "bitness" of the CPU.

They are registers and defined as such in Intel's datasheets and manuals.
Since they can be fully accessed in one cycle as any other register, I don't see a reason not to consider them so. Of course there is no 256-bit or 512-bit ALU, so ALU operations on them are limited to operations on chunks of the registers, but that doesn't make them any less of registers. And you can still move arbitrary data around with them at their full size. Just because they are virtually organized as predefined chunks for some operations doesn't change much. There are operations on "regular" registers such as byte/word swapping that also use predefined chunks of the registers.

All of this to again say that it sounds futile to try and see a definitive definition.

[NorthGuy]

To get back to the topic, all 8-bit processors are not equal by any means. Some will even get you more effective performance and lower power draw than some 16-bit processors, whereas other 8-bit processors are usable only for the simplest tasks and actually draw more power than even a lot of more recent 32-bit ones.

This is a question of technology. 32-bit processors typically use smaller transistors which are faster and consume less power. 8-bit processors are usually made of bigger transistors which consume more power an will be slower. If you build both on the same technology, there's no doubts that you can achieve lower power consumption and faster speeds with 8-bit processors compared to 16-bit processors, or with 16-bit processors compared to 32-bit processors.

[SiliconWizard]

To get back to the topic, all 8-bit processors are not equal by any means. Some will even get you more effective performance and lower power draw than some 16-bit processors, whereas other 8-bit processors are usable only for the simplest tasks and actually draw more power than even a lot of more recent 32-bit ones.

This is a question of technology. 32-bit processors typically use smaller transistors which are faster and consume less power. 8-bit processors are usually made of bigger transistors which consume more power an will be slower. If you build both on the same technology, there's no doubts that you can achieve lower power consumption and faster speeds with 8-bit processors compared to 16-bit processors, or with 16-bit processors compared to 32-bit processors.

Sure. The point was not what is technologically possible, but rather what's actually available on the market.

As for speed, yes you can obviously achieve higher clock speeds on a given process node with a simpler architecture and smaller registers. As for the resulting performance, it's a trade-off. Higher clock speeds on a given process node for an equivalent "processing power" may actually draw more power than a more complex/wider architecture running at lower clock speeds. The sweet spot is not necessarily trivial to find IMO.

[NorthGuy]

Of course there is no 256-bit or 512-bit ALU, so ALU operations on them are limited to operations on chunks of the registers, but that doesn't make them any less of registers.

Another interesting example is 8087. When it was a separate chip, it was 80-bit CPU attached to 16-bit 8086 processor. It could operate on 80-bit floats and 64-bit integers.

Once the functionality of 8087 was taking into the processor, the 80-bit registers (with 80-bit operations) became part of the processor. Did it make 80386 into a 64-bit (or 80-bit) processor?

BTW: The FPU is still there in the most modern Intel processors, although newer software doesn't use it. Does this make new Intel processors into 80-bit processors?

The point is moot. It's the same as pornography. You cannot define it, but you recognize it when you see it.

[technix]

To get back to the topic, all 8-bit processors are not equal by any means. Some will even get you more effective performance and lower power draw than some 16-bit processors, whereas other 8-bit processors are usable only for the simplest tasks and actually draw more power than even a lot of more recent 32-bit ones.

This is a question of technology. 32-bit processors typically use smaller transistors which are faster and consume less power. 8-bit processors are usually made of bigger transistors which consume more power an will be slower. If you build both on the same technology, there's no doubts that you can achieve lower power consumption and faster speeds with 8-bit processors compared to 16-bit processors, or with 16-bit processors compared to 32-bit processors.

Sure. The point was not what is technologically possible, but rather what's actually available on the market.

As for speed, yes you can obviously achieve higher clock speeds on a given process node with a simpler architecture and smaller registers. As for the resulting performance, it's a trade-off. Higher clock speeds on a given process node for an equivalent "processing power" may actually draw more power than a more complex/wider architecture running at lower clock speeds. The sweet spot is not necessarily trivial to find IMO.

Maybe this can be tested on a FPGA. Throw various different processor cores on the same FPGA platform and run the same test program. Same FPGA platform means there would be no variance of process node.

An example test would be RV64GC vs Cortex-M0 vs Zet the open source 80486 implementation vs that open source AVR implementation. RV64, Cortex-M0, 80486 and AVR all run code produced by mainline GCC, so we can even remove most of the compiler and optimizer differences if we use the same source tree to generate the four compilers used in the tests. And since we are using the same version of GCC across the platforms we can use the same test code (with platform-specific boilerplate though) at the same optimization level.

[NorthGuy]

As for speed, yes you can obviously achieve higher clock speeds on a given process node with a simpler architecture and smaller registers. As for the resulting performance, it's a trade-off. Higher clock speeds on a given process node for an equivalent "processing power" may actually draw more power than a more complex/wider architecture running at lower clock speeds. The sweet spot is not necessarily trivial to find IMO.

Performance is another story. The performance depends on what you're doing. The current most popular benchmarks use different sorts of 32-bit number crunching, so 32-bit processors certainly come as winners. But look at your embedded programs. Most of the time, you're doing something completely different. As a result, the 32-bit ALU crunches mostly zero bits, which could have been avoided if you used 8-bit ALU.

32x32 multiplier takes 16 times more silicon that 8x8 multiplier. What would you rather have: one 1-GHz 32-bit CPU, or 16 1-GHz 8-bit CPUs running independently and controlling the peripherals? IMHO, for the majority of tasks the second would be more preferable.

[brucehoult]

32x32 multiplier takes 16 times more silicon that 8x8 multiplier. What would you rather have: one 1-GHz 32-bit CPU, or 16 1-GHz 8-bit CPUs running independently and controlling the peripherals? IMHO, for the majority of tasks the second would be more preferable.

The latter, obviously.

Unfortunately you don't get to make that trade-off as instruction decode and control takes a large proportion of the area of a CPU, and doesn't vary much depending on whether the registers and ALU are 8, 16, 32 or 64 bits. For example, the decode and control on a 64 bit RISC-V Rocket core is just about identical to that on a 32 bit RISC-V Rocket core.

So, it's more likely that you'd actually get to choose between one 1-GHz 32-bit CPU, or two or maybe three 1-GHz 8-bit CPUs.

Three points about the multiplier argument:

1) many useful CPUs don't have a multiplier or divider at all

2) the ratio of the rest of the ALU and registers and datapath is proportional to the bitwidth, lowering the average.

3) a 32x32 multiply can be done with three 16x16 multiplies. Each 16x16 multiply can be done with three 8x8 multiplies. So actually you need nine 8x8 multipliers, not sixteen.

Also, few CPUs do single-cycle multiply. It's more likely to use a 16x16 multiplier three times and take three clock cycles. So that's only three times the area of an 8x8 multiplier.

[NorthGuy]

Unfortunately you don't get to make that trade-off as instruction decode and control takes a large proportion of the area of a CPU, and doesn't vary much depending on whether the registers and ALU are 8, 16, 32 or 64 bits. For example, the decode and control on a 64 bit RISC-V Rocket core is just about identical to that on a 32 bit RISC-V Rocket core.

So, it's more likely that you'd actually get to choose between one 1-GHz 32-bit CPU, or two or maybe three 1-GHz 8-bit CPUs.

Most of the control that you're referring to is not required in light-weight cores:

- There's no pipeline, so no need for pipeline control.
- There's no cache, so there's no need for cache and big memory controllers.
- We won't worry about code density (because the performance doesn't depend
    on decoding speed), so we can have really long instructions, such as 32-bit.
    This way the instruction will come out already decoded  to a great extent
- We'll also get rid of the bus with all the bus arbitrage and collisions, and
    let our small cores communicate through dedicated FIFOs.

In the end, it'll be much less of silicon for each core. May be not 16, but close. More importantly, you
may be able to run the whole thing faster and will end up with 2 GHz 8-bit cores, or even 3 GHz 8-bit
cores. This would certainly beat the current behemoths.

Three points about the multiplier argument:

3) a 32x32 multiply can be done with three 16x16 multiplies. Each 16x16 multiply can be done with three 8x8 multiplies. So actually you need nine 8x8 multipliers, not sixteen.

May be Karatsuba gives some advantage, but it also requires lots of dancing around. When I implemented SSL a long time ago, I found out that it only produces benefits for really big numbers. Of course it's different in silicon, but I don't think it's advantageous.

Also, few CPUs do single-cycle multiply. It's more likely to use a 16x16 multiplier three times and take three clock cycles. So that's only three times the area of an 8x8 multiplier.

You either pipeline it, then each stage requires its own multiplier, or you don't, in which case next multiply commands will be sitting there waiting for its turn.

[brucehoult]

Unfortunately you don't get to make that trade-off as instruction decode and control takes a large proportion of the area of a CPU, and doesn't vary much depending on whether the registers and ALU are 8, 16, 32 or 64 bits. For example, the decode and control on a 64 bit RISC-V Rocket core is just about identical to that on a 32 bit RISC-V Rocket core.

So, it's more likely that you'd actually get to choose between one 1-GHz 32-bit CPU, or two or maybe three 1-GHz 8-bit CPUs.

Most of the control that you're referring to is not required in light-weight cores:

- There's no pipeline, so no need for pipeline control.
- There's no cache, so there's no need for cache and big memory controllers.
- We won't worry about code density (because the performance doesn't depend
    on decoding speed), so we can have really long instructions, such as 32-bit.
    This way the instruction will come out already decoded  to a great extent
- We'll also get rid of the bus with all the bus arbitrage and collisions, and
    let our small cores communicate through dedicated FIFOs.

That turns out not to be the case. On simple processors the control is the majority of the chip.

For example here's a labelled photo of a Z80



You'll observe that the control logic is something like 60% of the chip, and the registers and ALU 40% (to be generous).

If you made a chip with the same instruction set with the same encoding, but just made the registers and ALU two or four times wider, the control part would stay the same size while the registers and ALU would get bigger, roughly in proportion to the bit width. So the control part would get relatively smaller. So a 32 bit Z80 might be 25% control and 75% registers and ALU.

In the end, it'll be much less of silicon for each core. May be not 16, but close. More importantly, you
may be able to run the whole thing faster and will end up with 2 GHz 8-bit cores, or even 3 GHz 8-bit
cores. This would certainly beat the current behemoths.

There is no reason for a 2x or 4x wider data path to run 50% more slowly. The only place it will make any difference at all is carry propagation in adders, but that's logarithmic if done correctly. Basically, a 32 bit adder has two gates more delay than an 8 bit adder. And the adder isn't usually the clock-limiting factor anyway.

You either pipeline it, then each stage requires its own multiplier, or you don't, in which case next multiply commands will be sitting there waiting for its turn.

Multiplies are rare. Two multiplies in a row are *very* rare.

The Coremark and Dhrystone benchmarks, for example are quite heavily influenced by multiply performance.

I just checked on my HiFive1 "Arduino" board (32 bit RISC-V "Rocket" microcontroller running at 256 MHz). It has a 4 cycle multiplier which allows following instructions to continue as long as they are not multiplies (or divides) and as long as they do not need the result of the multiply. I used gcc 7.2.0.

Coremark/MHz with hardware multiply: 2.68
Coremark/MHz with software multiply:  0.94

Dhrystone/MHz with hardware multiply: 1.56
Dhrystone/MHz with software multiply:  0.85

For comparison, for the Cortex M3/M4 ARM claims http://www.eeherald.com/section/design-guide/arm_cortex_m3_m4_mcu.html 2.17 Coremark/MHz and 1.25 Dhrystone/MHz.

ARM manuals say the M3/M4 has a single-cycle multiplier. But it's coming out considerably slower than the chip with the 4 cycle multiplier on benchmarks where multiplication is important (as seen by software emulation being much slower)

As in most real-case uses of multiply, Coremark (for example) is generally loading two values from memory, then multiplying them, then storing the result, and then looping. There are plenty of other instructions around the multiply that a four cycle latency is no big deal.

[legacy]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

[technix]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

There is this matrix adder design for integer multiplier, a lot of adders are involved but it is a fully combinatorial unit.

[GeorgeOfTheJungle]

ARMs are the best, trash all your 8-bitters now!

[Howardlong]

ARM manuals say the M3/M4 has a single-cycle multiplier. But it's coming out considerably slower than the chip with the 4 cycle multiplier on benchmarks where multiplication is important (as seen by software emulation being much slower)

As in most real-case uses of multiply, Coremark (for example) is generally loading two values from memory, then multiplying them, then storing the result, and then looping. There are plenty of other instructions around the multiply that a four cycle latency is no big deal.

A quick note: how often a multiply instruction appears in object code isn't the same as how often it's executed.

In some number crunching applications, particularly DSP, multiplies, or more often MACs, are a significant proportion of the run time effort.

I totally agree that, particularly in ARM, and depending on the benchmark, loads and stores are an expensive overhead. ARM is optimised for in-register processing.

In many applications, this necessitates amalgamating several logically separate, chained algorithms into fewer more complex algorithms to be able to compute in-register, minimising loads and stores. This is on top of being acutely aware of processor pipeline stalls, which in itself demands a mental maze to be minimised.

While compiler optimisers are capable of helping out with things like loop unrolling, re-implementing multiple chained algorithms to reduce loads and stores is not something a compiler optimiser is capable of.

Once you've optimised out as many loads and stores as possible, you're left with a run time profile with a very high percentage of multiplies and/or MACs, even though the object code itself only has <1% multiply/MAC instructions.

[Siwastaja]

While compiler optimisers are capable of helping out with things like loop unrolling, re-implementing multiple chained algorithms to reduce loads and stores is not something a compiler optimiser is capable of.

Exactly.

When the processing power is at premium, mapping the memory correctly is a huge deal; not only to minimize the load/stores, but also to utilize the available SIMD instruction set. DMAs that can increment the addresses by a value larger than the write access size help here by interleaving the datasets, if you have that available to you.

Some example code from an older project: https://pastebin.com/NJf5WF93 . Two ADCs are configured in dual-mode to utilize 32-bit memory operations on DMA, halving the memory access time spent by DMA. Now, the data for two independent but synchronous DC/DC converters are interleaved; their control ISRs happen synchronously on 180 degree phase shift as well. The original code simply summed the eight current measurement to average them, but this only works with 16-bit loads, taking the same time as 32-bit loads would take. Both ISRs needed to do 8 such loads. By manually optimizing it, 16-bit loads are replaced by 32-bit loads, and utilizing SIMD instructions, each ISR calculates half of what it needs, and as a free side product, half of what the another ISR needs. One register is dedicated for storing the intermediate result, so we need to tell the compiler not to use that register elsewhere. (I needed to analyze how that limitation affects the performance elsewhere. No performance drop was caused, as the full number of registers were never used by the compiler at the same time anywhere expect non-critical initialization.)

The reason for this was that I was actually having random ADC data register overruns when the CPU was executing the loooong eight loads, and simultaneously, the DMA was doing a bunch of 16-bit writes all the time from the ADCs working in separate mode. This fix halved both usage patterns, reducing the memory operation load by 4x. This was, by the way, two ADC converting at 5MSPS each (so 10MSPS total), the CPU and the AHB bus running at 72MHz, on STM32F334.

[legacy]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

There is this matrix adder design for integer multiplier, a lot of adders are involved but it is a fully combinatorial unit.

but usually there is a limit for the number of numbers you can sum, how can they perform 40 add-operations in parallel and respecting the timing for data being stable?

[NorthGuy]

That turns out not to be the case. On simple processors the control is the majority of the chip.

This can be reduced if you set it as a design goal.

For example here's a labelled photo of a Z80

If you want to use existing processors, look at this:

https://en.wikipedia.org/wiki/Transistor_count

Z80 had 8500 transistors. ARM Cortex A9 has 26 million transistors. You could have over 3000 Z80 cores instead of one ARM core, all running at the same clock speed or faster. This is a little bit more than 16, is it?

I couldn't find data for ARM Cortex M, but my guess would be 100000, which would give you roughly 12 Z80 cores.

But this can be improved if you aim at pure performance and forget about code density.

There is no reason for a 2x or 4x wider data path to run 50% more slowly. The only place it will make any difference at all is carry propagation in adders, but that's logarithmic if done correctly. Basically, a 32 bit adder has two gates more delay than an 8 bit adder. And the adder isn't usually the clock-limiting factor anyway.

Of course, dealing with wider datapath requires more logic and more pipelining at faster clocks. You need to arrange the gates and flops in space. This produces delays. I'm 100% confident that if you put the higher clock frequency as you design goal, you'll be able to build much faster 8-bit cores than 32-bit cores with the same design goal in mind.

Multiplies are rare. Two multiplies in a row are *very* rare.

Depends on what you're doing. If you want to do a FIR filter, you'd be better off with multiplications done every cycle. And DSP processors (such as dsPIC) can do it, and will give you much higher performance doing FIR. Although they will fall way behind the ARM M3/M4 cores in your Coremark/Dhrystone tests. These tests have nothing to do with performance.

Of course, people look at benchmarks, so if you design a processor which is high on benchmarks, people will think of it as a high performance processor. Better yet, if you design a benchmark test to make your processor look good ...

[langwadt]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

afair ARM use some kind booth multiplier, basically a bunch of adders and some trickery

might not be exactly the algo they use but close enough, http://www.ellab.physics.upatras.gr/~bakalis/Eudoxus/MBM.html

[Fungus]

but usually there is a limit for the number of numbers you can sum, how can they perform 40 add-operations in parallel and respecting the timing for data being stable?

The timing problem is O(logN). 64 bits isn't much more difficult than 16 bits.

How do they do it? Very carefully.

[Siwastaja]

How do they do it? Very carefully.

Yeah, I guess there is quite a lot of complexity hidden in the place&route (synthesis) and timing analysis tools, which is vital for the end result.

[coppice]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

afair ARM use some kind booth multiplier, basically a bunch of adders and some trickery

might not be exactly the algo they use but close enough, http://www.ellab.physics.upatras.gr/~bakalis/Eudoxus/MBM.html

Its more likely they use a Wallace tree than a Booth tree. Booth is naturally 2's complement, and you need extra fudging to do unsigned multiplies. Wallace is naturally unsigned, and you need extra fudging to do 2's complement multiplies. When you need to do both types of multiply (which an ARM does) Wallace + fudging logic tends to work out better. For 2's complement only work (e.g. most DSP) Booth is the winner.

[nctnico]

Actually it is easier to implement 1's complement calculations than 2's complement. Someone I knew in a distant past wrote a PhD thesis on that.

[legacy]

The timing problem is O(logN). 64 bits isn't much more difficult than 16 bits.
How do they do it? Very carefully.

I have implemented a Booth 32x32 Multiplier and Adder (MAC) with saturating arithmetic, but ... it takes 4 clocks to compute, otherwise, the synthesizer complains of the timing (of the full adder units) not respected.

It means that, on ISE-v11/Spartan6, I can't sum more than 32/4=8 numbers in parallel with the same adder 

anyway, I have a wait-flag in the finite state machine of the CPU (Arise-v2) that stalls the whole core until the MAC unit comes ready with the results.

External interrupts are handled by a Cop0 unit which works in parallel, hence they accepted during the CPU stall and saved for being handled on the next fetch.

[legacy]

Actually it is easier to implement 1's complement calculations than 2's complement. Someone I knew in a distant past wrote a PhD thesis on that.

with the software made able to handle "negative zero"

[technix]

ARM manuals say the M3/M4 has a single-cycle multiplier

how is it implemented?

There is this matrix adder design for integer multiplier, a lot of adders are involved but it is a fully combinatorial unit.

but usually there is a limit for the number of numbers you can sum, how can they perform 40 add-operations in parallel and respecting the timing for data being stable?

Instead of traditional adders they expand one of the operands into sums of powers of two. Now multiply by power of two is just shifting which can be done without propagation delay using cross wiring, and the matrix multiplier uses a one-counter (a special type of encoder) to reduce the amount of adders actually needed.

[brucehoult]

That turns out not to be the case. On simple processors the control is the majority of the chip.

This can be reduced if you set it as a design goal.

I'm pretty sure the people designing the Z80 had simplicity of implementation as a primary goal. The ones designing the 6502 certainly did, and it's got a similar control-to-datapath ratio.

For example here's a labelled photo of a Z80

If you want to use existing processors, look at this:

https://en.wikipedia.org/wiki/Transistor_count

Z80 had 8500 transistors. ARM Cortex A9 has 26 million transistors. You could have over 3000 Z80 cores instead of one ARM core, all running at the same clock speed or faster. This is a little bit more than 16, is it?

The A9 has a lot of transistors because it's a complex out-of-order CPU, has a lot of cache, has FPU, has MMU.

Virtually nothing to do with being 32 bit vs 8 bit.

[NorthGuy]

The A9 has a lot of transistors because it's a complex out-of-order CPU, has a lot of cache, has FPU, has MMU.

Virtually nothing to do with being 32 bit vs 8 bit.

You don't seem to like my examples. Would you pick a 32-bit processor which has something to do with being 32-bit?

[SilverSolder]

Are there any 3 cent 32 bit microcontrollers?   

[SiliconWizard]

with the software made able to handle "negative zero"

Is zero negative or positive?
You have 4 hours.

[brucehoult]

The A9 has a lot of transistors because it's a complex out-of-order CPU, has a lot of cache, has FPU, has MMU.

Virtually nothing to do with being 32 bit vs 8 bit.

You don't seem to like my examples. Would you pick a 32-bit processor which has something to do with being 32-bit?

Sure. An actually small 32 bit ARM such as the Cortex M0 or a simple 32 bit RISC-V would be appropriate to compare to the likes of Z80.

It's hard to know much about ARMs but in fully open RISC-V land you have for example https://github.com/SpinalHDL/VexRiscv which can be configured as RV32I at 346 MHz and 0.52 Dhrystone MIPS/MHz on an Artix 7 using 481 LUTs and 539 FFs.

LUTs don't convert conveniently to equivalent gates, but somewhere between 6 and 24 is about right, and probably 12 is a good average. So that's somewhere between 3000 and 12000 gates for the LUTs with 6000 probably being a good guess. D flip-flops are worth 4 gates each I guess, so that's 2000. Total maybe 8000.

When you convert gates to transistors that's bigger than a Z80. But it's *far* from 100000. Let alone millions.

Note that the 32 bit ARM1 is listed on the Wikipedia page you referenced as having 25000 transistors, about 3x the z80.

[legacy]

with the software made able to handle "negative zero"

Is zero negative or positive?

mathematically
zero+ = 0 + eps
zero- = 0 - eps

hence,
zero+ is positive
zero- is negative

numerically, in 1's complement
zero+=0x0000.0000
zero-=0xffff.ffff

a circuit evaluates if a number is positive or negative by checking the most significant bit: (boolean_t) is_positive(A) = (MSbit(A) isEqualTo '0');

hence
(MSbit(0x0000.0000) = '0') => zero+ is positive
(MSbit(0xffff.ffff) = '1') => zero- is negative

but the point is that a 1's-complement-ALU requires an additional circuit to handle results with end-around carry propagation and subtract if it's set to '1'

Code: [Select]

  0001 0110     22
+ 1111 1111     −0
===========   ====
1 0001 0101     21    —An end-around carry is produced. it's set to '1'
+ 0000 0001      1    — subtract it
===========   ====
  0001 0110     22    —The correct result (22 + (−0) = 22)

and you also have to modify each compare-and-branch instruction in your hypothetical ISA to double compare an operand, which can zero 0+ or zero-, and they both must be handled as zero.


These look the couple of software patches you have to apply if you are willing to use a 2's-complement-ALU for the 1's-complement math 

[legacy]

for sure the 1's complement math gives the less numerical error when used to implement a fixed-point DSP engine, simply because the weights of positive numbers and negatives numbers are perfectly balanced

2's complement
bx00: positive, zero
bx01: postive, non zero
bx10: negative, non zero
bx11: negative, non zero

1 positive non zero vs 2 negative non zero: weights are not balanced, it may cause an additional  numerical error if the algorithm needs to bounce between positive numbers and negative numbers (e.g. a trigonometric algorithm)


1's complement
bx00: positive, zero+
bx01: postive, non zero
bx10: negative, non zero
bx11: negative, zero-

1 positive non zero vs 1 negative non zero: weights are balanced. It offers the same truncation error for both positive and negative numbers. Which is good!

[Fungus]

with the software made able to handle "negative zero"

Is zero negative or positive?
You have 4 hours.

That's a trick question. The answer is "Both", obviously.

[Fungus]

Sure. An actually small 32 bit ARM

I had an original Acorn Archimedes back in the day. 

[technix]

Are there any 3 cent 32 bit microcontrollers?   

Maybe not quite three US cents...

SWM050I2P7, Cortex-M0 in TSOP-8, 8kB Flash, 1kB SRAM, US$0.2 in volume of 10
GD32F130F8P6, Cortex-M3 in TSOP-20, 32kB fast Flash + 32kB slow Flash, 8kB SRAM, US$0.5 in volume of 10.

[NorthGuy]

Sure. An actually small 32 bit ARM such as the Cortex M0 or a simple 32 bit RISC-V would be appropriate to compare to the likes of Z80.

It's hard to know much about ARMs but in fully open RISC-V land you have for example https://github.com/SpinalHDL/VexRiscv which can be configured as RV32I at 346 MHz and 0.52 Dhrystone MIPS/MHz on an Artix 7 using 481 LUTs and 539 FFs.

LUTs don't convert conveniently to equivalent gates, but somewhere between 6 and 24 is about right, and probably 12 is a good average. So that's somewhere between 3000 and 12000 gates for the LUTs with 6000 probably being a good guess. D flip-flops are worth 4 gates each I guess, so that's 2000. Total maybe 8000.

Physically a LUT consists of 64 config bits which are selected by 6 address lines. Thus it's 63 muxes, which is lot more than 12 gates. You may be able to get the same effect with discrete gates, or you may be not. It's like data compression - some data compresses well, some data doesn't compress at all. You only can tell, if all 6 inputs are used, you need at least 6 gates. Therefore comparing LUTs to gates is not a good idea.

If you compare to FPGA based cores, such as Picoblaze, your basic RV32I is equivalent of 5 Picoblazes (however I don't think Picoblaze can run at 350 MHz).

However, this is a very basic, very feeble processor. If you start adding features (look at the table you posted: https://github.com/SpinalHDL/VexRiscv ), by the time you add enough features to make it into a typical 32-bit processor, you get to 2000 LUTs and the speed deceases to 183 MHz - now it's equivalent to 20 Picoblazes and your RISC is now running slower than Picoblaze.

This is a very interesting table, by the way - adding features consumes lots of logic, but performance growth is not great - your fastest RISC is not even 50% faster than the feeble 346 MHz model.

And that's RISC - the best 32-bit CPU the humanity could come up with. If you look at others (such as ARM or Microblaze), the pattern will be the same, but the performance will be even lower.

Note that the 32 bit ARM1 is listed on the Wikipedia page you referenced as having 25000 transistors, about 3x the z80.

If we use the smallest 32-bit processor (ARM1), shouldn't we pick the smallest 8-bit processor for comparison? The table shows 3500 transistors for 6502. Your ARM1 is roughly 7 times bigger.

[technix]

Sure. An actually small 32 bit ARM such as the Cortex M0 or a simple 32 bit RISC-V would be appropriate to compare to the likes of Z80.

It's hard to know much about ARMs but in fully open RISC-V land you have for example https://github.com/SpinalHDL/VexRiscv which can be configured as RV32I at 346 MHz and 0.52 Dhrystone MIPS/MHz on an Artix 7 using 481 LUTs and 539 FFs.

LUTs don't convert conveniently to equivalent gates, but somewhere between 6 and 24 is about right, and probably 12 is a good average. So that's somewhere between 3000 and 12000 gates for the LUTs with 6000 probably being a good guess. D flip-flops are worth 4 gates each I guess, so that's 2000. Total maybe 8000.

Physically a LUT consists of 64 config bits which are selected by 6 address lines. Thus it's 63 muxes, which is lot more than 12 gates. You may be able to get the same effect with discrete gates, or you may be not. It's like data compression - some data compresses well, some data doesn't compress at all. You only can tell, if all 6 inputs are used, you need at least 6 gates. Therefore comparing LUTs to gates is not a good idea.

If you compare to FPGA based cores, such as Picoblaze, your basic RV32I is equivalent of 5 Picoblazes (however I don't think Picoblaze can run at 350 MHz).

However, this is a very basic, very feeble processor. If you start adding features (look at the table you posted: https://github.com/SpinalHDL/VexRiscv ), by the time you add enough features to make it into a typical 32-bit processor, you get to 2000 LUTs and the speed deceases to 183 MHz - now it's equivalent to 20 Picoblazes and your RISC is now running slower than Picoblaze.

This is a very interesting table, by the way - adding features consumes lots of logic, but performance growth is not great - your fastest RISC is not even 50% faster than the feeble 346 MHz model.

And that's RISC - the best 32-bit CPU the humanity could come up with. If you look at others (such as ARM or Microblaze), the pattern will be the same, but the performance will be even lower.

There is a certain thing 8-bit processors suffer: memory space. Certain programs eat RAM like candy (Google Chrome with more than a handful of tabs open) and 8-bit cores will quickly start to suffer even if it has 64-bit memory pointers.

Note that the 32 bit ARM1 is listed on the Wikipedia page you referenced as having 25000 transistors, about 3x the z80.

If we use the smallest 32-bit processor (ARM1), shouldn't we pick the smallest 8-bit processor for comparison? The table shows 3500 transistors for 6502. Your ARM1 is roughly 7 times bigger.

Do keep in mind that one NMOS transistor can map to multiple CMOS transistors. The 25000 CMOS transistors in ARM1 and the 3500 NMOS transistors in 6502 maps to ARM1 having about three times the gate count.

[Fungus]

Are there any 3 cent 32 bit microcontrollers?   

There won't be any ARM chips, the ARM royalties will be more than 3 cents.

[mikeselectricstuff]

Are there any 3 cent 32 bit microcontrollers?   

There won't be any ARM chips, the ARM royalties will be more than 3 cents.

RISCV?

[rjp]

Are there any 3 cent 32 bit microcontrollers?   

There won't be any ARM chips, the ARM royalties will be more than 3 cents.

RISCV?

Not until someone is producing them in the numbers that get economies of scale.

Id expect one of the Chinese mobs to be on to that sooner rather than later but its not today.

[GeorgeOfTheJungle]

Are there any 3 cent 32 bit microcontrollers?   

How about 1 cent, and flexible?

$0.01 Flexible Plastic ARM Processor by PragmatIC

[wraper]

Are there any 3 cent 32 bit microcontrollers?   

How about 1 cent, and flexible?

$0.01 Flexible Plastic ARM Processor by PragmatIC

Except it's not 1 cent, not a real product, only prototype and even ARM licence is more expensive than 1 cent. A few cents sometime in the future, maybe, just as a guy on the right said.

[coppice]

Are there any 3 cent 32 bit microcontrollers?   

How about 1 cent, and flexible?

$0.01 Flexible Plastic ARM Processor by PragmatIC

Except it's not 1 cent, not a real product, only prototype and even ARM licence is more expensive than 1 cent. Sometime in the future, maybe, just a a guy on the right said.

They made an ARM1. That is licence free. To make a commercial product they have licence free options. like the RISC/V. People usually can't escape all royalties, because they will have to used some silicon IP, like a flash block. Since these people are not using any silicon technology, they will be creating 100% of their process related IP.

[wraper]

They made an ARM1. That is licence free. To make a commercial product they have licence free options. like the RISC/V. People usually can't escape all royalties, because they will have to used some silicon IP, like a flash block. Since these people are not using any silicon technology, they will be creating 100% of their process related IP.

It is cortex M0, not ARM1. In video was even said that it will become commercially viable when they will make a single chip few mm in size. Which means it's not commercially viable currently. And who would make a real product based on ARM1 to begin with?
EDIT: And anyway, it's not something you would use in a low and likely medium quantity product. It's a niche thing, flexible electronics. You won't solder this thing on the PCB.

[technix]

They made an ARM1. That is licence free. To make a commercial product they have licence free options. like the RISC/V. People usually can't escape all royalties, because they will have to used some silicon IP, like a flash block. Since these people are not using any silicon technology, they will be creating 100% of their process related IP.

It is cortex M0, not ARM1. In video was even said that it will become commercially viable when they will make a single chip few mm in size. Which means it's not commercially viable currently. And who would make a real product based on ARM1 to begin with?
EDIT: And anyway, it's not something you would use in a low and likely medium quantity product. It's a niche thing, flexible electronics. You won't solder this thing on the PCB.

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

Although if ou use RV32IMC it would have the same benefit.

[wraper]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

And no one would buy them because they would suck, therefore not possible to make such amounts to achieve low cost.

[brucehoult]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

ARM7TDMI was 1994. That should be out of protection now.

Although if ou use RV32IMC it would have the same benefit.

Just RV32IM for ARM2 equivalence. C gets you to competitive with Thumb2 on code size, and better and much cleaner than the mix of ARM32 and Thumb1 you need on ARM7TDMI.

Cortex M0(+) is of course almost exactly Thumb1 without any ARM mode and just a couple of extra instructions to handle system tasks.

I expect ARM2 code is a bit more compact than RV32IM -- they do get some benefit from predication, the free shifter on the 2nd argument, all those addressing modes, and LDM/STM. But RISC-V gets a decent size and speed benefit from the single-instruction "compare two registers and branch" instruction. And ARM needs to spill variables to RAM a lot more (and only passes 4 arguments in registers). I don't know if anyone has made a close comparison as ARM32 is basically obsolete and Thumb2 is what everyone uses. On RISC-V if you have more than maybe 1 KB of program code then it's a net benefit to implement the 16 bit instructions, so basically everyone does RV32IMC if not RV32IMAC (the Atomic instructions are trivial to implement if you only have one processor)

[technix]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Speaking of, since Cortex-A72 can still run ARM7TDMI code almost as-is, how much of ARM7TDMI isn’t covered in newer patents?

[GeorgeOfTheJungle]

And no one would buy them because they would suck [...]

But never as much as that chinese 3 cents µC 

[brucehoult]

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Interesting. $8 - $10.

Is there any good reason to use one of those rather than a Cortex M, other than "we already have a product and don't want to redesign it"?

[GeorgeOfTheJungle]

I don't think I've ever seen as much loathing of a computer design as you get when you push a paged solution, or as much relief as you get when you tell people you're going to stretch the address registers to solve their memory constraints.

Yes, exactly, the Apple IIe's AUX mem was perhaps the best example of how not to do it. Even worse, you can never be completely sure what state it's in after a reset!

[mikeselectricstuff]

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Interesting. $8 - $10.

Is there any good reason to use one of those rather than a Cortex M, other than "we already have a product and don't want to redesign it"?

Exactly this. Also lower volumes.
Would you rather a part you use in production went obsolete an unobtainable  overnight, or just increased in price ?

[nctnico]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Probably because these are old MCUs and are now being milked to support legacy designs. They used to be a whole lot cheaper a decade ago.

[coppice]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Probably because these are old MCUs and are now being milked to support legacy designs. They used to be a whole lot cheaper a decade ago.

They are probably cheap now, if you are a serious user still running a production line.

[brucehoult]

If it were ARM1 or ARM2 it could have been 1 cent: those cores have long past their patent expiry dates, and if you recreate the cores using a free implementation (e.g. the open source Amber core, which implements ARM2) there is nothing you need to pay other than fab. If you can squeeze the economy of scale up you get that price point.

ARM7TDMI was 1994. That should be out of protection now.

Then why is LPC2103 and AT91SAM7S128 still that damn expensive?

Probably because these are old MCUs and are now being milked to support legacy designs. They used to be a whole lot cheaper a decade ago.

They are probably cheap now, if you are a serious user still running a production line.

Serious users running production lines who only need ARM7TDMI performance (or even M3/M4) should probably be thinking about making their own SoC with as much as possible of the other chips they're using now integrated onto it.

I think you can now get a mask set for 180nm for $30k or so and even less for 350nm and then go into making a wafer worth of your custom SoC whenever you need for ... I'm not sure ... maybe $1 each.