4 ms·

It's not obsolete if it's running the apps that you need. I've done embedded work on MCUs with less horsepower than you probably have in your headphones. Sure

It's not obsolete if it's running the apps that you need. I've done embedded work on MCUs with less horsepower than you probably have in your headphones. Sure it's not going to run windows 10, but it'll reliably control that device until the mechanical parts wear down. Same applies here, where the advantage of huge transistors means much greater resistance to cosmic rays, and a 20 year old design means all the bugs and quirks are well understood. The latest and greatest is nice, but not always the right choice for the problem at hand when you have the option of custom firmware and you aren't connected to a hostile internet.

com2kid 6y ago
> I've done embedded work on MCUs with less horsepower than you probably have in your headphones. MCUs are awesome. Given a 100mhz single core M3, half a meg of SRAM, some serious fun can be head. (honestly 512K SRAM would be insane, but doable now days) People don't realize that with a purpose built runtime and well crafted code, 100mhz is a LOT of power. Modern OSes, complicated software stacks, preemptive multi-tasking, and the need for flexible general purpose usage, eat up a huge percent (I'd say well over ~70%) of the usable computing capacity in the devices we deal with every day. Now I write web services that spend more CPU and RAM decoding JSON than entire runtimes I helped design. Go figure. Of course productivity is a bit higher, having to design and code the most optimal binary serialization formats for every single task takes a lot of time and effort, but wow is the end result fast and memory efficient!
- Espressosaurus 6y ago
  Half a meg of SRAM is typical for the ASICs I've worked with, so...not as insane as you might thing. Working with a 50 MHz ASIC on an old process with 256K of SRAM shared between two different companies and codebases, now that was fun.
- elihu 6y ago
  > Modern OSes, complicated software stacks, preemptive multi-tasking, and the need for flexible general purpose usage, eat up a huge percent (I'd say well over ~70%) of the usable computing capacity in the devices we deal with every day. I think a big part of it is security. Having to isolate address spaces is expensive. (Sometimes I like to imagine being able to run a unikernel OS where applications are written in something like safe Rust, everything runs in the same address space, and the OS delegates enforcing memory separation to a trusted compiler. So, things like writing to disk or the network are just regular function calls with no context switch overhead. In this model, unsafe code is treated sort of the way we treat kernel code or setuid binaries in Linux: regular users aren't allowed to run arbitrary unsafe code. With Spectre, I don't know if this sort of approach is still feasible on modern processors, or if it's possible for a compiler to guarantee that the compiled code is not susceptible to any known side-channel attacks.)
  - com2kid 6y ago
    > Sometimes I like to imagine being able to run a unikernel OS where applications are written in something like safe Rust, everything runs in the same address space, Better than that, static allocation. Embedded typically doesn't allow malloc anyway, so give me a platform that has the world's simplest MMU, static bounds checks that are put into write once read many memory upon boot. :-D
    - elihu 6y ago
      I was thinking it terms of general purpose computing, but yeah, static-only allocation make a lot of sense in some contexts (embedded, some HPC workloads) and that would sidestep the usual overhead of the allocator.

com2kid 6y ago

> I've done embedded work on MCUs with less horsepower than you probably have in your headphones. MCUs are awesome. Given a 100mhz single core M3, half a meg of SRAM, some serious fun can be head. (honestly 512K SRAM would be insane, but doable now days) People don't realize that with a purpose built runtime and well crafted code, 100mhz is a LOT of power. Modern OSes, complicated software stacks, preemptive multi-tasking, and the need for flexible general purpose usage, eat up a huge percent (I'd say well over ~70%) of the usable computing capacity in the devices we deal with every day. Now I write web services that spend more CPU and RAM decoding JSON than entire runtimes I helped design. Go figure. Of course productivity is a bit higher, having to design and code the most optimal binary serialization formats for every single task takes a lot of time and effort, but wow is the end result fast and memory efficient!

Espressosaurus 6y ago
Half a meg of SRAM is typical for the ASICs I've worked with, so...not as insane as you might thing. Working with a 50 MHz ASIC on an old process with 256K of SRAM shared between two different companies and codebases, now that was fun.
elihu 6y ago
> Modern OSes, complicated software stacks, preemptive multi-tasking, and the need for flexible general purpose usage, eat up a huge percent (I'd say well over ~70%) of the usable computing capacity in the devices we deal with every day. I think a big part of it is security. Having to isolate address spaces is expensive. (Sometimes I like to imagine being able to run a unikernel OS where applications are written in something like safe Rust, everything runs in the same address space, and the OS delegates enforcing memory separation to a trusted compiler. So, things like writing to disk or the network are just regular function calls with no context switch overhead. In this model, unsafe code is treated sort of the way we treat kernel code or setuid binaries in Linux: regular users aren't allowed to run arbitrary unsafe code. With Spectre, I don't know if this sort of approach is still feasible on modern processors, or if it's possible for a compiler to guarantee that the compiled code is not susceptible to any known side-channel attacks.)
- com2kid 6y ago
  > Sometimes I like to imagine being able to run a unikernel OS where applications are written in something like safe Rust, everything runs in the same address space, Better than that, static allocation. Embedded typically doesn't allow malloc anyway, so give me a platform that has the world's simplest MMU, static bounds checks that are put into write once read many memory upon boot. :-D
  - elihu 6y ago
    I was thinking it terms of general purpose computing, but yeah, static-only allocation make a lot of sense in some contexts (embedded, some HPC workloads) and that would sidestep the usual overhead of the allocator.