Software and hardware obsolescence in the kernel

Posted Aug 31, 2020 1:22 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Software and hardware obsolescence in the kernel by iabervon
Parent article: Software and hardware obsolescence in the kernel

8-bit microcontrollers are dying. I'm seeing plenty of people switching to 32-bit ARMs with something like 8-32kb of RAM.

Turns out that the toolchains for 8-bit just suck and you have a hard limit of 64kb for direct addressability. So a switch to 32 bits will cause a hit to the code size, but you're likely not writing anything complex involving tons of pointers anyway.

Software and hardware obsolescence in the kernel

Posted Aug 31, 2020 3:34 UTC (Mon) by excors (subscriber, #95769) [Link]

You can even get a 32-bit Cortex-M3 at 32MHz with 2KB of RAM (https://www.silabs.com/mcu/32-bit/efm32-tiny-gecko), or a Cortex-M0+ with 1KB RAM (https://www.nxp.com/docs/en/data-sheet/LPC81XM.pdf). It looks like 8/16-bit MCUs are getting pushed out by the convenience of having a consistent high-quality ARM-based development environment across the whole product range, and the performance cost of 32-bit is still acceptable down to that level.

Software and hardware obsolescence in the kernel

Posted Aug 31, 2020 5:36 UTC (Mon) by jem (subscriber, #24231) [Link]

It's a slow death. You have to take human factors into account, too. A few years ago I met a hardware guy who had designed a new device based on an Atmel microcontroller. This Atmel device was available in two versions, pin compatible with identical peripherals. The only difference was that one version had an ARM core, and the other one had a 8-bit 8051 core. Of course he had chosen the 8051 version, because that was what he was familiar with writing software to (in assembly).

The cost of moving to a 32-bit RISC core is essentially negligible today. A RISC-V core can be implemented in 0.28 mm².