Hacker News Reader

Comment by TreeRingCounter | Hacker News Reader

We've gotten to the point where a small 32-bit ARM core IC is cheaper than an 8-bit atmel core IC. I've stopped using 8-bit chips entirely in my designs.

View on HN

I wonder if that's because the lower power consumption of an 8 bit Atmel is now in itself a premium feature consumers think is worth paying for? Definitely useful for remote IoT nodes at the very edge, where battery life really matters.

> a small 32-bit ARM core IC is cheaper

Can you show an example.

stm32g0 parts (for example the stm32g030) can often be in the <$1 range, or <$0.50 at decent quantities. I think there is even an stm32c0 line planned at a lower price point.

There are likely lower cost parts, but the REALLY cheap 32 bit parts are moving to RISC-V, see WCH's recent releases.

Edit: as a specific example, the STM32G030F6P6TR is available at $0.74 for one, or $0.45/ea at qty 1000 over on JLCPCB's part list:

https://jlcpcb.com/partdetail/Stmicroelectronics-STM32G030F6...

I put some of these on a very recent project.

Here are ~200 examples from Digikey (sort by price->increasing at a reasonable quantity):

https://www.digikey.com/short/jjhtf0h8

These are Cortex-M0 and Cortex-M23 parts in manufacturer lines like Atmel SAMD10, Freescale KE04, Nuvoton Mini55, NXP LPC82x, Infineon PSOC4, STmicro STM32G0 and STM32F0, and others. And they often blow the 8-bit parts out of the water in features and performance, usually losing only in battery leakage current/active current consumption.

Technically they're often 16/32-bit ARM Thumb cores, not sure I'd call them 32-bit cores when 90% of the instructions you'll execute are 16 bits, even though the memory space and registers are 32 bits wide. I suppose they feel close enough to developers and users like 32 bit cores as opposed to something that's painfully, obviously, only 8 or 16 bits wide that you can just ignore that technicality...

fwiw: cortex-m parts would be pretty conclusively referred to as 32-bit parts (due to the 32-bit address space/pointers as well as 32-bits being the native word size of the platform).

Other 32 and 64 bit platforms support some kind of "compressed instruction" support, for example 32-bit ARMv7 microprocessors (think early android phones, original raspberry pi, etc.) also support the 16-bit Thumbv2 instruction mode, though thumbv2 support was removed in AArch64/ARMv8.

This is contrasted with a "true" 16-bit platform like msp430, which has 16-bit pointers and native 16-bit words.

RISC-V also has an optional compressed instruction set for both 32- and 64-bit platforms as well.

And the Xtensa LX6/LX7 use a compressed 24-bit instruction set, but are referred to as 32-bit chips, just to add to your overall point.

I agree, I think it's strange to make the instruction encoding influence whether or not a part is to be considered 32-bit.

Instead I think the programmer's model is what determines that (which would make these ARM cores firmly 32-bit like you say).

Reply on news.ycombinator.com