Circuit Design

Microcontroller vs Microprocessor – Practical Differences

I’ve recently started a livestream series on the MicroType Engineering YouTube channel. It is called the “Live Lecture Series”. The theme of this series, as you can guess from the title, is to go into a specific topic in a livestream format. The first topic that I cover is “Microprocessor vs Microcontroller”. Users submit questions to an online form that I go over and answer at the end of the lecture. I am always looking for new topics to cover next, so please let me know any suggestions you may have.

 

Microcontroller vs Microprocessor – Practical Differences

The first topic covers something that is talked about a lot, but I feel sometimes too much focus is placed on the “nitty gritty” details instead of the big picture. The focus of this lecture is to zoom out, and determine not only what are the major differences between a microcontroller and a microprocessor, but more importantly, why would you use one over the other?

PDF version of the slide deck from the livestream: Microcontrollers vs Microprocessors – Live Lecture Series #1

This post is going to summarize what I spoke about during the lecture, as well as add a bit of additional information that hopefully you find helpful. But I highly recommend you watch the full YouTube stream to gain the best picture on this topic as possible.

 

What Does Google Say?

A common chart that appears when you do a Google search to compare a microcontroller vs a microprocessor

If you search Google to find the differences, you will be inundated with articles and charts like the one above. While these statements are mostly true, it really doesn’t tell the whole story. I will not recite what is in the chart, instead I encourage you to read through it yourself.

I would like to point out a few statements though: “Cannot be used in compact systems and hence inefficient”“Most of the microprocessors do not have power saving features“, and “Mainly used in personal computers”.  At best these are highly oversimplified statements. At worst, they are simply not true. Like everything in electronics design, there are always exceptions and distinctions depending on the application.

 

My Definitions and Examples

Unfortunately, there are a lot of different terms and wording in this space to describe essentially the same thing. For the sake of this article (and how I talk about these in general) I will use the following:

MCU: Microcontroller – Processor + Storage + Peripheral’s* + Power Management.

MPU: Microprocessor – Simply the Processor.

SBC: Single Board Computer – Everything needed to run a desktop OS on a single board.

*Some peripherals will still require external PHY’s/hardware (ethernet)

Some common examples of Microcontrollers and Microprocessors:

MCU’s:

  • Microchip ATMEGA328 (Arduino).
  • STMicro STM32 (Not like you can buy them).
  • Espressif ESP32.

MPU’s:

  • BCM28xx/BCM2711 (Raspberry Pi).
  • AM335x (Beagle Bone).
  • Jetson Nano (Tegra K1).
  • Computer CPU’s.

Commonly discussed advantages of an MPU are that they have more processing power and more memory. While an MCU is cheaper and easier to develop for. While these are true for the most part, they don’t tell the whole story when comparing a microprocessor vs a microcontroller.

 

Real World Example

To give a more concrete example of how to compare a microprocessor vs a microcontroller I will give a real-world example that we encountered on a job we did a proposal for.

It was an audio mixer that took in several audio channels. It would mix and apply filters to the streams, then output a single stream of audio.

We came up with two very different solutions:

MCU based approach: Uses a mixture of analog components and digital IC’s. The MCU controls the analog blocks and the IC’s.

MPU based approach: All audio is directly fed into the MPU, which handles all mixing and filtering. The audio stream is then output from the MPU.

While both of these approaches would work, there are some pretty massive differences between them.

Microprocessor Solution

  • Incredibly flexible.
  • Less external audio hardware.
  • Due to the above, it could end up being cheaper.
  • Easy to implement software using existing libraries.

Microcontroller Solution

  • Limited flexibility.
  • Requires a lot of analog and digital hardware.
  • Real-time audio, minimal latency.

Our Answer

While we ended up not actually working on this design, the solution we proposed was based around a Microcontroller. One of the client’s main criteria was that the audio needed to be passed through with minimal latency. That alone made the MPU solution tough to pull off.

 

Microprocessor vs Microcontroller Operating Systems

One of the key differences between a microprocessor and a microcontroller is the existence of an operating system. A microcontroller tends to run bare metal code or uses a Real Time Operating System (RTOS). A microprocessor will normally run a true operating system, typically some flavor of Linux.

Having Linux on an embedded system allows you to easily do in software what would be nearly impossible using a bare-metal approach.

