Author Topic: 8-bit uC - is there even a point?  (Read 24258 times)

0 Members and 1 Guest are viewing this topic.

Offline newbie666

  • Regular Contributor
  • *
  • Posts: 60
8-bit uC - is there even a point?
« on: September 26, 2018, 12:23:02 pm »
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
 

Offline taydin

  • Frequent Contributor
  • **
  • Posts: 460
  • Country: tr
Re: 8-bit uC - is there even a point?
« Reply #1 on: September 26, 2018, 12:30:02 pm »
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.
« Last Edit: September 26, 2018, 12:33:47 pm by taydin »
Real programmers use machine code!

My hobby projects http://mekatronik.org/forum
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 7367
  • Country: nz
Re: 8-bit uC - is there even a point?
« Reply #2 on: September 26, 2018, 12:34:22 pm »
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.
 
« Last Edit: September 26, 2018, 12:43:24 pm by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: 8-bit uC - is there even a point?
« Reply #3 on: September 26, 2018, 12:52:12 pm »
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
 

Offline sokoloff

  • Super Contributor
  • ***
  • Posts: 1325
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #4 on: September 26, 2018, 12:58:41 pm »
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
 

Online NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 1804
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #5 on: September 26, 2018, 12:59:15 pm »
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.
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #6 on: September 26, 2018, 01:00:29 pm »
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.
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 3404
  • Country: gb
  • M0UAW
Re: 8-bit uC - is there even a point?
« Reply #7 on: September 26, 2018, 01:25:01 pm »
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.

M0UAW
 

Offline Warhawk

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: 00
    • Personal resume
Re: 8-bit uC - is there even a point?
« Reply #8 on: September 26, 2018, 01:49:11 pm »
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  :-DD

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..  :horse:
« Last Edit: September 26, 2018, 01:51:17 pm by Warhawk »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #9 on: September 26, 2018, 02:04:46 pm »
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.
« Last Edit: September 26, 2018, 02:07:29 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: petert

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #10 on: September 26, 2018, 02:58:00 pm »
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.
« Last Edit: September 26, 2018, 03:24:52 pm by legacy »
 

Offline newbie666

  • Regular Contributor
  • *
  • Posts: 60
Re: 8-bit uC - is there even a point?
« Reply #11 on: September 26, 2018, 03:08:40 pm »
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.
 

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 310
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #12 on: September 26, 2018, 03:16:26 pm »
I like that PIC16 has seperate port with max 8 pins,
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 391
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #13 on: September 26, 2018, 04:11:54 pm »
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
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: fr
Re: 8-bit uC - is there even a point?
« Reply #14 on: September 26, 2018, 05:14:35 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #15 on: September 26, 2018, 05:16:15 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 391
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #16 on: September 26, 2018, 06:08:17 pm »
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
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 6404
  • Country: de
Re: 8-bit uC - is there even a point?
« Reply #17 on: September 26, 2018, 06:49:58 pm »
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.
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 379
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #18 on: September 26, 2018, 09:19:49 pm »

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.
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #19 on: September 26, 2018, 10:54:02 pm »
... 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.
 
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #20 on: September 26, 2018, 11:01:18 pm »
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.
 
The following users thanked this post: petert

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: fr
Re: 8-bit uC - is there even a point?
« Reply #21 on: September 26, 2018, 11:24:28 pm »
... 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.
 

Offline digsys

  • Supporter
  • ****
  • Posts: 2061
  • Country: au
    • DIGSYS
Re: 8-bit uC - is there even a point?
« Reply #22 on: September 26, 2018, 11:59:34 pm »
Quote from: newbie666
... 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 :-)
Hello <tap> <tap> .. is this thing on?
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #23 on: September 26, 2018, 11:59:42 pm »
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.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: 8-bit uC - is there even a point?
« Reply #24 on: September 27, 2018, 12:06:13 am »
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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #25 on: September 27, 2018, 12:15:39 am »
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

 

Offline AndersJ

  • Regular Contributor
  • *
  • Posts: 231
  • Country: se
Re: 8-bit uC - is there even a point?
« Reply #26 on: September 27, 2018, 12:17:26 am »
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?
"It should work"
R.N.Naidoo
 

