Skip navigation

Embedded

3 Posts authored by: txbeech

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.

When beginning a project that you know will contain an MCU there are so many options that it may be overwhelming.  One of the biggest questions is what size MCU should you use?  I will release a series of articles that will shed some light on this issue faced by so many designers and developers.


Uncovering the differences and architectures

The 2 ends of the scale for bit size of microcontrollers are 8 bit and 32 bit. Bit size in this case means that the MCU processes an 8 or 32 bit data word at a time and also dictates the register, address and bus size.  Both have advantages and disadvantages and throughout the series I will talk about both. The most common architectures within these categories is 8051 architecture for the 8 bit and ARM architecture for the 32 bit.  There seems to be a popular belief that 8 bit MCUs are on their way out. With the release of new products such as the EFM8 MCUs, I have heard many people question using an 8 bit in their design.  Well, not only will this series distinguish the best cases for each MCU but also shed some light on why the 8 bit with its 8051 architecture still thrives in many applications.

 

First, let’s discuss some of the more general and obvious differences, namely size, cost, and ease of use.  Before we begin there are fine lines that can be drawn between which is better for a certain application.  If a systems demands >64 KB of RAM then the choice to use a 32 bit MCU is an easy one to make.  If the system is ultra-cost sensitive then using an 8 bit MCU is the correct decision. However for the application where this clear line can’t be drawn there are deeper things that must be considered.

 

Ease of use and cost

The picture is very exaggerated but it points out the general truth that the ARM core, which most 32 bit devices use, is easier to use compared with the 8051 core, which the majority of 8 bit MCU use. The ARM core 32 bit MCUs utilize familiar compilers, have a long list of available libraries and the perhaps the most important of all, have unified memory, make coding on the ARM an easier task than on an 8051. However, you pay for this as the price for ARM based devices are normally higher than the 8051. The most aggressively priced 8 bit 8051s out there hit ridiculous lows and can be bought for cents. But, with ease of use comes a quicker time to market.  For some products time to market is a deciding factor in its success therefore for these end products paying a bit more for the 32 bit can be well worth it.

 

Size

An advantage of the 8 bit devices is that they are generally smaller devices. This becomes an enormous edge over the 32 bit if the final product is space constrained. If you were designing a wearable like a watch, an 8 bit 8051 could allow the device to be smaller and have the same functionality compared to a wearable with a 32 bit. To give the edge even more to the 8 bit, some manufacturers like Silicon Labs use chip scale packages (CSP) with their 8 bit devices which decreases the size significantly. Their CSP 8051 is 1.66x1.78 mm2 which is one of the smallest on the market. This compared to their smallest 32 bit, the Tiny Gecko which is 4x4 mm2 is 4 times the size!


 

A theme you will see multiple times in this series is that knowing your application and final design is perhaps the most important thing when choosing the MCU for you!

Add USB interface in 4 easy steps with CP210x family

 

Sometimes we forget to add USB to our designs, or we need USB to access the design more efficiently from our development platform.

Don’t worry. It’s easy to drop-in USB connectivity to any design—old or new—with the fixed-function CP210x MCU family from Silicon Labs.


Step 1 – Connect your CP210x EVK to your Windows PC.


Step 2 – Launch Windows driver installer and walk through the wizard to set the driver name, address and other configurations.

 

 

Step 3 – Install the driver on the target device and reboot Windows to recognize it. No additional code writing necessary.

 


Step 4 – Once the drivers are in place and the device is recognized, open a com port and, USB-am! start sending and receiving USB data.


 

This is the set up. There are 2 wires that go from my UART ports on the device to the TX and RX ports of the Silicon Labs CP2102 device.

The USB then goes to the host computer where the terminal is viewed.

 

 

To learn more or to get involved please follow the links below!

Also feel free to message me with questions or to get more information.

 

Learn more at the Silicon Labs CP210x Page

CP210x devices

Download AN721 for more detailed instructions

AN721, adding USB walkthrough

Buy the CP210x EVK to get started

Evaluation kit

Customize the USB driver

Custom driver info

Filter Blog

By date: By tag: