For the second installment in the 32 vs 8 bit MCU series I will get a little more technical here and talk about processing power, interrupt latency, pointer efficiency and pointer ease of use.
The two architectures that I am very familiar with are the 8051 on the 8 bit and ARM on the 32 bit. Because of this, the comparisons I make will be based on those architectures. There are many others out there like PIC with its modified Harvard architecture as well as other RISCs but my breathe of knowledge on those lacks a bit so I will focus on the 8051 and the ARM architectures.
Processing
When people think of 32 bit vs 8 bit most automatically assume that the 32 is going to out process or be much faster than the 8 bit. While generally that may be true 8 bit 8051s excel at what they were made to do, handle 8 bit data…. The code and memory size will be smaller for a program which shifts and alters 8 bit data on an 8051 than on an ARM. A smaller program uses less memory and allows the designer to use an even smaller chip lending many advantages to the 8 bit. However, when moving 16 bit data the efficiency of the 32 bit begins to differentiate itself. When it comes to 32 bit data and math the 32 bit outshines the 8 bit because it can do 32 bit addition/subtraction in 1 instruction while it takes the 8 bit 4 instructions. This makes the 32 bit better suited for a large data streaming role. However, the 32 bit core isn’t always better at this data pass through especially in the simple cases. For example if it is a simple SPI-UART bridge then a 32 bit MCU sits in idle for long periods of time and on top of that the entire application is small at < 8kb flash. This makes the 8 bit the right choice in this simple example and many USB – SPI/I2C/etc devices which simply pass through peripherals are repurposed 8 bit MCUs like the Cp210x family.
To illustrate the point of 8, 16 and 32 bit data efficiency I compiled the function below on a 32 bit ARM core and an 8 bit 8051 MCU with varying sizes of uint8_t, uint16_t and uint32_t.
uint32_t funcB(uint32_t testA, uint32_t testB){
return (testA * testB)/(testA - testB)
}
| data type | 32bit(-o3) | 8bit |
| uint8_t | 20 | 13 | bytes
| uint16_t | 20 | 20 | bytes
| uint32_t | 16 | 52 | bytes
As the data size/type used increased the 8051 begins to require more and more code size to deal with it and eventually surpassing the size of the ARM function. The 16-bit case is dead even for this example however the 32 bit used less instructions and therefore has the edge here. Also, it’s important to know that this comparison is only valid when compiling the ARM code with optimization. Un-optimized code is several times larger. This can also be dependent on the compiler and the level of coding being done.
Interrupt Speed
The latency involved in interrupts and function calls are vastly different between the two. The 8 bit is going to be faster at performing interrupts as well as communicating with 8 bit peripherals. The 8051 core has an advantage in ISR service times and latency. But this only comes into play on entry and exit so as the ISR gets larger the benefit will die out. The ARM interrupt controller will automatically save around 4 registers depending on the type of core. If the interrupt service routine(ISR) doesn’t need all four or five of these registers then those cycles are wasted. So for the smaller ISRs the 8051 will be faster to execute. Again the theme is, the bigger the system the less edge the 8 bit will have. Also you must consider what the ISR is doing. If it is performing 32 bit math or something to that degree it will take the 8 bit longer and the faster ISR entry/exit will be negated.
Pointers
When using pointers with an 8051 device, it is more efficient to specify which data segment the pointer is pointing to, for example XDATA. Generic pointers exist but are slower and use more memory. If you have an application which utilizes pointers especially in data transfer then the 8051 may start to lag behind the ARM core in terms of efficiency. This is because the ARM has a unified memory and a pointer on the ARM core can point to anywhere and transfer without the need to copy the data to another segment. Also using memory specified pointers on the 8051 can be tough to understand and can be taxing on the developer thus lending the advantage to ARM if your application heavily utilizes pointers. It is all a game of tradeoffs and knowing what you application needs can help you better weigh the options.
Top Comments