Online james_s

  • Super Contributor
  • ***
  • Posts: 9797
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #27 on: September 27, 2018, 12:23:36 am »
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.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #28 on: September 27, 2018, 12:42:41 am »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Offline thermistor-guy

  • Regular Contributor
  • *
  • Posts: 206
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #29 on: September 27, 2018, 12:43:59 am »
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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #30 on: September 27, 2018, 01:09:55 am »
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?
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #31 on: September 27, 2018, 01:37:38 am »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online Rerouter

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: au
  • Question Everything... Except This Statement
Re: 8-bit uC - is there even a point?
« Reply #32 on: September 27, 2018, 02:34:07 am »
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,
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 379
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #33 on: September 27, 2018, 03:51:13 am »
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.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #34 on: September 27, 2018, 08:01:35 am »
The PCB count

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

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #35 on: September 27, 2018, 08:27:10 am »
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  :o :o :o

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  :D
« Last Edit: September 27, 2018, 08:28:44 am by legacy »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #36 on: September 27, 2018, 08:57:53 am »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #37 on: September 27, 2018, 09:11:48 am »
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.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: 8-bit uC - is there even a point?
« Reply #38 on: September 27, 2018, 09:17:08 am »
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
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • Country: au
    • EEVblog
Re: 8-bit uC - is there even a point?
« Reply #39 on: September 27, 2018, 09:24:01 am »
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.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #40 on: September 27, 2018, 11:12:06 am »
if you want to prepare your students for the future

you'd better teach them how to design  :horse:
 
The following users thanked this post: wraper, JPortici

Offline rjp

  • Regular Contributor
  • *
  • Posts: 120
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #41 on: September 27, 2018, 11:24:30 am »
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.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #42 on: September 27, 2018, 11:38:22 am »
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.
« Last Edit: September 27, 2018, 11:52:19 am by wraper »
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: 8-bit uC - is there even a point?
« Reply #43 on: September 27, 2018, 12:19:57 pm »
if you want to prepare your students for the future

you'd better teach them how to design  :horse:


 :clap: unfortunately that requires the teacher to have a hint of experience in designing
« Last Edit: September 27, 2018, 01:04:45 pm by JPortici »
 

Offline brabus

  • Regular Contributor
  • *
  • Posts: 222
  • Country: it
Re: 8-bit uC - is there even a point?
« Reply #44 on: September 27, 2018, 01:15:34 pm »
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.
 

Offline Peabody

  • Frequent Contributor
  • **
  • Posts: 554
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #45 on: September 27, 2018, 01:47:42 pm »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #46 on: September 27, 2018, 02:36:26 pm »
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.
« Last Edit: September 27, 2018, 02:57:23 pm by Siwastaja »
 

Offline Whales

  • Frequent Contributor
  • **
  • Posts: 879
  • Country: au
    • Halestrom
Re: 8-bit uC - is there even a point?
« Reply #47 on: September 27, 2018, 04:47:05 pm »
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. 
« Last Edit: September 27, 2018, 04:49:03 pm by Whales »
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 369
Re: 8-bit uC - is there even a point?
« Reply #48 on: September 27, 2018, 05:10:54 pm »
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

 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #49 on: September 27, 2018, 05:18:52 pm »
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.
« Last Edit: September 27, 2018, 05:21:37 pm by Siwastaja »
 

Offline Whales

  • Frequent Contributor
  • **
  • Posts: 879
  • Country: au
    • Halestrom
Re: 8-bit uC - is there even a point?
« Reply #50 on: September 27, 2018, 05:56:35 pm »
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?

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: fr
Re: 8-bit uC - is there even a point?
« Reply #51 on: September 27, 2018, 06:19:21 pm »
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
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: 8-bit uC - is there even a point?
« Reply #52 on: September 27, 2018, 06:36:09 pm »
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.

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

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #53 on: September 27, 2018, 06:57:30 pm »
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
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #54 on: September 27, 2018, 07:41:08 pm »
As things go up, things also go down.
Sure, we have more and more ARM chips replacing 8-bitters, but we also have SiLego and iCE40 replacing Cyclone FPGAs.
As long as there is a market, no matter how many year it's been vacant, it will be filled, sooner or later.

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

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: 8-bit uC - is there even a point?
« Reply #55 on: September 27, 2018, 08:31:38 pm »
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/
 

Offline glarsson

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: 8-bit uC - is there even a point?
« Reply #56 on: September 27, 2018, 08:38:02 pm »
And the Apple watch (a typical wearable) has a 64 bit dual core ARM processor.
 

