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

0 Members and 1 Guest are viewing this topic.

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 8156
  • 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: 1212
  • 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: 1212
  • 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: 1835
  • 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: 8156
  • 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: 121
  • 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: 8156
  • 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?
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5736
  • 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: 2073
  • 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

Offline coppice

  • Super Contributor
  • ***
  • Posts: 4755
  • 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
 

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

Offline 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: 2073
  • 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.
 

Offline 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: 2073
  • 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: 10402
  • 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: 9808
  • 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: 17991
  • 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf