10 ms·

What? More 8-Bit Microcontrollers?

socialdemocrat 4y ago
Cool, I really like AVR, but kind of wished there was like a 8-bit RISC-V or something with similar packaging and choices as AVR.
- snvzz 4y ago
  >a 8-bit RISC-V There's n-bit RISC-V implementations. The registers are still 32 or 64 bit wide, but the ALU is smaller and takes multiple steps. One such implementation is open source, but I sadly don't remember the name and can't find immediately.
  - FullyFunctional 4y ago
    There are oh-so-many, but the one you think of might be Olof's SERV (https://github.com/olofk/serv https://github.com/olofk/serv)
  - freemint 4y ago
    Yeah but the registers do not get smaller in that implementation.
- ChuckNorris89 4y ago
  Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) for applications that are perfectly served by mature, battle proven solutions which provide a reliable, cheap and quick time to market. AVR is today a pretty niche solution, but for it's niche it's better than Risc-V for its mature silicon and tooling, robust analog and digital 5V tolerant I/O, robust CPU and peripheral clocking, cycle accurate simulators, and experienced dev pool. The over 20 year old gas boiler my grandma has, is "powered" by an DIP packaged AVR chip and does the job just fine for controlling a couple of valves, LEDs, relays, and a PID loop. Same for the old elevator on my university. These kinds of apps is where the simplicity of AVR shines. Source: former AVR dev
  - FullyFunctional 4y ago
    I don't think anyone would seriously claim that the existing 8-bit architectures represent any optimal design point (AVR definitely does not). A constant cycle of innovation is what characterize all technology progress.
    - ChuckNorris89 4y ago
      Let's not let perfect be the enemy of good. A lot of embedded devices and white goods are profitable to build and sell in the economies of scale, because they can reuse an old microcontroller design like the AVR, which is not the pinnacle anymore, but that's been proven over decades to be robust and reliable for specific use cases. Technology progress is happening regardless, but not all products benefit from switching to the new shiny. Especially legacy boring products. Some AVR perks like 5V tolerant I/O, and pins able to sink high currents, is something rarely found on newer more modern ARM or RISC-V chips which tend to be more "fragile" in some regards. So this is why sich older chips could still be advantageous.
      - HeyLaughingBoy 4y ago
        > So this is why sich older chips could still be advantageous Yup. I just found myself having to buffer an ESP32's output with an LS245!! because the old-school LED display I needed to drive required more current on its logic inputs than the ESP could source. An AVR would have driven it just fine. And before anyone asked why I used a 74LS245 instead of a more appropriate level converter, I had to go with what's in stock these days and this design will have at most 3 units built.
    - nousermane 4y ago
      AVR might be not optimal in mathematical sense, but it feels so nice: - Tons of registers, up to a point where there are attiny parts with no RAM, and they are fairly usable; - Great code density for embedded - single-instruction atomic GPIO bit sets/bit resets, branch-if-bit-set/reset, etc; - In general, pretty approachable instruction set, if one fancies writing some assembly/machine code directly, while GCC also targets this ISA without issues; - Brilliant JTAG-like hardware debugging interface that uses zero extra pins (reset pin is reused), and hardware-wise, interfacing requires serial port + one diode, that's it [0] [0] https://github.com/dcwbrown/dwire-debug https://github.com/dcwbrown/dwire-debug
- throwaway81523 4y ago
  RISC is a 32 or 64 bit arch. There was some discussion of a 16 bit version but it didn't get traction. 8 bits wouldn't really work: who wants an 8 bit cpu with 32 bit wide instructions? From a software perspective I could see some attraction to new 8-bit architectures, but in market terms it is legacy space by now, it seems to me.
- Findecanor 4y ago
  That AVR has 8-bit registers isn't much of a benefit today. While it might make the AVR's core small, it requires more instructions to operate on 16-bit or 32-bit values — which a lot of code has to. For instance, an "int" in AVR C is 16 bits and because C does "integer promotion", it requires 16-bit semantics even when both operands are char. Despite having wider registers, I believe RISC-V cores could be made quite small too because of how lean its ISA is. As a hobbyist, I use AVR mostly because it is 5V-capable and electrically robust, so it can interface with vintage peripherals without requiring signal-level converters or additional ESD protection. It would be nice to see more competition in this space, for sure.
  - gsliepen 4y ago
    While the C standard does say that integer promotion happens, if the result is being cast back to char again, a C compiler will see that it doesn't need to operate on 16 bits and is allowed to optimize the result back to 8 bit operations. See for example: https://godbolt.org/z/zM8reeqrc https://godbolt.org/z/zM8reeqrc
  - hajile 4y ago
    I feel like 16-bit MCs aren't popular because they aren't popular. They offer a straight-up 2x performance increase in most applications and something like a 4-10x performance increase with 32-bit numbers (not to mention the space savings from fewer instructions). Despite this, the 16-bit MCs all seem to be rather niche. I'd love for an open RISC-V variant that could fill this gap and allow sourcing of the same ISA from multiple companies.
- PaulHoule 4y ago
  I dunno. AVR-8 is basically the last 8 bit CPU so it is much better than the CPUs we remember from the 1980s like the Z80, 6502, 6809, in most respects except RAM size. 32 registers is a lot! It also takes advantage of the Harvard architecture and has none of this pipelining and cache BS, most instructions take a cycle so if it runs at 20MHz it is basically running at 20 MIPS. Assembly language is beautiful and thinking about writing C for it makes me want to cry. The one issue is that it has no upgrade path to anything more powerful so if you want something better it is going to be ARM or ESP32 so you might just keep writing portable C.
- deleted 4y ago
  [deleted]
- phendrenad2 4y ago
  Why do you want that? What do you think that would look like? What about it appeals to you? Specifically?
kuon 4y ago
As a side note, I am trying zig for embedded on tiny MCU and it is a better fit than rust. Not having to "move the borrow" for register around makes the code simpler to reason about and also is important when flash is only a few kb. I think both languages have their applications and I am really happy with both. I hope both languages (and others!) will help us make quality and robust softwares in the long run.
- lr1970 4y ago
  When you are coding in Rust for tiny MCU sooner or later you would code some functions in assembler or in unsafe Rust. At this point Rust does not provide much of the advantages over Zig as far as safety guarantees are concerned. Lightweight Zig seems to fit this space better that heavy Rust.
  - rowanG077 4y ago
    Besides the CTE and Cross compiling, what is objectively better in Zig then in Rust? Just the Rust ecosystem would sway me towards it honestly instead of something esotoric like Zig. Writing unsafe Rust is not really a problem I have.
    - kuon 4y ago
      Well, I am not saying it is better objectively, but for my uses it was easier. I wrote a firmware in rust and I rewrote it in zig as my first real world exercice, I ended up with 90% less code. Rust has really great abstraction and I like it, but for some things it is overkill. In zig I didn't need much of the abstraction because I did not have to make the borrow checker happy. In rust you have to structure your code in a way each part of it will have access to what it needs. In zig you just access it, as a global if needed. And sometimes the ability that zig code have to fit in memory (mine) is a real productivity boost.
  - throwaway81523 4y ago
    Small MCU programming usually doesn't use dynamic memory allocation at all. Does Rust bring borrowing into play in any other situations? I don't know anything about Zig and should probably look into it, but I think Ada is underrated for MCU's.
kristianpaul 4y ago
“Also, that the 8-bit machines are seeing increasing use as co-processors, performing tasks like taking sensor readings and pre-processing this sensor data before passing it on to the higher-level processor.”
- Glawen 4y ago
  I just came out of a embedded Linux training, and the guy basically told us that if we want to have hard real time constraints, it is easier to execute real time stuff on a dedicated microcontroller on the side. I find it crazy that we need such a powerful MCU to run Linux, but still it is not fit for real time.
  - 2rsf 4y ago
    When I worked at Qualcomm this is exactly what we used to do, if I rememeber correctly even parts of the USB driver used to run on one.
  - radarsat1 4y ago
    It really depends on what you're doing, but there are certainly versions of Linux that are capable of hard real-time performance. But it shouldn't be too surprising that the goals of an operating system designed for multiuser, multiprocess context is not well aligned with the needs of real-time machine control applications. The trainer is correct, often times it really is appropriate to just delegate those requirements to a dedicated controller whose job is to do nothing else than keep performing the same DSP loop over and over in a well-timed manner. However, there are certainly cases where you might want to interact smoothly between real-time and non-real-time components of a system and use things like shared memory, and in those cases, there definitely are Linux-based solutions available. Like most things in engineering, there are trade-offs along this continuum, so knowing the options and the pros and cons so that you can make a good design decision is just part of the job.
    - freemint 4y ago
      Hard real time, yes. But with very high tolerances compared to what a MHz processor can accomplish just running the application.
the__alchemist 4y ago
Do these have cost savings over a budget-series 32-bit MCU, eg using Cortex-M0? For example, STM32G0 is very cheap (~$1-4 USD depending on variant and quantity), and has a number of peripherals. My guess: 8-bit MCUs are used for high-production run, minimal cost uses where the MCU does one specific task, probably in a network with other MCUs. In these cases, they could offer cost savings, even over an M0/M0+.
- iasay 4y ago
  Yes. You can get an 8-bit for $0.15 in quantity and they go down to 6-pin SOT-23 or even smaller parts. The PIC10F320 is an interesting one as it can replace a fairly large amount of discrete logic very easily. I think I paid $0.47 in one off quantity for those! It was used to entirely replace a couple of timers and a state machine.
- deleted 4y ago
  [deleted]

Cool, I really like AVR, but kind of wished there was like a 8-bit RISC-V or something with similar packaging and choices as AVR.

snvzz 4y ago
>a 8-bit RISC-V There's n-bit RISC-V implementations. The registers are still 32 or 64 bit wide, but the ALU is smaller and takes multiple steps. One such implementation is open source, but I sadly don't remember the name and can't find immediately.
- FullyFunctional 4y ago
  There are oh-so-many, but the one you think of might be Olof's SERV (https://github.com/olofk/serv https://github.com/olofk/serv)
- freemint 4y ago
  Yeah but the registers do not get smaller in that implementation.
ChuckNorris89 4y ago
Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) for applications that are perfectly served by mature, battle proven solutions which provide a reliable, cheap and quick time to market. AVR is today a pretty niche solution, but for it's niche it's better than Risc-V for its mature silicon and tooling, robust analog and digital 5V tolerant I/O, robust CPU and peripheral clocking, cycle accurate simulators, and experienced dev pool. The over 20 year old gas boiler my grandma has, is "powered" by an DIP packaged AVR chip and does the job just fine for controlling a couple of valves, LEDs, relays, and a PID loop. Same for the old elevator on my university. These kinds of apps is where the simplicity of AVR shines. Source: former AVR dev
- FullyFunctional 4y ago
  I don't think anyone would seriously claim that the existing 8-bit architectures represent any optimal design point (AVR definitely does not). A constant cycle of innovation is what characterize all technology progress.
  - ChuckNorris89 4y ago
    Let's not let perfect be the enemy of good. A lot of embedded devices and white goods are profitable to build and sell in the economies of scale, because they can reuse an old microcontroller design like the AVR, which is not the pinnacle anymore, but that's been proven over decades to be robust and reliable for specific use cases. Technology progress is happening regardless, but not all products benefit from switching to the new shiny. Especially legacy boring products. Some AVR perks like 5V tolerant I/O, and pins able to sink high currents, is something rarely found on newer more modern ARM or RISC-V chips which tend to be more "fragile" in some regards. So this is why sich older chips could still be advantageous.
    - HeyLaughingBoy 4y ago
      > So this is why sich older chips could still be advantageous Yup. I just found myself having to buffer an ESP32's output with an LS245!! because the old-school LED display I needed to drive required more current on its logic inputs than the ESP could source. An AVR would have driven it just fine. And before anyone asked why I used a 74LS245 instead of a more appropriate level converter, I had to go with what's in stock these days and this design will have at most 3 units built.
  - nousermane 4y ago
    AVR might be not optimal in mathematical sense, but it feels so nice: - Tons of registers, up to a point where there are attiny parts with no RAM, and they are fairly usable; - Great code density for embedded - single-instruction atomic GPIO bit sets/bit resets, branch-if-bit-set/reset, etc; - In general, pretty approachable instruction set, if one fancies writing some assembly/machine code directly, while GCC also targets this ISA without issues; - Brilliant JTAG-like hardware debugging interface that uses zero extra pins (reset pin is reused), and hardware-wise, interfacing requires serial port + one diode, that's it [0] [0] https://github.com/dcwbrown/dwire-debug https://github.com/dcwbrown/dwire-debug
throwaway81523 4y ago
RISC is a 32 or 64 bit arch. There was some discussion of a 16 bit version but it didn't get traction. 8 bits wouldn't really work: who wants an 8 bit cpu with 32 bit wide instructions? From a software perspective I could see some attraction to new 8-bit architectures, but in market terms it is legacy space by now, it seems to me.
Findecanor 4y ago
That AVR has 8-bit registers isn't much of a benefit today. While it might make the AVR's core small, it requires more instructions to operate on 16-bit or 32-bit values — which a lot of code has to. For instance, an "int" in AVR C is 16 bits and because C does "integer promotion", it requires 16-bit semantics even when both operands are char. Despite having wider registers, I believe RISC-V cores could be made quite small too because of how lean its ISA is. As a hobbyist, I use AVR mostly because it is 5V-capable and electrically robust, so it can interface with vintage peripherals without requiring signal-level converters or additional ESD protection. It would be nice to see more competition in this space, for sure.
- gsliepen 4y ago
  While the C standard does say that integer promotion happens, if the result is being cast back to char again, a C compiler will see that it doesn't need to operate on 16 bits and is allowed to optimize the result back to 8 bit operations. See for example: https://godbolt.org/z/zM8reeqrc https://godbolt.org/z/zM8reeqrc
- hajile 4y ago
  I feel like 16-bit MCs aren't popular because they aren't popular. They offer a straight-up 2x performance increase in most applications and something like a 4-10x performance increase with 32-bit numbers (not to mention the space savings from fewer instructions). Despite this, the 16-bit MCs all seem to be rather niche. I'd love for an open RISC-V variant that could fill this gap and allow sourcing of the same ISA from multiple companies.
PaulHoule 4y ago
I dunno. AVR-8 is basically the last 8 bit CPU so it is much better than the CPUs we remember from the 1980s like the Z80, 6502, 6809, in most respects except RAM size. 32 registers is a lot! It also takes advantage of the Harvard architecture and has none of this pipelining and cache BS, most instructions take a cycle so if it runs at 20MHz it is basically running at 20 MIPS. Assembly language is beautiful and thinking about writing C for it makes me want to cry. The one issue is that it has no upgrade path to anything more powerful so if you want something better it is going to be ARM or ESP32 so you might just keep writing portable C.
deleted 4y ago
[deleted]
phendrenad2 4y ago
Why do you want that? What do you think that would look like? What about it appeals to you? Specifically?

kuon 4y ago

As a side note, I am trying zig for embedded on tiny MCU and it is a better fit than rust. Not having to "move the borrow" for register around makes the code simpler to reason about and also is important when flash is only a few kb. I think both languages have their applications and I am really happy with both. I hope both languages (and others!) will help us make quality and robust softwares in the long run.

lr1970 4y ago
When you are coding in Rust for tiny MCU sooner or later you would code some functions in assembler or in unsafe Rust. At this point Rust does not provide much of the advantages over Zig as far as safety guarantees are concerned. Lightweight Zig seems to fit this space better that heavy Rust.
- rowanG077 4y ago
  Besides the CTE and Cross compiling, what is objectively better in Zig then in Rust? Just the Rust ecosystem would sway me towards it honestly instead of something esotoric like Zig. Writing unsafe Rust is not really a problem I have.
  - kuon 4y ago
    Well, I am not saying it is better objectively, but for my uses it was easier. I wrote a firmware in rust and I rewrote it in zig as my first real world exercice, I ended up with 90% less code. Rust has really great abstraction and I like it, but for some things it is overkill. In zig I didn't need much of the abstraction because I did not have to make the borrow checker happy. In rust you have to structure your code in a way each part of it will have access to what it needs. In zig you just access it, as a global if needed. And sometimes the ability that zig code have to fit in memory (mine) is a real productivity boost.
- throwaway81523 4y ago
  Small MCU programming usually doesn't use dynamic memory allocation at all. Does Rust bring borrowing into play in any other situations? I don't know anything about Zig and should probably look into it, but I think Ada is underrated for MCU's.

kristianpaul 4y ago

“Also, that the 8-bit machines are seeing increasing use as co-processors, performing tasks like taking sensor readings and pre-processing this sensor data before passing it on to the higher-level processor.”

Glawen 4y ago
I just came out of a embedded Linux training, and the guy basically told us that if we want to have hard real time constraints, it is easier to execute real time stuff on a dedicated microcontroller on the side. I find it crazy that we need such a powerful MCU to run Linux, but still it is not fit for real time.
- 2rsf 4y ago
  When I worked at Qualcomm this is exactly what we used to do, if I rememeber correctly even parts of the USB driver used to run on one.
- radarsat1 4y ago
  It really depends on what you're doing, but there are certainly versions of Linux that are capable of hard real-time performance. But it shouldn't be too surprising that the goals of an operating system designed for multiuser, multiprocess context is not well aligned with the needs of real-time machine control applications. The trainer is correct, often times it really is appropriate to just delegate those requirements to a dedicated controller whose job is to do nothing else than keep performing the same DSP loop over and over in a well-timed manner. However, there are certainly cases where you might want to interact smoothly between real-time and non-real-time components of a system and use things like shared memory, and in those cases, there definitely are Linux-based solutions available. Like most things in engineering, there are trade-offs along this continuum, so knowing the options and the pros and cons so that you can make a good design decision is just part of the job.
  - freemint 4y ago
    Hard real time, yes. But with very high tolerances compared to what a MHz processor can accomplish just running the application.

the__alchemist 4y ago

Do these have cost savings over a budget-series 32-bit MCU, eg using Cortex-M0? For example, STM32G0 is very cheap (~$1-4 USD depending on variant and quantity), and has a number of peripherals. My guess: 8-bit MCUs are used for high-production run, minimal cost uses where the MCU does one specific task, probably in a network with other MCUs. In these cases, they could offer cost savings, even over an M0/M0+.

iasay 4y ago
Yes. You can get an 8-bit for $0.15 in quantity and they go down to 6-pin SOT-23 or even smaller parts. The PIC10F320 is an interesting one as it can replace a fairly large amount of discrete logic very easily. I think I paid $0.47 in one off quantity for those! It was used to entirely replace a couple of timers and a state machine.
deleted 4y ago
[deleted]