Offline sokoloff

  • Super Contributor
  • ***
  • Posts: 1325
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #57 on: September 27, 2018, 08:45:16 pm »
Quote
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?
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #58 on: September 27, 2018, 08:52:12 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #59 on: September 27, 2018, 09:11:26 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #60 on: September 27, 2018, 09:13:08 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #61 on: September 27, 2018, 09:22:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #62 on: September 27, 2018, 09:27:15 pm »
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
Quote
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
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #63 on: September 27, 2018, 09:27:38 pm »
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?
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #64 on: September 27, 2018, 09:31:19 pm »
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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #65 on: September 27, 2018, 09:33:49 pm »
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?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #66 on: September 27, 2018, 09:51:32 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • Country: au
    • EEVblog
Re: 8-bit uC - is there even a point?
« Reply #67 on: September 27, 2018, 10:46:19 pm »
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".
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • Country: au
    • EEVblog
Re: 8-bit uC - is there even a point?
« Reply #68 on: September 27, 2018, 10:47:17 pm »
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.
 
The following users thanked this post: Mr. Scram

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • Country: au
    • EEVblog
Re: 8-bit uC - is there even a point?
« Reply #69 on: September 27, 2018, 10:55:36 pm »
Quote
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #70 on: September 27, 2018, 11:36:48 pm »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: Mr. Scram

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #71 on: September 27, 2018, 11:43:07 pm »
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.
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 379
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #72 on: September 27, 2018, 11:54:43 pm »
.... 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.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #73 on: September 28, 2018, 12:23:10 am »


OT, but why everyone is using this stupid pricing structure? 100 parts is the same price of 91 parts. That means only idiots will buy 91~99 parts, but FFS why?
Why can't they use a more sensible price break system, such as the tax bracket system?
 

Online james_s

  • Super Contributor
  • ***
  • Posts: 9797
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #74 on: September 28, 2018, 12:58:42 am »
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.

 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #75 on: September 28, 2018, 01:01:15 am »
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?
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: 8-bit uC - is there even a point?
« Reply #76 on: September 28, 2018, 02:09:12 am »
Quote
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: 8-bit uC - is there even a point?
« Reply #77 on: September 28, 2018, 02:12:53 am »
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.
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #78 on: September 28, 2018, 04:26:59 am »
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.

 
The following users thanked this post: JPortici

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #79 on: September 28, 2018, 05:40:08 am »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #80 on: September 28, 2018, 05:59:11 am »
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #81 on: September 28, 2018, 06:12:45 am »
I'm sure you can run it bare-metal as well.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline rjp

  • Regular Contributor
  • *
  • Posts: 120
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #82 on: September 28, 2018, 06:21:01 am »
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 :)
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #83 on: September 28, 2018, 06:25:48 am »
I'm sure you can run it bare-metal as well.
Is there a convenient, accessible and well documented IDE though?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #84 on: September 28, 2018, 06:47:21 am »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #85 on: September 28, 2018, 08:39:31 am »
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?
« Last Edit: September 28, 2018, 08:53:27 am by Siwastaja »
 
The following users thanked this post: james_s

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #86 on: September 28, 2018, 09:33:32 am »
Quote
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #87 on: September 28, 2018, 10:41:44 am »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #88 on: September 28, 2018, 11:50:13 am »
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.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #89 on: September 28, 2018, 11:55:26 am »
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?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #90 on: September 28, 2018, 11:59:04 am »
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.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #91 on: September 28, 2018, 12:02:14 pm »
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
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #92 on: September 28, 2018, 12:06:37 pm »
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #93 on: September 28, 2018, 01:05:47 pm »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 369
Re: 8-bit uC - is there even a point?
« Reply #94 on: September 28, 2018, 02:15:35 pm »
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
Quote
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



 

Offline MT

  • Super Contributor
  • ***
  • Posts: 1179
  • Country: fo
Re: 8-bit uC - is there even a point?
« Reply #95 on: September 28, 2018, 02:56:23 pm »
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.
« Last Edit: September 28, 2018, 03:12:31 pm by MT »
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #96 on: September 28, 2018, 03:01:58 pm »
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.
« Last Edit: September 28, 2018, 03:04:07 pm by wraper »
 

Online james_s

  • Super Contributor
  • ***
  • Posts: 9797
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #97 on: September 28, 2018, 04:03:48 pm »
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.
 

Offline kaevee

  • Regular Contributor
  • *
  • Posts: 68
  • Country: in
