> This is definitely not the fastest, but I think it may be the cheapest, slowest, simplest to hand assemble, lowest part count, and lowest-end Linux PC.
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.
Yeah, but those Linux SoCs don't have a ADC or accurate PWM timers.
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.
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.)
> it's not difficult to get them to draw less average current than the leakage current of their battery.
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).
they can input 5v, sure, but they cannot output 5v, and that is still a pain. pullups and open-drain only get you so far (not very, if you need fast io)
True. I'm just dabbling so I haven't found this particularly annoying, so just curious what fast 5V I/O devices are still interesting? Display drivers?
You should never run microcontroller from an unregulated supply - it will brown out. USB is not unregulated, it just has bad precision, but regulation I am sure is pretty fine.
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.
I used AT90USB1286 for its timers that make easy to implement proper 3-phase sine motor control. The stuff you've mentioned does not have the same type of hardware.
I'm sure the author had a ton of fun achieving this. I must admit to loving this kind of thing despite the lack of utility.
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].
So today in theory according to https://elinux.org/STM32 you can buy an STM32F4 board which costs about 100RMB (USD$15) including external ethernet PHY and SD card and run Linux on it. It looks like STMicro is seeking a very competitive price point for STM32F407 class chips right now and you get USB OTG, camera, etc. as well as "more RAM than anyone will ever need". I would like to see that.
What does he mean by ARM emulator? Does it mean translating from ARM instruction set to AVR's? If so what is the 6.5 kHz about? An ATmega can probably run at a few MHz, surely emulating 32-bit instructions from 8-bit doesn't take a thousand cycles on average.
> 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 :)
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.
At that point, you probably do just want to go the path of the LGP-30. The registers are the most expensive part. While you could move them into RAM, that has the same performance cost as an accumulator machine, with more control complexity. If you were considering RISC (without compression, anyway) then you're likely not heavily pressed for code density to begin with. It probably could be done in under 100 gates, excluding the shift registers.
Since you are already using TTL parts -- would peripherals build from them (or similar discrete gates with whatever voltage levels you'd need) help to speed up the ARM emulator? I'm asking this because I'm actually not sure if such a thing would be faster than even bit-banging on the AVR. But I could imagine that things like the memory interface would benefit from a "hardware" implementation.
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...