Steve Ciarcia answers this question (What is the goal of targeting 6502 or Z80?) in his editorial in the April 2012 issue of Circuit Cellar magazine:
PRIORITY INTERRUPT
by Steve Ciarcia, Founder and Editorial Director
8-Bit Control Is Dead - No Way!
For years tech pundits have been predicting the end of 8-bit micros. Apparently, with the prices of 16- and 32-bit MCUs constantly dropping, and presuming you always want your application to do more stuff, there is no reason not to replace a less powerful MCU, right? In my opinion, it was a false assumption then, and it still is today.
We can’t look at this as a zero-sum game. Yes, 32-bitters open up all kinds of new opportunities for embedded processing, especially in the area of network-connected personal entertainment and information devices. But this doesn’t mean they’re a better fit in the low-end control and text-based applications that the 8-bitters have occupied for so long. The boundaries are certainly “fuzzy," but consider how we tend to generally categorize MCUs.
At the low end, we have the 8-bit controllers which typically have 8-bit data and registers along with 16-bit address paths. This is a sweet spot for all kinds of control and text~based functions that simply don`t need to handle more than 64 KB of data at a time. The price/performance of the 8-bit chip should win this fight every time.
In the midrange, we have the 16-bit MCUs and lower-end 16-bit DSP chips. These chips can do a bunch more because they handle 16-bit data and have at least 24-bit address paths. There is often a hardware multiplier as well, which makes this class of chip ideal for many types of signal processing and audio applications.
At the high end, there is the 32-bit MCU/MPU (and higher-end DSPs) that have 32-bit data and address paths. These are the chips that have the power to drive an interactive graphical user interface and process video signals in real time.
lt’s clear that chip manufacturers believe in the future of all three classes of MCU; just look at the innovations they continue to introduce at all levels. Fundamentally, as the silicon improves in terms of transistor density, more memory fits onto a smaller chip, and there’s more room for on-chip peripherals. Also, clock and power management has become a lot more flexible than ever before. The lower-end and midrange MCUs are all available with some combination of hardware timers (e.g., PWM, pulse capture, and motor control), communications (e.g., UART, SPI, IZC, CAN, USB, etc.), and analog interface (e.g., ADC, DAC, and touch). Some include hardware controllers for multiplexed LCDs or Ethernet interfaces.
At the higher end, in addition to all of that, we also see options like on-chip SDRAM controllers, SD memory and I/O controllers, Ethernet MAC (and sometimes PHY), mass storage (ATAPI, SATA) and video support, including in some cases a separate GPU core. Basically, everything you need to run a full-up operating system like Windows, MacOS, or Android.
Probably the greatest result of across-the-board lower MCU costs is that we will be seeing multiple chips where just one was used before. This has been the situation with automobiles for years where reliability has increased with lots of "smart"-control modules all networked together. Certainly, this make senses in a $30,000 car, but the concept is moving down the cost spectrum as well. Take your typical household washing machine or dryer that has a motor or two and a control panel. Instead of one chip handling all of the control functions and user interface I/O, there will be one (or two)
motor controller chip with a communications interface (e.g, SPI, I2C, CAN, etc.) and a second chip with a communications interface along with an LCD controller and touch sensor support.
lf the system designers are forvvard-thinking when they define the protocol by which these subsystems communicate, they’ll end up with intelligent building blocks (e.g., “smart motor,” “smart valve,” “smart sensor") that can be easily reused in other products, keeping manufacturing costs low. The modules themselves will be reliable and energy-efficient, contributing substantially to end-user satisfaction and low recurring costs. The key is to make each module just smart enough without going overboard on processing power or overloading it with a top-heavy protocol.
And, that’s where the lowly 8-bit MCU shines. A smart valve that just needs to sit on a LIN or 1-wire bus, operate a solenoid, and verify that it opened or closed doesn’t need a lot of CPU cycles or 32-bit addressing to do the job. One of the tiny 8-bitters in a six- or eight-pin package will do nicely, and might even cost less than the manufacturing cost and testing of the dedicated wiring harness needed to do the job in the traditional way. There’s no way a 16-bit or 32-bit MCU makes sense in this context. But more importantly, these lowly control tasks aren’t going to go away. ln fact, l think you’ll be seeing a lot more of them and they’ll all need MCUs. So, although it will be less visible, the 8-bit MCU will still be deeply embedded in increasingly subtle, but important, parts of your life, working hard so you don’t have to.
Received on Wed Apr 25 2012 - 23:47:00 UTC