Re: 8-bit uC - is there even a point?
« Reply #98 on: September 28, 2018, 05:21:15 pm »

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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #99 on: September 28, 2018, 05:27:54 pm »
Quote
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #100 on: September 28, 2018, 05:41:58 pm »
$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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #101 on: September 28, 2018, 06:15:55 pm »
$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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #102 on: September 28, 2018, 07:27:29 pm »
I'm sure you can run it bare-metal as well.

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

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 887
  • Country: gb
  • Embedded stuff
Re: 8-bit uC - is there even a point?
« Reply #103 on: September 28, 2018, 07:34:55 pm »
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
Bob
"All you said is just a bunch of opinions."
 
The following users thanked this post: Bassman59

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #104 on: September 28, 2018, 07:37:57 pm »
$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.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #105 on: September 28, 2018, 08:11:09 pm »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #106 on: September 28, 2018, 08:35:26 pm »
... 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!

 :-DD
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #107 on: September 28, 2018, 09:40:52 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: petert

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #108 on: September 28, 2018, 09:54:53 pm »
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #109 on: September 29, 2018, 12:57:32 am »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #110 on: September 29, 2018, 01:01:00 am »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #111 on: September 29, 2018, 08:38:32 am »
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.
 
The following users thanked this post: Mr. Scram

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #112 on: September 29, 2018, 08:46:17 am »
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.
« Last Edit: September 29, 2018, 08:57:53 am by Siwastaja »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #113 on: September 29, 2018, 09:16:18 am »
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.
« Last Edit: September 29, 2018, 09:26:44 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #114 on: September 29, 2018, 09:20:28 am »
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:


« Last Edit: October 03, 2018, 07:24:36 am by GeorgeOfTheJungle »
git diff *
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #115 on: September 29, 2018, 02:37:07 pm »
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.
 
The following users thanked this post: wraper, james_s

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #116 on: September 29, 2018, 06:32:11 pm »
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.
« Last Edit: September 29, 2018, 07:46:46 pm by GeorgeOfTheJungle »
git diff *
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #117 on: September 29, 2018, 06:49:57 pm »
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?

Quote
Semiconductor MCU revenue market forecast –millions of dollars
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #118 on: September 29, 2018, 06:51:46 pm »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 
The following users thanked this post: Siwastaja

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #119 on: September 29, 2018, 07:26:50 pm »
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.
git diff *
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #120 on: September 29, 2018, 08:12:08 pm »
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.
« Last Edit: September 29, 2018, 08:15:04 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #121 on: September 29, 2018, 08:31:02 pm »
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 ?
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #122 on: September 29, 2018, 08:35:06 pm »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 
The following users thanked this post: JPortici

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #123 on: September 29, 2018, 08:48:20 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #124 on: September 29, 2018, 08:58:31 pm »
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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #125 on: September 29, 2018, 09:06:11 pm »
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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #126 on: September 29, 2018, 09:10:10 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #127 on: September 29, 2018, 09:33:21 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: hans

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #128 on: September 29, 2018, 09:33:39 pm »
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.
 
The following users thanked this post: hans, petert

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #129 on: September 29, 2018, 09:41:25 pm »
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
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #130 on: September 29, 2018, 10:26:24 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #131 on: September 29, 2018, 11:05:17 pm »
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. ;)
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #132 on: September 29, 2018, 11:06:03 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #133 on: September 29, 2018, 11:09:17 pm »
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.
« Last Edit: September 29, 2018, 11:14:29 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja, petert

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #134 on: September 29, 2018, 11:11:21 pm »
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.
« Last Edit: September 29, 2018, 11:15:31 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #135 on: September 29, 2018, 11:13:20 pm »
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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #136 on: September 29, 2018, 11:29:09 pm »
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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #137 on: September 29, 2018, 11:31:23 pm »
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.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #138 on: September 30, 2018, 12:56:55 am »
Quote
[Simple ARM chips exist]
Quote
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.)"

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

 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1282
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #139 on: September 30, 2018, 02:51:34 am »
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.
 
The following users thanked this post: hans, petert

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: 8-bit uC - is there even a point?
« Reply #140 on: September 30, 2018, 04:02:37 am »
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.
 
