Tag Archives: RTOS

The Linux Foundation is building an RTOS for the Internet of Things

The Zephyr Project will offer a modular, connected operating system to support IoT devices.

The Linux Foundation recently introduced the Zephyr Projectan open source collaborative effort that hopes to build a real-time operating system (RTOS) for the Internet of Things. Announced just days before Embedded World 2016, the project is looking to bring vendors and developers together under a single OS which could make the development of connected devices a simpler, less expensive process.


Industrial and consumer IoT devices require software that is scalable, secure and enables seamless connectivity. Developers also need the ability to innovate on top of a highly modular platform that easily integrates with embedded devices regardless of architecture.

While Linux has proven to be a wildly successful operating system for embedded development, some smart gadgets require an RTOS that addresses the very smallest memory footprints. This complements real-time Linux, which excels at data acquisition systems, manufacturing plants and other time-sensitive instruments and machines that provide the critical infrastructure for some of the world’s most complex computing systems.

If all goes to plan, the Zephyr Project has the potential to become a significant step in creating an established ecosystem in which vendors subscribe to the same basic communication protocols and security settings.

With modularity and security in mind, the Zephyr Project provides the freedom to use the RTOS as is or to tailor a solution. The initiative’s focus on security includes plans for a dedicated working group and a delegated security maintainer. Broad communications and networking support is also addressed and will initially include Bluetooth, BLE and IEEE 802.15.4, with more to follow.

The Zephyr Project aims to incorporate input from the open source and embedded developer communities and to encourage collaboration on the RTOS. Additionally, this project will include powerful developer tools to help advance the Zephyr RTOS as a best-in-breed embedded technology for IoT. To start, the following platforms will initially be supported:

  • Arduino Due (Atmel | SMART SAM3X8E ARM Cortex-M3 MCU)
  • Arduino 101
  • Intel Galileo Gen 2
  • NXP FRDM-K64F Freedom board (ARM Cortex-M4 MCU)

Intrigued? Head over to the Zephyr Project’s official site to learn more.

“It’s not a feature, it’s a bug”

Embedded systems no longer need to be a ‘black box’ that leaves engineers guessing what may be happening, Percepio AB CEO Dr. Johan Kraft explains his latest guest blog post.

Anyone involved with software development will have most likely heard (and perhaps even said) the phrase “it’s not a bug, it’s a feature” at some point, and while its origins remain a mystery, its sentiment is clear — it’s a bug that we haven’t seen before.


Intermittent ‘features’ in an embedded system can originate in either the software or hardware domain, often only evident when certain conditions collide in both. In the hardware domains, the timings involved may be parts of a nano second and where the logic is accessible, such as an address line or data bus — there exist instruments that can operate at high sample rates, allowing engineers to visualize and verify such ‘glitches.’ In the software domain, this becomes much more challenging.

Sequential Processing

While parallel processing is being rapidly adopted across all applications, single-processor systems remain common in embedded systems, thanks partly to the continued increases in the performance of microcontroller cores. Embedded MCUs are now capable of executing a range of increasingly sophisticated Real-Time Operating Systems (RTOS), often including the ability to run various communication protocols for both wired and wireless interfaces.

Whether in a single- or multi-processing system, combining these tasks with the embedded system’s main application, written by the engineering team, can make embedded software builds large, complex and difficult to fault-find, particularly when visibility into the code’s execution is limited. It can also lead to the dreaded intermittent fault which, if part of the system’s operation is ‘hidden’, can make solving them even more challenging.

A typical example may be an unexplained delay in a scheduled task. Of course, an RTOS is intended to guarantee specific tasks happen at specific times but this can be dependent on the task’s priority and what else may be happening at any time. In one real-world example, where a sensor needed to be sampled every 5ms, it was found that occasionally the delay between samples reached 6.5ms, with no simple explanation as to the cause. In another example, a customer reported that their system exhibited random resets; the suspected cause was that the watchdog was expiring before it was serviced, but how could this be checked? In yet another example, a system running a TCP/IP stack showed slower response times to network requests after minor changes in the code, for no obvious reason.

