Compare the use cases of 8-bit MCU and 32-bit MCU as a selection guide

How to choose between 8-bit and 32-bit MCUs? 8-bit and 32-bit MCUs are still mutually complementary and have their own functions. The trick is to understand what kind of MCU architecture is suitable for the application.

This article compares the use cases of 8-bit MCUs and 32-bit MCUs, and can also be used as a guide to how to choose these two MCU architectures. Most of the 32-bit MCU examples in this article will focus on the ARM Cortex-M, which performs very similarly across different MCU vendor portfolios. Given the wide variety of architectures for 8-bit MCUs, it is difficult to make a similar comparison of 8-bit vendor products. For ease of comparison, we will use the widely used, easy-to-understand 8051 architecture that is favored by embedded developers.

How to choose 8-bit and 32-bit MCUs?

Sometimes, when I compare things that people are familiar with (such as ARM and 8051), it feels like "StarCraft" is better than "Star Wars" on the Internet of Things forum. .

In fact, ARM Cortex and 8051 which is better is not a logical problem, just like asking: Which is better for guitar and piano? The real problem to be solved is which MCU can help me better solve the problems I face now. Different tasks require different tools, and our goal is to understand "how to better use the tools we have," including 8-bit and 32-bit MCUs. It is almost certain that those who simply answer "ARM is better" or "8051 is better" have their own purposes, and they may be trying to sell a certain product.

Compare different devices and measure them. There are a lot of build tools to choose from, we try to choose some scenarios, I think it can make the most fair comparison, and best represent the real experience of the developer.

Not all MCUs are the same

Before starting to compare the architecture, it's important to note that not all MCUs are produced the same. If you compare a modern MCU based on the ARM Cortex M0+ processor with the 8051 MCU 30 years ago, the 8051 MCU won't beat the performance comparison. Fortunately, there are still many suppliers who have been investing in 8-bit processors. In many applications, 8-bit cores can still compensate for the disadvantages of the M0+ or ​​M3 cores, and even better in some respects.

Development tools are also important. Modern embedded firmware development requires a full-featured IDE, an off-the-shelf firmware library, a rich set of examples, a complete evaluation and starter kit, and a helper application to simplify things like hardware setup, library management, and production programming. When MCUs have a modern 8-bit core and development environment, in many cases, such MCUs will surpass ARM Cortex-based MCUs.

System size

The general rule is that the ARM CortexM core is more suitable for larger system sizes, while the 8051 device is suitable for smaller system sizes. A medium-sized system can choose between two methods, depending on the tasks to be performed by the system. It is important to note that in most cases, peripheral combinations will play an important role. If you need 3 UARTs, 1 LCD controller, 4 clocks, and 2 ADCs, you probably won't find all of these peripherals on the 8-bit MCU.

Ease of use vs. cost and size

For a medium-sized system, work can be done using any kind of architecture. The trade-off is to choose the ease of use of the ARM core, or the cost and physical size advantages of the 8051 device. The ARM Cortex-M architecture has a unified memory mapping mode and supports full C99 in all common compilers, making this architecture very easy to write firmware. In addition, a range of libraries and third-party codes are available. Of course, the cost of this ease of use is cost. Ease of use is an important factor for high-complexity, time-to-market applications or inexperienced firmware developers.

Although 8-bit has some cost advantages over 32-bit components, the real difference is the cost level. Small 8-bit devices with 2 KB/512 B (Flash/RAM) are often found, but 32-bit devices below 8 KB/2 KB are rare. In systems that don't require a lot of resources, this range of storage capacity gives system developers a significant cost reduction solution. Therefore, applications that are extremely cost sensitive or require only small storage capacity are more likely to choose the 8051 solution.

In general, 8-bit devices also have physical size advantages. For example, some MCUs have a 32-bit QFN package of 4 mm × 4 mm, while an 8051-based 8-bit device has a QFN package as small as 2 mm × 2 mm. The difference between 8-bit and 32-bit architectures for chip-scale packaging (CSP) is small, but it adds cost and makes assembly difficult. For applications where space is strictly limited, it is often necessary to select an 8051 MCU to meet the restrictions.

General purpose code and RAM efficiency

One of the main reasons for the lower cost of the 8051 MCU is that it typically uses Flash and RAM more efficiently than the ARM Cortex-M core, which allows the system to be implemented with fewer resources. The larger the system, the smaller the impact.

But the advantages of this 8-bit storage resource are not always the case. In some cases, the ARM core will be as efficient or more efficient than the 8051 core. For example, a 32-bit operation requires only one ARM device instruction, while on an 8051 MCU, multiple 8-bit instructions are required. Obviously, this code has higher execution efficiency on the ARM architecture.

The two main drawbacks of the ARM architecture when Flash/RAM size is small are: code space efficiency and predictability of RAM usage. The first and most obvious problem is the general code space efficiency. The 8051 core uses 1-bit, 2-bit, or 3-bit instructions, while the ARM core uses 2-bit or 4-bit instructions. Normally, the 8051 instruction is smaller, but this advantage is weakened by the fact that it takes a lot of time. The ARM core can do more work than the 8051 in one instruction. The 32-bit operation is such an example. In practice, the instruction width is able to produce moderately denser code on the 8051.

Code space efficiency

In systems with decentralized access variables, the ARM architecture's load/store architecture is usually more important than the instruction width. Imagine the implementation of a signal quantity. A variable needs to be decremented (allocated) or incremented (released) at multiple different locations around the code. The ARM core must load the variables into the registers, manipulate them and store them again, which requires three instructions. On the other hand, the 8051 core can operate directly on the memory location and requires only one instruction. As each workload on the variable is increased, the consumption due to loading/storage becomes negligible. But for the case where only a little work is done each time, load/store can have a significant impact, giving the 8051 a significant efficiency advantage.

Although the amount of signals is not common in embedded software, simple counters and flag signals are widely used in control-oriented applications and play the same role. Many common MCU codes fall into this category.

Another reason is that ARM processors have more free use of stack space than the 8051 kernel. Typically, the 8051 device stores only the return address (2-bit group) on the stack for each function call, usually handling a large number of tasks through static variables assigned to the stack.

In some cases, this can cause problems because it can cause function presets to not be reentrant. However, this also means that the stack space that must be reserved is small and fully predictable, which is critical in MCUs with limited RAM capacity.

Figure 1: Different tasks require different tools. Our goal is to understand "how to better use the tools we have," including 8-bit and 32-bit MCUs. (Source:Yola)

Architectural details

Now, let's talk about the basic scenario. Assuming that there is one ARM-based and 8051-based MCU with the required peripherals, ARM devices are a better choice for larger systems or applications that require ease of use. If the primary consideration is low cost / small size, then 8051 equipment will be a better choice. Below we have a more detailed analysis of the applications that each architecture is better at, and also divide the general principles.

(1) Delay

There are large differences in interrupt and function call latency between the two architectures, and the 8051 is faster than the ARM Cortex-M core. In addition, the peripherals equipped with the Advanced Peripheral Bus (APB) also affect latency because the data must be transmitted through the APB and AMBA High Performance Bus (AHB). Finally, when using a high frequency core clock, many Cortex-M based MCUs need to allocate an APB clock, which also increases peripheral latency.

I did a simple experiment where the interrupts were triggered by I/O pins. This interrupt signals some of the pins and updates the flag based on the pin that caused the interrupt. Then I measured some parameters showing a 32-bit implementation.

To illustrate the results of this experiment, the 8051 core shows an advantage when the Interrupt Service Routine (ISR) enters and exits. However, as the Interrupt Service Routine (ISR) grows larger and execution time increases, these delays become negligible. Consistent with the existing principles, the larger the system, the smaller the advantage of the 8051. In addition, if the Interrupt Service Routine (ISR) involves a large amount of data transfer or an integer data operation greater than 8 bits, the advantage of the interrupt service routine (ISR) execution time will shift to the ARM core. For example, an ADC ISR that updates a 16-bit or 32-bit moving average with a new sample may perform faster on an ARM device.

(2) Control vs. processing

The basic function of the 8051 kernel is the control code, where access to variables is decentralized and uses a lot of control logic (if, case, etc.). The 8051 core is also very efficient at processing 8-bit data, while the ARM Cortex-M core excels at data processing and 32-bit operations. In addition, the 32-bit data channel makes it more efficient for ARM MCUs to copy large packets of data because it can move 4 bits at a time, while the 8051 can only move 1 bit at a time. Therefore, applications that stream data processing that primarily move data from one place to another (such as UART to CRC or to USB) are better suited for ARM processor-based systems.

This does not mean that applications with large amounts of data movement or 32-bit operations should not be selected for the 8051 kernel. In many cases, other considerations will outweigh the efficiency advantages of the ARM core, or that this advantage is irrelevant. Considering the use of a UART to SPI bridge, the application spends most of its time copying data between peripherals, and the ARM core does this more efficiently.

