|
Well, I disagree with yours! What cases are you thinking of when you say "Plenty of people are still using technology developed thousands of years ago even when there are modern alternatives that are thousands of times more efficient"? I considered hand sewing, cultivation with digging sticks instead of tractors, cooking over wood fires, walking, execution by stoning, handwriting, and several other possibilities, but none of them fit your description. In most cases the modern alternatives are less efficient but easier to use, but in every case I can think of where the efficiency ratio reaches a thousand or more in favor of the new technology, the thousands-of-years-old technology is abandoned, except by tiny minorities who are either impoverished or deliberately engaging in creative anachronisms. I don't think "the relative simplicity of old technology" is a good argument for attempting to control your tractor with a Z80 instead of an ATSAMD20. You have to hook up the Z80 to external memory chips (both RAM and ROM) and an external clock crystal, supply it with 5 volts (regulated with, I think, ±2% precision), provide it with much more current (which means bypassing it with bigger capacitors, which pushes you towards scarcer, shorter-lived, less-reliable electrolytics), and program it in assembly language or Forth. The ATSAMD20 has RAM, ROM, and clock on chip and can run on anywhere from 1.62 to 3.63 volts, and you can program it in C or MicroPython. (C compilers for the Z80 do exist but for most tasks performance is prohibitively poor.) You can regulate the ATSAMD20's voltage adequately with a couple of LEDs and a resistor, or in many cases just a resistor divider consisting of a pencil lead or a potentiometer. It would be pragmatically useful to use a Z80 if you have an existing Z80 codebase, or if you're familiar with the Z80 but not anything current, or if you have Z80 documentation but not documentation for anything current, or if you can get a Z80 but not anything current. (One particular case of this last is if the microcontrollers you have access to are all mask-programmed and don't have an "external access" pin like the 8048, 8051, and 80C196 family to force them to execute code from external memory. In that case the fact that the Z80 has no built-in code memory is an advantage instead of a disadvantage. But, if you can get Flash-programmed microcontrollers, you can generally reprogram their Flash.) Incidentally, the Z80 itself "only" uses about 500 milliwatts, and there are Z80 clones that run on somewhat less power and require less extensive external supporting circuitry. (Boston Scientific's pacemakers run on a Z80 softcore in an FPGA, for example, so they don't have to take the risk of writing new firmware.) But the Z80's other drawbacks remain. |
There are a bazillion Z80s and 8051s, and many of them are in convenient packages like DIP. You can probably scavenge some from your nearest landfill using a butane torch to desolder them from some defunct electronics.
In contrast, there are a trillion flavours of modern MCUs, not all drop-in interchangeable. If your code and tooling is designed for an ATSAMD20, great, but I only have a bag of CH32V305s. Moreover, you're moving towards finer pitches and more complex mounting-- going from DIP to TSSOP to BGA mounting, I'd expect every level represents a significant dropoff of how many devices can be successfully removed and remounted by low-skill scavengers.
I suppose the calculus is different if you're designing for "scavenge parts from old games consoles" versus proactively preparing a hermetically sealed "care package" of parts pre-selected for maximum usability.