These are typical examples of how embedded systems running complex software can behave in unforeseen ways, leaving engineering teams speculating on the causes and attempting to solve the problems with only empirical results from which to assess their efforts. In the case of intermittent faults or system performance fluctuations, this is clearly an inefficient and unreliable development method.

Trace Tools

The use of logging software embedded in a build in order to record certain actions isn’t new, of course, and it can offer a significantly improved level of visibility into a system. However, while the data generated by such trace software is undoubtedly valuable, exploiting that value isn’t always simple.

Analyzing trace data and visually rendering it in various ways is the key function of Percepio’s Tracealyzer tools. It offers visualization at many levels, ranging from an event list to high-level dependency graphs and advanced statistics.

Over 20 different graphical views are provided, showing different aspects of the software’s execution that are unavailable with debuggers alone, and as such it complements existing software debug tools in a way that is becoming essential in today’s complex embedded systems. It supports an increasing range of target operating systems.

Figure 1(a): It appears that the ControlTask may be disabling interrupts.

Figure 1(a): It appears that the ControlTask may be disabling interrupts.

The main view in Tracealyzer, as shown in Figure 1(a) and 1(b), is a vertical timeline visualizing the execution of tasks/threads and interrupts. Other logged events, such as system calls, are displayed as annotations in this timeline, using horizontal colour-coded text labels. Several other timeline views are provided using horizontal orientation and all horizontal views can be combined on a common horizontal timeline. While much important data is created by the operating system’s kernel, developers can also extend the tracing with User Events, which allow any event or data in a user’s application to be logged. They are logged similar to calling the classic ‘printf’ C library function but are much faster as the actual formatting is handled in the host-side application, and can therefore also be used in time-critical code such as interrupt handlers. And, of course, they can also be correlated with other kernel-based events.

Figure 1(b): By changing the way ControlTask protects a critical section, SamplerTask is able to run as intended.

Figure 1(b): By changing the way ControlTask protects a critical section, SamplerTask is able to run as intended.

Tracealyzer understands the general meaning of many kernel calls, for instance locking a Mutex or writing to a message queue. This allows Tracealyzer to perform deep analysis to connect related events and visualize dependencies, e.g., which tasks communicate (see the communication flow graph, shown in Figure 3). This allows developers to quickly understand what’s really going on inside their system.


Returning to the first example, where a scheduled task was being inexplicably delayed intermittently, Tracealyzer was used to graphically show the task in question, time-correlated with other tasks. By invoking an exploded view of the task of interest, it was found that a lower priority task was incorrectly blocking the primary task from executing. It was discovered that the second task was disabling interrupts to protect a critical section unrelated to the primary task, which blocked the operating system scheduling. After changing the second task to using a Mutex instead, the primary task was able to meet its timing requirements. Figure 1(a) shows the SamplerTask being delayed by the (lower priority) ControlTask before the bug fix; Figure 1(b) confirms that SamplerTask is now occurring every 5ms as intended.

In the second example, User Events were used to not only record when the Watchdog was reset or when it expired, but also to log the remaining Watchdog timer value, thereby showing the time left in the Watchdog timer when it is reset. By inspecting the logged system calls it was found that the task in question did not only reset the Watchdog timer; it also posted a message to another task using a (fixed-size) message queue. The Watchdog resets seemed to occur while the Watchdog task was blocked by this message posting. Once realised, the question then became ‘why’. By visually exploring the operations on this message queue using the Kernel Object History view, it became clear that the message queue sometimes becomes full, as suspected. By correlating a view of the CPU load against how the Watchdog timer margin varied over time, as shown in Figure 2, it was found that Fixed Priority Scheduling was allowing a medium-priority task (ServerTask) to use so much CPU time that the message queue wasn’t always being read. Instead, it became full, leading to a Watchdog reset. The solution was in this case to modify the task priorities.