Note: MCU’s can technically run a true operating system, but it is not commonly done, and I will not discuss that use case.

 

Why is Designing with Microprocessors Difficult?

Nearly every comparison chart discussing a Microcontroller vs a microprocessor mentions that designing with a MPU is more difficult. On the hardware side it is hard to disagree with that.

First, the majority of MPU’s use BGA packages. Often, quite fine pitch, high pin count BGA’s! An experienced electronics design shop certainly won’t have any issues with this, but it is something to keep in mind.

While not common, this is a massive 1932 pin count BGA for a NXP Microprocessor! I sympathize with the assembly house that gets hired to assemble this beast. Package sizes are a big factor when comparing microprocessors vs microcontrollers.

Also, MPU’s require external flash and RAM (some will have a bit of onboard flash, but you will still need additional for most applications.) While having more RAM/Flash is one of the common reasons to use a MPU in the first place, it increases hardware complexity. DDRx memory is also a high-speed interface that requires higher layer count PCB’s and controlled impedances.

Finally, getting Linux up and running can be an awful experience. It is nearly 100% dependent on vendor support. Common Linux distributions are Ubuntu/Debian, Yocto, and BuildRoot.

 

Dealing with Real-Time Requirements

Often, the single differentiating factor when deciding between a microcontroller and a microprocessor is the real-time response. Due to the operating system, MPU’s are inherently not real-time systems. For some applications this is not an issue, for others this is a complete deal breaker.

If you need real-time response and also to run Linux, there are a few solutions:

First, you can have an MPU as the controller for the system. It will then talk to an external MCU over SPI/UART/i2c/etc. The MCU would handle the time critical functions, while the MPU handles everything else. This is a very commonly used solution in industry.

Second, some more modern microprocessors are embedding a secondary co-processor onboard. The STM32MP1 is an example of an MPU that has one. This co-processor can be used to offload code that needs to be able to run real-time.

STM32MP1 is an example of a microprocessor that embedds a coprocessor onboard.

How Do I Choose?

To boil down this topic even further, I will discuss how we evaluate a new design. Normally, the default option is to just use a microcontroller. The majority of applications that we encounter, it makes the most sense.

If the project is:

  • Computationally heavy
    • Computer vision.
    • Machine learning.
    • Anything with a lot of math calculations.
    • Onboard graphics engine.
  • Memory intensive
    • Driving displays.
    • Large LED arrays.
  • Requiring specific interfaces
    • High-speed USB.
    • HDMI.
    • Ethernet.

Then we will consider using a microprocessor instead of a microcontroller.

From there, if we think the application requires a true operating system to give the best solution, we will lean towards using a microprocessor. If there is an interface that must be real-time, then we normally will add additional microcontrollers to the design to handle that aspect.

Conclusion

There are a lot of articles out there discussing microcontrollers vs microprocessors. Instead of taking an approach of just compare/contrasting pros/cons I used more concrete, real-world examples. While there are certainly applications that require a microcontroller or a microprocessor specifically, normally both will work. It is a matter of deciding which approach makes more sense both in BOM cost and design time.

MicroType Engineering has years of experience designing both microcontroller and microprocessor based systems. With full firmware support, MTE can assist with any and all parts of the design process. Reach out to learn how MTE can kickstart your new design today!

Kyle Hunter

Recent Posts

Securing the Future: Our Commitment to ITAR and CMMC Compliance

Securing the Future: Our Commitment to ITAR and CMMC Compliance Elevating Aerospace and Defense Technology…

10 months ago

Elevating Standards: Our Journey to AS9100 Certification

Elevating Standards: Our AS9100 Certification Journey Paving the Way for Aerospace Engineering Excellence At MicroType…

10 months ago

Enhancing Precision and Quality: MicroType Engineering’s Latest Technological Advancements

New Advanced Circuit Board Assembly Equipment Introduction At MicroType Engineering, we pride ourselves on staying…

10 months ago

The Usage and Function of TVS Diodes in Circuit Protection

The Usage and Function of TVS Diodes in Circuit Protection Introduction Hey there! Today, we're…

1 year ago

DC Bias Effect in Ceramic Capacitors

This article, The DC Bias Effect in Ceramic Capacitors, is based on the above YouTube…

2 years ago

Designing ESD Protection Circuits

I recently began a livestream series on the MicroType Engineering YouTube channel. It is called…

2 years ago