However, this is also a very small application and may be small enough to fit into a device with a storage capacity of only 2 KB. Although the 8051 core is less efficient, it still has enough processing power to handle the high data rates in the application. For ARM devices, the extra cycles available may be in an idle loop or "WFI" (waiting for an interrupt), waiting for the next available piece of information to arrive. In this case, the 8051 core still makes the most sense, because the extra CPU cycles are negligible, and the smaller Flash package saves money. If we are going to take advantage of the extra cycles to do some meaningful work, then the extra efficiency will be critical, and the higher the efficiency, the better the ARM core. This example illustrates how important it is to understand the various architectural advantages in the environment that is being addressed by the development system. Making this best decision is a simple but important step.

(3) pointer

The 8051 device does not have a uniform memory map like the ARM device, but has different instructions for access code (Flash), IDATA (internal RAM), and XDATA (external RAM). In order to generate efficient code, the metrics of the 8051 code will indicate what space it points to. However, in some cases, using generic metrics can point to any space, but this type of metric is inefficient access. For example, a function that points a pointer to a buffer and outputs the buffer data to the UART. If the indicator is an XDATA indicator, the XDATA array can be sent to the UART, but the array in code space first needs to be copied to XDATA. Generic metrics can point to both code and XDATA space, but are slower and require more code to access.

Dedicated area metrics work in most cases, but generic metrics are very flexible when writing reusable code with unknown usage. If this situation is common in applications, then the 8051 loses its efficiency advantage.

(4) Complete the work by choosing

I have noticed many times that the operation tends to choose ARM, and the control tends to choose 8051, but no application only focuses on calculation or control. How can we characterize the application in a broad sense and calculate its appropriate range? Let us consider a hypothetical application consisting of 10% 32-bit calculation, 25% control code, and 65% general code, which cannot be explicitly attributed to the 8-bit or 32-bit categories.

This application also pays more attention to code space than execution speed because it does not require all available MIPS and must be optimized for cost. The fact that cost is more important than application speed will give the 8051 core a slight advantage in the general code scenario. In addition, the 8051 core has an intermediate level of advantage in the control code. The ARM core prevails in 32-bit computing, but this is not something that many applications consider. With all of these factors in mind, this particular application is more suitable for the 8051 core.

If you make subtle changes, assuming that the application is more concerned with execution speed than cost, then the general code will not be inclined to which architecture, and the ARM core is fully dominant in the calculation code. In this case, although there are more control codes than calculations, the overall result will be fairly balanced. Obviously, there are a lot of evaluations in this process, but decomposing the application and then evaluating the technology of each component will ensure that we understand which architecture has a more significant advantage.

Power consumption

When reviewing the data sheet, it is easy to draw a conclusion about which MCU is better based on the power consumption data. While sleep mode and operating mode current performance are better on some types of MCUs, this assessment can be very misleading. The duty cycle (how much time is spent in each power mode) will always dominate the power consumption. Unless the duty cycles of the two devices are the same, the current specifications in the data sheet are almost meaningless. The core architecture that best fits the application needs usually has lower power consumption.

Suppose there is a system that adds a 16-bit ADC sample to the moving average after the device wakes up, then returns to sleep until it is woken up again when the next sample is taken. This task involves a large number of 16-bit and 32-bit calculations. ARM devices will be able to perform calculations and return to sleep faster than the 8051 device, which will result in lower system power consumption, even if the 8051 has better sleep and operating mode currents. Of course, if the task is more suitable for the 8051 device, the MCU power consumption is beneficial to the system for the same reason.

Figure 2: Although sleep mode and operating mode current performance are better on some types of MCUs, this assessment can be very misleading. (Source:NBC News)

8 or 32? I still can't decide!

If you consider all of these variables and still don't know which MCU architecture is the best choice, what happens? OK then! This shows that they are all good choices, and which architecture you use is not a critical issue. If there is no clear technical advantage, past experience and personal preferences also play a big role in your MCU architecture decisions.

In addition, you can use this opportunity to evaluate possible future projects. If most future projects are more suitable for ARM devices, then choose ARM. If the future project is more focused on reducing costs and size, then choose 8051.

What does this mean?

8-bit MCUs can still provide many features for embedded developers and are increasingly focused on the Internet of Things. When developers start designing, it's important to make sure you get the right tools from the toolbox. Although I am still happy to sell the 8051 to a customer who might be better suited to choose a 32-bit device, I can't help but imagine that if the developer takes only one hour to think, then their work will be easier and the final product will be will be better.

The real problem is that you can't just rely on one or two points in some of the demo files to get the conclusion of choosing the MCU architecture. However, once you have the right information and are willing to spend a little time applying it, it is not difficult to make the best choice.