There is a simple reason why the 8-bit microcontroller continues to defy expectations and maintain impressive growth. Cost is king. If it is possible to solve a problem using an 8-bit microcontroller, it will cost less than solving the same problem using a 32-bit microcontroller.
There are applications that need a 32-bit MCU. Usually these are easy to identify. A good rule of thumb is that if a system needs to manipulate 32-bit data, then a 32-bit CPU is a good way to address it.
The vast majority of embedded systems however, only need to operate upon 8-bit data. That is because the control system will interface with inputs such as switches, sensors, keyboards and relatively slow serial communications systems. On the output side, we mostly see basic actuators (motors and solenoids), LEDs and other indicators. The problem can be solved more than adequately with an 8-bit solution.
It is not efficient to solve an 8-bit problem with a 32-bit solution. It is more expensive and wasteful to do so. 32-bit CPUs have an instruction length that is wider than an 8-bit instruction. Realistically, the code size that it takes a 32-bit CPU to implement an algorithm for an embedded control system will be around four times bigger than that of an 8-bit CPU.
This has been demonstrated again and again with benchmarks. Even in the more efficient ’16-bit instruction length’ operating modes, a 32-bit CPU will generate significantly more sizeable code. The bottom line is that if it takes 16kbytes of code to implement a given algorithm on an 8-bit machine, it will likely take 64kbytes of code to implement an equivalent algorithm on a 32-bit machine. The reality is that is costs less to buy a 16kbyte MCU than it does a 64kbyte microcontroller (most of the die size will be memory).
Don’t get me wrong – if the algorithm is 32-bit math intensive, then a 32-bit wide CPU will implement this more efficiently than an 8-bitter. The point is that a 32-bit CPU is a fantastic solution for operating on 32-bit data, but there is a significant cost in trying to solve an 8-bit problem with a 32-bit solution.
Another disadvantage of using 32-bit solutions when they are not required is that they will consume more power. To explain this simply, when arrays of 32 transistors are switching, more current will flow than when arrays of 8-bit transistors are switching. Usually significantly more current. Upon inspection, datasheets for 32-bit microcontrollers will reveal that the power consumption is higher in all modes of operation (Stop, Run, Wait, etc) than for an 8-bit microcontroller. That is why embedded systems that use batteries do not tend to use 32-bit CPUs.
Another reason why the 8-bit market is continuing to expand is that the 8-bit MCU suppliers are not sitting still. There has been an enormous amount of innovation in the 8-bit market in recent years. The original Intel 8051 operated at 1MHz and had a divide by 12 stage between the bus clock and the instruction clock. There are now 8051’s that will operate at 100MHz with no divide stage – an improvement of 1200 times faster. Instructions are also fewer cycles long – most are only 1 or 2 cycles. This gives a further performance improvement. In terms of CPU performance, it is not exaggerating to suggest that there is significant overlap between the performance of the fastest 8-bit MCU and the typical 32-bit MCU.
As well as being efficient with code size and having significantly improved performance, the 8-bit MCU has another major thing going for it. It is very easy to use. Development tools are mature, well understood and low cost.
There is lots of legacy code out there that is widely available. One estimate suggested that there is over 300 Million hours of development time invested in writing code for the 8051 alone.
In summary, 8-bit MCUs are always going to be a better fit for most embedded control applications. A better fit means a lower cost solution. If you wish to compare a 32-bit solution with an 8-bit solution, do not fall into the trap of considering equivalent memory sizes. Factor in that the 32-bit CPU will need about four times more memory to contain the bigger code that is necessary.
That is why the 8-bit MCU is here to stay.
Ross Bannatyne is director of marketing for MCUs at Silicon Labs