An MCU or MPU, that is the question: Part 2

In part one of this series, Bits & Pieces discussed a number of differences between an MCU and MPU, including memory and power consumption methodology. In part two of this installment, we take a closer look at processing power, UI, TFT controllers, connectivity and real-time/deterministic behavior.

thinkbeyondcore

As previously discussed on Bits & Pieces, an ARM Cortex-M4-based microcontroller such as Atmel’s SAM4 MCU is rated at 150 DMIPS (Dhrystone MIPS ) while an ARM Cortex-A5 application processor (MPU) such as Atmel’s SAMA5D3 is capable of delivering up to 850 DMIPS.

“One way of estimating the DMIPS required is by looking at the parts of the application that may be performance hungry. Running a full operating system (OS), such as Linux, Android or Windows CE would demand at least 300 – 400 DMIPS,” Frédéric Gaillard, product marketing manager and Andreas Eieland, senior product marketing manager, told Bits & Pieces.

“For many applications, a straightforward RTOS might suffice and an allowance of 50 DMIPS would be more than adequate. Using an RTOS also has the benefit that it requires little memory space; a kernel of just a few kB being typical. Unfortunately, a full OS demands a memory management unit (MMU) in order to run; this in turn specifies the type of processor core to be used and require more processor capability.”

Gaillard and Eieland also noted that DMIPS allowance needs to be reserved on top of any OS and other communication and control tasks for running applications that are more number-crunching intensive enough. Meaning, the more numeric-based the application, the more likely a MPU is required.

The user interface (UI), say Gaillard and Eieland, is also a serious consideration for engineers, whether the intended application is targeted at consumer electronics or industrial automation. Indeed, consumers have grown accustomed to colorful and intuitive graphical UIs, with industrial applications increasingly using this method of operator interaction (although the operating environment can limit how much this is warranted).

“For the UI there are a number of factors. Firstly, is a processing overhead required? For a UI library such as Qt, which is widely used on top of Linux, an overhead of 80 – 100 DMIPS might suffice,” the two explained.”The second factor is to do with the complexity of the UI. The more you have animations, effects, multimedia content, the more changes are applied to the image to be displayed, the more processing power and memory you need.”

Of course, requirements do scale up with the resolution, which is why UI-centric applications are probably best suited for an MPU. On the other hand, a simpler UI with pseudo-static images on a lower resolution screen can easily be addressed by an MCU. Indeed, MPUs typically include an embedded TFT LCD controller, while very few MCUs are packaged with this feature. Meaning, the TFT LCD controller, along with a number of external driver components, have to be added externally to MCUs.

“Yes, some Flash MCUs are now hitting the market with TFT LCD controllers embedded, although there still must be enough embedded SRAM memory available to drive the display. For example, the QVGA 320 x 240 16-colour format requires 150 kB of SRAM to feed and refresh the display,” Gaillard and Eieland noted.

“This is a fairly high amount of SRAM to dedicate; so extra memory might be required – further adding to the BOM and bridging the gap with the MPU solution. More complex and advanced graphical UIs, especially using screens larger than 4.3-inches, would stipulate an MPU. If MPUs are seen to dominate when it comes to run a UI on a color TFT screen then MCU are the kings for segment or dot matrix LCD control and other screens with serial interfaces.”

In short, the decisions involved in selecting either an MCU  or MPU-based approach are varied, with engineers carefully weighing a number of factors, including performance, capability and BOM (budget).

Broadly speaking, MCUs  tend to be used in cost-optimized solutions where a tight control of BOM and power saving is essential. MPUs are typically chose for functionally, as well as rich and high performance applications. In contrast, MCUs tend to be deployed in ultra low power applications such as remote controls, consumer electronics and smart meters where the design emphasis puts longevity of battery life and none or little UI interaction. And lastly, MCUs are also used where a highly deterministic behavior is needed, while MPUs are ideal for OS-based industrial and consumer applications that might be compute intensive, requiring multiple high-speed connectivity or a rich UI.

“Selecting a vendor offering highly compatible MCU  and MPU products where you can easily migrate up and down and maximize software reuse provides the best return on investment over time,” Gaillard and Eieland added.

1 thought on “An MCU or MPU, that is the question: Part 2

  1. Anders Borg

    I’d argue that in many cases the UI used with an MCU is not display-based (which is very CPU-intensive to handle), but rather physical knob and button based, that’s easily handled by an MCU, provided enough analog and digital inputs. And many uses of MCUs have no UI at all (sensor nodes etc).

    But other parameters also come into play here:
    Need for a lot of data storage?
    Need for a network connection?
    Need for complex number-crunching?
    Fixed vs battery-powered?
    How long on one battery?
    What kind of UI?
    Space requirements?
    Stand-alone or integrated?
    BOM cost requirements?
    etc etc

    Things that should show up during the requirement specification phase.

    Software requirements affect hardware requirements affect cost, size, power requirements etc, so think the complete set of requirements from day one.

    Like

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s