Figure 2: The CPU Load graph, correlated to the Watchdog Timer User Event, gives valuable insights.

Figure 2: The CPU Load graph, correlated to the Watchdog Timer User Event, gives valuable insights.

In the last example, where a software modification caused increased response time to network requests, using the Communications Flow view (Figure 3) it was found that one particular task — Logger — was receiving frequent but single messages with diagnostics data to be written to a device file system, each causing a context switch. By modifying the task priorities, the messages were instead buffered until the network request had finished and thereafter handled in a batch. This way, the number of context-switches during the handling of network requests was drastically reduced, thereby improving overall system responsiveness.

Figure 3: The Communication Flow reveals 5 tasks sending messages to Logger.

Figure 3: The Communication Flow reveals 5 tasks sending messages to Logger.


The complexity of embedded software is increasing rapidly, creating demand for improved development tools. While runtime data can be recorded in various ways, understanding its meaning isn’t a simple process, but through the use of innovative data visualization tools such as Tracealyzer it can be.

Many companies have already benefited from the many ways of using the tool to really discover what’s going on in the runtime system. Some Tracealyzer users even include it in production code, allowing them to gather invaluable data about real systems running in the field.

Embedded systems need no longer be a ‘black box,’ leaving engineers to suppose what may be happening; powerful visualization tools now turn that black box into an open box.

3 design hooks of Atmel MCUs for connected cars

The MPU and MCU worlds are constantly converging and colliding, and the difference between them is not a mere on-off switch — it’s more of a sliding bar. 

In February 2015, BMW reported that it patched the security flaw which could allow hackers to remotely unlock the doors of more than 2 million BMW, Mini and Rolls-Royce vehicles. Earlier, researchers at ADAC, a German motorist association, had demonstrated how they could intercept communications with BMW’s ConnectedDrive telematics service and unlock the doors.


BMW uses SIM card installed in the car to connect to a smartphone app over the Internet. Here, the ADAC researchers created a fake mobile network and tricked nearby cars into taking commands by reverse engineering the BMW’s telematics software.

The BMW hacking episode was a rude awakening for the connected car movement. The fact that prominent features like advanced driver assistance systems (ADAS) are all about safety and security is also a testament is that secure connectivity will be a prime consideration for the Internet of Cars.

Built-in Security

Atmel is confident that it can establish secure connections for the vehicles by merging its security expertise with performance and low-power gains of ARM Cortex-M7 microcontrollers. The San Jose, California-based chip supplier claims to have launched the industry’s first auto-qualified M7-based MCUs with Ethernet AVB and media LB peripherals. In addition, this high-end MCU series for in-vehicle infotainment offers the CAN 2.0 and CAN flexible data rate controller for higher bandwidth requirements.

Nicolas Schieli, Automotive MCU Marketing Director at Atmel, acknowledges that security is something new in the automotive environment that needs to be tackled as cars become more connected. “Anything can connect to the controller area network (CAN) data links.”

Schieli notes that the Cotex-M7 has embedded enhanced security features within its architecture and scalability. On top of that, Atmel is using its years of expertise in Trusted Platform Modules and crypto memories to securely connect cars to the Internet, not to mention the on-chip SHA and AES crypto engines in SAM E70/V70/V71 microcontrollers for encryption of data streams. “These built-in security features accelerate authentication of both firmware and applications.”


Schieli notes that the Cotex-M7 has embedded enhanced security features within its architecture and scalability. On top of that, Atmel is using its years of expertise in Trusted Platform Modules and crypto memories to securely connect cars to the Internet, not to mention the on-chip SHA and AES crypto engines in SAM E70/V70/V71 microcontrollers for encryption of data streams. “These built-in security features accelerate authentication of both firmware and applications.”

