Linux on an 8-Bit Micro? (2012)(dmitry.gr) |
Linux on an 8-Bit Micro? (2012)(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.)
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 :)
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.
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.
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.