The following users thanked this post: petert

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #141 on: September 30, 2018, 04:06:20 am »

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.
Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #142 on: September 30, 2018, 05:35:04 am »
Quote
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 :-(

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

Offline petert

  • Regular Contributor
  • *
  • Posts: 61
  • Country: de
Re: 8-bit uC - is there even a point?
« Reply #143 on: September 30, 2018, 06:32:21 am »
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.
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1282
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #144 on: September 30, 2018, 06:42:06 am »
Quote
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 :-(

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

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #145 on: September 30, 2018, 07:23:41 am »
Quote from: westfw link=topic=141497.msg
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
Quote
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #146 on: September 30, 2018, 07:32:41 am »
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):

1802RCA? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs).  2.5MHz @ 5V.
8080Intel? (still waiting for information)
8088Intel10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information)
8086IntelWDC says 182 clocks max total latency. * * * * *  (still waiting for information)
Z8ZilogIRET (E) takes 16 execution cycles.  I don't know how many clock cycles per execution cycle.  8MHz?
Z80Zilog11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz.  RETI (E) is 14 clocks, or 3.5μs @ 4MHz.
Z8000ZilogIRET (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.
8048Intel(?) return (E) is 2.7μs @ 11MHz
8051Dallas1.5μs @ 33MHz (52 clocks) latency
8051Intel1.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
80C51XAPhilips2.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.
KS88Samsung3μ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.
78K0NEC4.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.
COP8National70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles).  (7μs & 5μs @ 10MHz)
μPD78C05NECRETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz)
μPD70008/ANECsequence (C) takes 13 or 19 clocks.  Return (E) takes 14 clocks.
Instructions take 4-23 clocks each.  6MHz in '87 book.
V20NECRETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book.
Instruction set is a superset of that of 8086/8088.
V25NEC?  (still waiting for information)
68000Motorola46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?.  Has a very complex interrupt system.
6800Motorola(C)=13 clocks, including pushing the index register and both accumulators.  RTI (E) takes 10 clocks.  2MHz.
6809Motorola(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.
68HC05Motorola16 clocks typ (8μs @ 2MHz)
68HC08MotorolaInstructions 1-9 cy, or 0.125-1.125μs.  Avg 4-5 cy, or around 0.55μs.
68HC11Motorola(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.
68HC12Motorola2.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.
68HC16Motorola2.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.
PIC16Microchip(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.
TMS370TI15 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).
TMS7000TI(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.
ST6STM78 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.
ST7STM3μ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.
ST9STMExternal 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+STM1.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/300Hitachi8/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-51Silicon 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.
65C02WDCNormal 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!)

« Last Edit: September 30, 2018, 10:03:44 am by GeorgeOfTheJungle »
git diff *
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #147 on: September 30, 2018, 08:45:05 am »
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.
« Last Edit: September 30, 2018, 08:50:43 am by Siwastaja »
 
The following users thanked this post: nfmax

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #148 on: September 30, 2018, 10:17:29 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #149 on: September 30, 2018, 10:24:16 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #150 on: September 30, 2018, 10:40:21 am »
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.
 
The following users thanked this post: maginnovision

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #151 on: September 30, 2018, 11:18:03 am »
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.
« Last Edit: September 30, 2018, 11:30:31 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #152 on: September 30, 2018, 12:28:13 pm »
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.

 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #153 on: September 30, 2018, 12:44:50 pm »
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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #154 on: September 30, 2018, 03:06:46 pm »
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?
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #155 on: September 30, 2018, 03:22:20 pm »
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.

 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #156 on: September 30, 2018, 03:42:22 pm »
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
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1282
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #157 on: September 30, 2018, 04:31:12 pm »
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):

1802RCA? Most instructions take 16 clocks (6.4μs), some, 24 (9.6μs).  2.5MHz @ 5V.
8080Intel? (still waiting for information)
8088Intel10 bus cycles or 40 clocks(?) (B)+(C) (still waiting for further information)
8086IntelWDC says 182 clocks max total latency. * * * * *  (still waiting for information)
Z8ZilogIRET (E) takes 16 execution cycles.  I don't know how many clock cycles per execution cycle.  8MHz?
Z80Zilog11-19 clocks (B)+(C) depending on mode, or 2.75-4.75μs @ 4MHz.  RETI (E) is 14 clocks, or 3.5μs @ 4MHz.
Z8000ZilogIRET (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.
8048Intel(?) return (E) is 2.7μs @ 11MHz
8051Dallas1.5μs @ 33MHz (52 clocks) latency
8051Intel1.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
80C51XAPhilips2.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.
KS88Samsung3μ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.
78K0NEC4.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.
COP8National70 clocks (7 instruction cycles). RETI (E) is 50 clocks (5 instruction cycles).  (7μs & 5μs @ 10MHz)
μPD78C05NECRETI (E) takes 13 or 15 clocks (2.08 or 2.4μs at 6.25MHz)
μPD70008/ANECsequence (C) takes 13 or 19 clocks.  Return (E) takes 14 clocks.
Instructions take 4-23 clocks each.  6MHz in '87 book.
V20NECRETI (E) takes 39 clocks or 3.9μs @ 10MHz in '87 book.
Instruction set is a superset of that of 8086/8088.
V25NEC?  (still waiting for information)
68000Motorola46 clocks or 2.875μs minimum @ 16MHz (B)+(C)?.  Has a very complex interrupt system.
6800Motorola(C)=13 clocks, including pushing the index register and both accumulators.  RTI (E) takes 10 clocks.  2MHz.
6809Motorola(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.
68HC05Motorola16 clocks typ (8μs @ 2MHz)
68HC08MotorolaInstructions 1-9 cy, or 0.125-1.125μs.  Avg 4-5 cy, or around 0.55μs.
68HC11Motorola(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.
68HC12Motorola2.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.
68HC16Motorola2.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.
PIC16Microchip(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.
TMS370TI15 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).
TMS7000TI(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.
ST6STM78 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.
ST7STM3μ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.
ST9STMExternal 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+STM1.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/300Hitachi8/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-51Silicon 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.
65C02WDCNormal 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.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #158 on: September 30, 2018, 04:58:03 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #159 on: September 30, 2018, 05:11:42 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4775
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #160 on: September 30, 2018, 05:59:55 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #161 on: September 30, 2018, 07:15:06 pm »
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'.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1282
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #162 on: September 30, 2018, 07:33:19 pm »
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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #163 on: September 30, 2018, 07:59:15 pm »
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

 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1282
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #164 on: September 30, 2018, 08:16:49 pm »
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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #165 on: September 30, 2018, 08:30:34 pm »
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

 
The following users thanked this post: maginnovision

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #166 on: September 30, 2018, 08:59:44 pm »
Quote
(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."
« Last Edit: September 30, 2018, 10:13:36 pm by westfw »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4775
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #167 on: September 30, 2018, 09:18:46 pm »
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.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #168 on: September 30, 2018, 09:21:35 pm »
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.")
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #169 on: September 30, 2018, 09:37:59 pm »

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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #170 on: September 30, 2018, 09:56:10 pm »
Quote
    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!"
« Last Edit: September 30, 2018, 10:15:12 pm by westfw »
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #171 on: September 30, 2018, 10:11:24 pm »
Quote
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!
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #172 on: September 30, 2018, 10:24:32 pm »
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.
 
The following users thanked this post: Siwastaja

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #173 on: September 30, 2018, 10:29:39 pm »
Quote
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: 8-bit uC - is there even a point?
« Reply #174 on: September 30, 2018, 11:00:07 pm »
(One 16bit constant per instruction on MIPS. A 32bit constant needs two load instructions)
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: 8-bit uC - is there even a point?
« Reply #175 on: October 01, 2018, 12:04:29 am »
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.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #176 on: October 01, 2018, 01:32:40 am »
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  :palm:.

 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #177 on: October 01, 2018, 01:52:01 am »

Quote
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.  :-(
« Last Edit: October 01, 2018, 01:54:29 am by westfw »
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #178 on: October 01, 2018, 03:04:25 am »
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.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline rjp

  • Regular Contributor
  • *
  • Posts: 120
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #179 on: October 01, 2018, 03:08:06 am »
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 :)
 
The following users thanked this post: ogden

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #180 on: October 01, 2018, 07:04:13 am »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #181 on: October 01, 2018, 07:46:13 am »
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.
« Last Edit: October 01, 2018, 07:49:40 am by Siwastaja »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #182 on: October 01, 2018, 08:40:19 am »
http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  :palm:.

Complex RGB LED blinking patterns needs lots of fast PWM channels, CPU resources and memory  :-DD 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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #183 on: October 01, 2018, 09:07:05 am »
What's wrong with DIP? Why there's no ARMs in DIP? Damn it.
git diff *
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #184 on: October 01, 2018, 09:10:02 am »
http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  :palm:.
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.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #185 on: October 01, 2018, 09:21:58 am »
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #186 on: October 01, 2018, 09:29:57 am »
IIRC, according to Hackaday, that's not the case anymore.

https://hackaday.com/2018/04/15/rip-dip-arm/
« Last Edit: October 01, 2018, 10:15:14 am by GeorgeOfTheJungle »
git diff *
 

Offline rjp

  • Regular Contributor
  • *
  • Posts: 120
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #187 on: October 01, 2018, 09:33:54 am »
Cheap gumstick modules with all thr supporting passives appear to be the diy replacement.
 

Online mariush

  • Super Contributor
  • ***
  • Posts: 3833
  • Country: ro
  • .
Re: 8-bit uC - is there even a point?
« Reply #188 on: October 01, 2018, 09:41:43 am »
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
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #189 on: October 01, 2018, 09:58:39 am »
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
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #190 on: October 01, 2018, 10:11:24 am »
http://www.coolermaster.com/peripheral/keyboards/suppressor/
Boasting 72MHz 32 bit MCU and 128kB of flash in keyboard, as if does matter FFS  :palm:.

Complex RGB LED blinking patterns needs lots of fast PWM channels, CPU resources and memory  :-DD 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  |O. BTW it's not like it lost key press, any first press was registered as press- immediate release, thus key combinations failed.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #191 on: October 01, 2018, 10:13:49 am »
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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: GeorgeOfTheJungle

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #192 on: October 01, 2018, 10:32:41 am »
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.
« Last Edit: October 01, 2018, 10:34:18 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: GeorgeOfTheJungle

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #193 on: October 01, 2018, 10:39:43 am »

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
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4775
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #194 on: October 01, 2018, 11:06:28 am »
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.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2302
  • Country: de
    • Frank Buss
Re: 8-bit uC - is there even a point?
« Reply #195 on: October 01, 2018, 11:24:08 am »
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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5730
  • Country: nl
Re: 8-bit uC - is there even a point?
« Reply #196 on: October 01, 2018, 11:30:17 am »
Better to design your own small adapter board and add all the local jellybean stuff to get it working properly.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #197 on: October 01, 2018, 11:32:32 am »

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?
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #198 on: October 01, 2018, 11:49:07 am »
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #199 on: October 01, 2018, 02:48:26 pm »
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! :-)
git diff *
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #200 on: October 01, 2018, 02:55:03 pm »
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...  :scared:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #201 on: October 01, 2018, 04:08:18 pm »
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...  :scared:

digikey has plenty

 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #202 on: October 01, 2018, 04:09:51 pm »
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.
 
The following users thanked this post: hans, ogden

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #203 on: October 01, 2018, 04:26:03 pm »
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.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9204
  • Country: my
  • reassessing directives...
Re: 8-bit uC - is there even a point?
« Reply #204 on: October 01, 2018, 04:59:55 pm »
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.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #205 on: October 01, 2018, 05:47:45 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #206 on: October 01, 2018, 05:50:03 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #207 on: October 01, 2018, 05:54:16 pm »
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.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #208 on: October 01, 2018, 05:54:46 pm »
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.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #209 on: October 01, 2018, 05:58:05 pm »
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.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #210 on: October 01, 2018, 06:00:35 pm »
Like here at 4:30, they machine place TH capacitors but other stuff is placed by hand.

https://youtu.be/ylk6VMBLrvM
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
Re: 8-bit uC - is there even a point?
« Reply #211 on: October 01, 2018, 06:02:30 pm »
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
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #212 on: October 01, 2018, 06:06:09 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #213 on: October 01, 2018, 06:09:00 pm »
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  8)
The SMT parts where glued to the solder side and the whole PCB would then go through the wave soldering machine.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 12479
  • Country: cn
  • Power Electronics Guy
Re: 8-bit uC - is there even a point?
« Reply #214 on: October 01, 2018, 06:20:10 pm »
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.

A company can utilize such a machine will definitely grow out of THT in 2018. A company that still is stuck with THT can't justify such a machine.

FYI, a product line worker in Shenzhen works 12 hours a day, 6 days a week, can stuff a part in less than 5 seconds, and gets paid $500 per month. That's around 500 parts per dollar.

A modern machine can beat that price, but only at very high volume.
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #215 on: October 01, 2018, 06:23:05 pm »
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  8)
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.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #216 on: October 01, 2018, 07:12:38 pm »
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.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #217 on: October 01, 2018, 07:39:30 pm »
Quote
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.)

 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #218 on: October 02, 2018, 12:57:26 am »
Quote
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
« Last Edit: October 02, 2018, 11:53:10 am by ogden »
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #219 on: October 02, 2018, 01:53:09 am »
Well, this post certainly wanders all over the place ;-)
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3614
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #220 on: October 02, 2018, 05:03:29 am »
Quote
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. 

Quote
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.
« Last Edit: October 02, 2018, 05:05:02 am by KL27x »
 
The following users thanked this post: petert

Offline ogden

  • Super Contributor
  • ***
  • Posts: 2667
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #221 on: October 02, 2018, 08:35:33 am »
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.
« Last Edit: October 02, 2018, 11:58:16 am by ogden »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #222 on: October 02, 2018, 09:11:13 am »
Quote
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.
« Last Edit: October 02, 2018, 12:22:27 pm by Siwastaja »
 
The following users thanked this post: ogden

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8154
  • Country: 00
  • Display aficionado
Re: 8-bit uC - is there even a point?
« Reply #223 on: October 02, 2018, 10:20:14 am »
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.
 

Online Rerouter

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: au
  • Question Everything... Except This Statement
Re: 8-bit uC - is there even a point?
« Reply #224 on: October 02, 2018, 12:15:58 pm »
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,
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 4750
  • Country: gb
Re: 8-bit uC - is there even a point?
« Reply #225 on: October 02, 2018, 01:31:41 pm »
Quote
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.
 

Offline Nauris

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #226 on: October 02, 2018, 06:32:07 pm »
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  8)
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):
 

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #227 on: October 02, 2018, 06:44:49 pm »
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  8)
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.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: 8-bit uC - is there even a point?
« Reply #228 on: October 02, 2018, 07:02:28 pm »
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.
 

Offline Nauris

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #229 on: October 02, 2018, 08:06:45 pm »

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.
« Last Edit: October 02, 2018, 08:09:35 pm by Nauris »
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3066
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #230 on: October 02, 2018, 10:09:41 pm »
Quote
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.
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 379
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #231 on: October 03, 2018, 04:23:02 am »
Really, entire world? Then why new parts still appear no the market?

Quote
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
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 379
  • Country: au
Re: 8-bit uC - is there even a point?
« Reply #232 on: October 03, 2018, 04:33:48 am »
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...
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #233 on: October 03, 2018, 06:02:02 am »
Really, entire world? Then why new parts still appear no the market?

Quote
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: pl
Re: 8-bit uC - is there even a point?
« Reply #234 on: October 03, 2018, 07:25:01 am »
4.5x times the clock speed == 9.4x times faster:

« Last Edit: October 03, 2018, 10:08:42 am by GeorgeOfTheJungle »
git diff *
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2072
  • Country: fi
Re: 8-bit uC - is there even a point?
« Reply #235 on: October 03, 2018, 07:55:14 am »
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...

Quote
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!
« Last Edit: October 03, 2018, 07:58:46 am by Siwastaja »
 
The following users thanked this post: ogden

Offline wraper

  • Supporter
  • ****
  • Posts: 10388
  • Country: lv
Re: 8-bit uC - is there even a point?
« Reply #236 on: October 03, 2018, 08:30:23 am »
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.
« Last Edit: October 03, 2018, 09:38:02 am by wraper »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17970
  • Country: nl
    • NCT Developments
Re: 8-bit uC - is there even a point?
« Reply #237 on: October 03, 2018, 09:06:40 am »
Quote
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: JPortici

Offline MT

  • Super Contributor
  • ***
  • Posts: 1179
  • Country: fo
Re: 8-bit uC - is there even a point?
« Reply #238 on: October 03, 2018, 11:25:07 am »
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?
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12033
  • Country: gb
    • Mike's Electric Stuff
Re: 8-bit uC - is there even a point?
« Reply #239 on: October 03, 2018, 12:22:59 pm »
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
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: Siwastaja

Offline snarkysparky

  • Regular Contributor
  • *
  • Posts: 172
  • Country: us
Re: 8-bit uC - is there even a point?
« Reply #240 on: October 03, 2018, 07:24:18 pm »
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.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: 8-bit uC - is there even a point?
« Reply #241 on: October 03, 2018, 07:46:44 pm »
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.