He explained how the access to the Flash, SRAM, core registers and internal peripherals is blocked to enable security. It’s done either through the SW-DP/JTAG-DP interface or the Fast Flash Programming Interface. The automotive-qualified SAM V70 and V71 microcontrollers support Ethernet AVB and Media LB standards, and they are targeted for in-vehicle infotainment connectivity, audio amplifiers, telematics and head control units companion devices.

Software Support

The second major advantage that Atmel boasts in the connected car environment is software expertise and an ecosystem to support infotainment applications. For instance, a complete automotive Ethernet Audio Video Bridging (AVB) stack is being ported to the SAM V71 microcontrollers.

Software support is a key leverage in highly fragmented markets like automotive electronics. Atmel’s software package encompasses peripheral drivers, open-source middleware and real-time operating system (RTOS) features. The middleware features include USB class drivers, Ethernet stacks, storage file systems and JPEG encoder and decoder.

Next, the company offers support for several RTOS platforms like RTX, embOS, Thread-X, FreeRTOS and NuttX. Atmel also facilitates the software porting of any proprietary or commercial RTOS and middleware. Moreover, the MCU supplier from San Jose features support for specific automotive software such as AUTOSAR and Ethernet AVB stacks.

Atmel supports IDEs such as IAR or ARM MDK and Atmel Studio and it provides a full-featured board that covers all MCU series, including E70, V70 and V71 devices. And, a single board can cover all Atmel microcontrollers. Moreover, the MCU supplier provides Board Support Package for Xplained evaluation kit and easy porting to customer boards through board definition file (board.h).

Beyond that, Atmel is packing more functionality and software features into its M7 microcontrollers. Take SAM V71 devices, for example, which have three software-selectable low-power modes: sleep, wait and backup. In sleep mode, the processor is stopped while all other functions can be kept running. While in wait mode, all clocks and functions are stopped but some peripherals can be configured to wake up the system based on predefined conditions. In backup mode, RTT, RTC and wake-up logic are running. Furthermore, the microcontroller can meet the most stringent key-off requirements while retaining 1Kbyte of SRAM and wake-up on CAN.

Transition from MPU to MCU

Cortex-M7 is pushing the microcontroller performance in the realm of microprocessors. MPUs, which boast memory management unit and can run operating systems like Linux, eventually lead to higher memory costs. “Automakers and systems integrators are increasingly challenged in getting performance point breakthrough because they are running out of Flash capacity,” explained Schieli.

On the other hand, automotive OEMs are trying to squeeze costs in order to bring the connected car riches to non-luxury vehicles, and here M7 microcontrollers can help bring down costs and improve the simplification of car connectivity.

The M7 microcontrollers enable automotive embedded systems without the requirement of a Linux head and can target applications with high performance while running RTOS or bare metal implementation. In other words, M7 opens up avenues for automotive OEMs if they want to make a transition from MPU to MCU for cost benefits.

However, the MPU and MCU worlds are constantly converging and colliding, and the difference between them is not a mere on-off switch. It’s more of a sliding bar. Atmel, having worked on both sides of the fence, can help hardware developers to manage that sliding bar well. “Atmel is using M7 architecture to help bridge the gap between microprocessors and high-end MCUs,” Schieli concludes.

Majeed Ahmad is the author of books Smartphone: Mobile Revolution at the Crossroads of Communications, Computing and Consumer Electronics and The Next Web of 50 Billion Devices: Mobile Internet’s Past, Present and Future.

Percepio Tracealyzer: Periodic task not running as expected

Learn how a developer used Tracealyzer to solve an unexpected timing issue. 

With time-to-market pressures constantly on the rise, advanced visualization support is a necessity nowadays. For those who may be unfamiliar with Percepio, the company has sought out to accelerate embedded software development through world-leading RTOS tracing tools. Tracealyzer provides Makers, engineers and developers alike a new level of insight into the run-time world, allowing for improved designs, faster troubleshooting and higher performance. What has made it such a popular choice among the community is that it works with a wide-range of operating systems and is available for Linux and FreeRTOS, among several others.


