Linux on an 8-Bit Micro? (2012)
dmitry.gr
dmitry.gr
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.)
Well... depends on the battery. A bog-standard AA Alkaline battery has 2500 mA-hr (from 1.5V to 1V, @100mA draw: https://data.energizer.com/pdfs/e91.pdf), and have a ~3%/year self discharge rate. That's a leakage current of 75mA-hrs / year, or ~10 uA if I did my math correctly. Lithium, and watch button batteries (Silver) leak even less!
ATTiny 1607 is specified at 6uA at 1.8V @ 32kHz active mode (though 5V barely is any more current). It looks like STM32G031J4 is ~20 uA at "low-power mode" @ 1.8V 32kHz (a special mode below 2MHz). Which is a lot better than I was expecting. (Note to others who may not know this: this is likely a Cortex-M0+ design only. Typical ARMs will not be able to reach this low level of power. Heck, larger STM32 Cortex-M4 processors probably have a much higher minimum clockrate)
Both chips are ~200 uA at 2MHz, Which gets you to ~500 days of continuous operation from 2500 mA-hr AA.
------
Yeah, there's a bunch of batteries that self-discharge in just 3-months. But... alkaline AA exist for a reason! Low-self discharge, and they're actually really good at these milliamp/microamp levels of current. And again, its all about those silver-watch batteries or lithium-watch batteries if you really want the lowest self-discharge in the market. (~5 years per silver-watch battery, but you need to draw stupidly low amounts of current).
It seems like the ATTiny 1607 still has a superior sleep mode compared to STM32G031J4, so if you're sleeping most of the time on a watch battery, maybe ATTiny wins.
I do agree with you though: it does seem like STM32 has really dropped their power down a lot. I don't know if STM32 always supported 32kHz clock rates however, I seem to remember them having a higher minimum clock rate last time I checked this out. Lowering those clock speeds really helps at minimizing power. And I expect AA-batteries to be the typical size of most people's hobby projects.
I dunno if "full static" is really needed, since 32kHz is still really, really low power. It seems nice that ATTiny / ATMegas hve 0Hz as an option (maybe if an external temporary clock turns on only occasionally in a power-constrained environment).
It should be noted many STM32's (if not all, huge family) have 5V tolerant I/O pins, so it's not nearly as annoying as it could be.
Looks like a pretty unregulated power supply to me, lol.
I realize you're talking about normal use, and not abuse like this avrTiny example, but... those Microchip / Atmel chips are pretty legendary with regards to the electrical abuse they withstand.
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...
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.
It does if you do it in C, and also need to emulate the mmu and permission checks. Plus arm's instructions do a lot. A free arbitrary 32-bit shift in every instruction is hard on an 8-bit device which can only shift 8 bits by one bit per instruction. You end up with a lot of loops, and loop control instrs kill perf there.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 :)
One of the most popular SIMD computers in the late 80s was the CM-2: a 4096x wide 1-bit computer. All SIMD-instructions.
So it can definitely be used "seriously".
I've really enjoyed RISC V serial (SERV) presentation - 1-bit computer essentially. Wonder how low one can get in terms of transistor count, without going the path of LGP-30.