Amazing to think that 8 years later these ATMegas are more expensive than some of the SoCs currently on the market in production linux devices.
https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solde...
You cam probably beat an ATMega with a STM32 of some kind. But the embedded world is more about simplicity of connecting to ADC / PWM / I2C and other such functionality. But even vs STM, ATMega supports 5V and full static (0Hz clock) operation.
You're not looking at MHz or RAM when you buy a microcontroller. You're looking at connectivity (which STM delivers... but there's still an ATMega / Arduino legacy advantage from a code perspective).
----------
20 years ago, plenty of people were making fun of 8051 boards that cost $100 but provided only 12MHz of clock and 256-bytes of RAM (not kB, literally bytes). The PC-market / high-level programmers always underestimate the importance of connectivity and overemphasize specs.
Embedded is mostly fine with 20MHz clocks: and arguably prefers less power usage (so things like "static 0Hz operation" are big features). Having an ATMega run at 100kHz clock rates for maximum power-savings but still providing the functionality you need (ie: Timers / ADC / etc. etc.) is pretty useful.
Or ATMegas can accept unregulated 5V, and just running off of USB-power (which can be between 4.5V to 5.5V in practice, exceeding the specs of STM32 chips). That simplifies the design of your board, since you don't need a buck-converter to go from 5V unregulated USB to 3.3V on the STM32.
You can run Linux directly on some STM32 MCUs. No emulation required!
https://github.com/torvalds/linux/tree/master/arch/arm/mach-...
That being said, static operation is really less of an issue than you're implying. Modern MCUs can idle (not sleep!) at under a milliamp; it's not difficult to get them to draw less average current than the leakage current of their battery. The lack of 5V operation is a little annoying in some scenarios, but is easily worked around with a 3.3V LDO -- which is frequently required anyway for interoperability with other components. (A switching converter is hardly necessary for a USB device drawing a couple milliamps.)
Nevertheless, that's still a fantastic achievement. And the ARM emulator makes it even more so.
> surely emulating 32-bit
> instructions from 8-bit
> doesn't take a thousand
> cycles on average.
The fact that I had to bit-bang the memory interface also does not help as the avr device has no dram controller
I had, at some point, rewritten the core in avr assembly for a large-ish speedup, but i never got around to publishing it.
Currently i am working on a TTL-built 1-bit computer, unto which i want to port this emulator, so boot linux on a 1-bit computer :)
With respect to functional utility though, it's possibly worth pointing out to others that Linux had (has?) an option to compile for MMU-less hardware. This was the basis for uClinux [0]. Though it supported pre-emptive multi-tasking I'm not sure it ever supported 8-bit CPUs.
Then there was LUnix [1] - a unix port for the C64 (written about a decade after the C64 came out). MMU-less, pre-emptive multi-tasking and (somewhat) usable. Not Linux, but still pretty amazing. Someone had even written a Small-C compiler for it [2]. You can watch a demo of it here [3].
People are very clever :)
[0] https://en.wikipedia.org/wiki/%CE%9CClinux
[1] http://lng.sourceforge.net/
[2] https://web.archive.org/web/20110106052323/http://www.reocit...