When developing advanced multi-threaded software systems, a traditional debugger is often insufficient for understanding the behavior of the integrated system, especially regarding timing issues. Tracealyzer is able to visualize the run-time behavior through more than 20 innovative views that complement the debugger perspective. These views are interconnected in intuitive ways which makes the visualization system powerful and easy to navigate. Beyond that, it seamlessly integrates with Atmel Studio 6.2, providing optimized insight into the run-time of embedded software with advanced trace visualization.

Over the next couple of weeks, we will be sharing step-by-step tutorials from the Percepio team, collected directly from actual user experiences with the Tracealyzer tools.

In the first case, a user had an issue with a periodic task not running as expected, here called SamplerTask. This was the highest priority task in the system and should execute every 5 ms to read a sensor. However, they found significant timing variations in the data sampling. Why, you ask?

With Tracealyzer, they soon found the Actor Instance Graph, revealing run-time metrics of individual task executions, as shown below. There are several such graphs, one for each supported metric, where each data point represents one execution of the task. The X-axis notes the start time of the instance and the Y-axis shows the specific metric, which in this case is “Periodicity – from Ready” (i.e., the time in between task activations).


As you can see in the above screenshot, the SamplerTask is not executing strictly every 5 ms as intended. While it usually does, there are cases with unusually long intervals in between activations — over 6.5 ms.

So, what exactly is going on during these instances? If we add a horizontal trace view, synchronized and with the other tasks enabled, we see that the ControlTask (dark green) is running in this interval. Is this causing the problem? But SamplerTask (orange) has higher priority, so it should preempt ControlTask.


Perhaps the ControlTask is disabling interrupts for a few milliseconds and thereby also the kernel tick interrupt? We can find out in the main trace view, which allows us to inspect the tick events. Let’s have a look…

By double-clicking on the data point, the corresponding interval is shown in the main trace view. This view provides a vertical timeline, with events presented as horizontal text labels. The OS tick events should occur every 1 ms in this system, but there is a gap of about 2.5 ms, starting at 2.018.000.


That being said, it seems plausible that ControlTask is disabling interrupts, probably to protect access to a shared resource like a file system. But SamplerTask is not using that resource, so is it really necessary to block it by disabling interrupts? Let’s check how the other task, ServerTask, is handling this.


In the lower right corner, you find the View Filter, where we have now enabled “Mutex” type kernel calls, and also User Events – generated by logging calls added to the application code. Here, we can see that the ServerTask (bright green) is using a Mutex for protecting access to the file system, but ControlTask makes no such calls, even though the logging indicates a similar operation in both tasks (“Updating File”). This can probably be solved by changing ControlTask to use the mutex (FS_Mutex) instead of disabling interrupts.

Let’s see what happens if we change this. In the screenshot below, it’s apparent that SamplerTask is now running periodically every 5 ms, as intended.


When looking at the detailed trace (below), we verify that ControlTask is now using FS_Mutex and the OS ticks are running periodically, even in the critical section, and lets SamplerTask preempt as intended.


Stay tuned for the next use case – the mysterious random watchdog reset.

Atmel | SMART MCUs are here!

Atmel Corporation, a global leader in microcontroller (MCU) and touch solutions, today announced the company has launched Atmel® | SMART™, the new brand of ARM®-based microcontrollers and has expanded its SMART portfolio with new SmartConnect SAM W23 modules, enabling Wi-Fi connectivity and the best of high performance and low power technology for Internet of Things (IoT) applications.

Atmel® | SMART™ ARM-based microcontrollers deliver the platform for intelligent, connected devices in the era of IoT, wireless and energy efficiency. These solutions include embedded processing and connectivity—as well as software and tools, designed to make development faster and more cost-effective to bring the best-in-class products to market. Atmel® | SMART™ MCUs combine powerful 32-bit ARM cores with industry-leading low-power technology and intelligent peripherals.

“Through the convergence of Atmel’s ultra-low power MCUs and Wi-Fi solutions, Atmel continues to benefit through the vast range of products developed such as SmartConnect,” said Reza Kazerounian, senior vice president and general manager, microcontroller business unit at Atmel. “Encompassing our unique combination of high performance, power efficiency and design flexibility, Atmel® | SMART™ is a true testament to Atmel’s commitment to innovation and is poised to deliver breakthrough technologies and key ingredients powering The Internet of Things.”

As part of the Atmel® | SMART™ product offering, the SAM W23 module offers the ideal solution for designers seeking to integrate Wi-Fi connectivity even with limited experience with IEEE802.11, RTOS, IP Stack or RF. These modules are based on Atmel’s industry leading ultra-low-power Wi-Fi SoC (System on Chip) combined with Atmel’s ARM® Cortex®M0+ based microcontroller technology. This turnkey system provides an integrated software solution with application and security protocols such as TLS, integrated network services (TCP/IP stack) and a standard Real Time Operating System (RTOS) which are all available through a simple serial host interface (SPI, UART) within Atmel Studio 6’s integrated development platform (IDP).

“With the increasing demand for extended battery life and greater connectivity, the SAM W23 eliminates the complexities associated with using traditional Wi-Fi solutions with an ease of use ideal for a vast range of industrial and consumer markets,” said Kaivan Karimi, vice president and general manager of the wireless microcontroller business unit at Atmel. “Whether you are a OEM, a developer or a maker, the SAM W23 paired with our broad portfolio of MCUs enables you to accelerate your development of IoT products, providing increased seamless connectivity with a whole new world of device use cases.”

Evaluation Kit

To help accelerate a designer’s development, the SAM W23, mounted on an XPRO wing, and compatible with any existing Atmel Xplained PRO evaluation board, is available now. The SmartConnect library is a turnkey Software Framework available in Atmel Studio that removes the need to understand the Wi-Fi stack, allowing designers to focus on adding functions.


The SAM W23 is available both as a fully certified module, as well as a reference design kit for OEMS to build modules based on the SAM W23 chipset. Developers can use the SAM W23 platform as a standalone system or as an add-on solution to enable Wi-Fi connectivity in an existing design.

Atmel Studio 6.2 goes live in Nuremberg (EW 2014)

Atmel has rolled out Studio 6.2 for its ARM-based and AVR-powered MCUs. The latest version of the popular integrated development environment (IDE) boasts a number of new features, including support for the Atmel-ICE probe, which provides advanced programming and debug connectivity, as well as the ability to capture data trace information.

As Steve Pancoast, Atmel’s VP of Software & Tools notes, Atmel-ICE allows engineers and designers to more easily develop and debug applications in a single, integrated environment.


Atmel’s Studio 6.2 also seamlessly integrates Percepio Trace, providing optimized insight into the run-time of embedded software with advanced trace visualization.

More specifically, Percepio Trace for Atmel Studio features control-flow trace (tasks and interrupts), custom data plots, application debug output, statistical code profiling, support for viewing MCU event counters and real-time operating system (RTOS) awareness. In addition to Percepio Trace, Atmel Studio 6.2 adds data breakpoints and live watch.

“With time-to-market pressures constantly increasing in today’s competitive market, advanced visualization support is a necessity,” explained Dr. Johan Kraft, CEO, Percepio AB.

“The integration of our Percepio Trace allows Atmel MCU designers to produce higher quality software in a shorter time and at a lower price point.”

Atmel’s Steve Pancoast expressed similar sentiments.

“With the increased complexity in today’s embedded designs, developers are differentiating their products through software and advanced peripherals. With Atmel’s latest Studio 6.2 version, we combine all the tools in a seamless, simple-to-use platform,” he said.

“As a leading provider of MCUs, we are committed to bringing an extensive and sophisticated eco-system to our software developers to ensure they have all the right tools to differentiate their products in this highly competitive market.”


Studio 6.2 can be downloaded here, free of charge.

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.


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.