uClinux on Cortex-M3/M4 MCU: The Costs, Performance and Power Consumption

I previously wrote about different options available to run Linux on Cortex M3 & M4 Microcontrollers, and more recently Vladimir Khusainov, co-founder and Director of Engineering at Emcraft Systems,wrote a longish article entitled “Practical Advice on Running uClinux on Cortex-M3/M4” on electronicdesign.com, where he explains how SoM are usually selected, the costs of running uClinux on Cortex M3/M4 MCUs such as Freescale K70 or STmicroelectronics STM32F2/F4, as well as performance and power consumption considerations.

First, Vladimir addresses one comment that says there’s basically no use for uClinux on Cortex M3/M4 MCU, since external memory is needed and an ARM7/ARM9 modules (with MMU) can be purchased for almost the same price.  There are 2 counter arguments to this point of view:

• In practice, customers usually select an hardware platform first, then think what OS can be used on the platform. For example, if a company decided to use an hardware based on Cortex M3, they would just consider whether running uClinux or another OS, rather that thinking about upgrading the hardware to use ARM9 or another processor with MMU.
• Many customers are using Cortex M3/4, as an upgrade products based on 8-bit/16-bit upgrades, and they do not feel comfortable to jump to ARM9 processor, yet still need lots of new features in their upgraded designs (e.g. SD card, networking…) which are already supported in uCLinux.

In the next two sections of the electronicdesign article, Vladimir writes about the difference between big Linux and uClinux and the robustness of uClinux, but I’ll skip this part in this post as it is not specific to Cortex M3/M4 MCUs.

When evaluating uClinux on Cortex M3/M4, companies have three main concerns:

• The costs (Bill of Materials)
• Performance (Will Cortex M3/M4 MCU be faster enough with such an OS?)
• Power consumption

Added BOM costs for uCLinux on Cortex M3/M4

U-Boot firmware can run from the on-chip eNVM/eSRAM (no added costs here), but the uCLinux image will have to be stored in a non-volatile storage device (NOR Flash, NAND Flash, SPI Flash, SD card…) and loaded into external RAM. This means you need two extra components to run uCLinux, although the non-volatile memory could be optional if your design allows you to boot from the network (e.g. TFTP).

4MB RAM can run uClinux, but emCraft recommends 16MB RAM to allow for extra requirements.

Now that we know what we need, how much does it actually costs? And the answer is: “it depends…” :).

You can use one of 3 types of RAM depending on the MCU memory interface(s):

• For MCUs that only support SRAM devices, you could select 16 MB Micron PSRAM device (~$4.5 – 1k order), which appears to be the largest SRAM you can get.

• For MCUs that support SDRAM devices, ~$1.5 will get you a a 32 MB SDRAM device. Other SDRAM devices (32 MB) with lower power consumption are also available but costs up to ~$6.
• For MCUs that support DDR memory, a 64 MB DDR device can be purchased for ~$3.5, and this is the best choice for power consumption.

Now let’s consider the price of non-volatile storage. The size of a bootable uClinux image with features you would expect in a 16MB RAM system should be 2 to 3 MB, and Emcraft used the following flash devices in some of their customer designs:.

• 16 MB NOR Flash ~$3
• 128 MB NAND Flash ~$2
• 16 MB SPI Flash ~$2.25

So if you specifically need to add both external RAM and non-volatile storage to your design for uClinux, the extra cost would be between $3.5 to $9. However, Vladimir points out that many of their customers also use external RAM and storage in their hardware platform that run RTOS, so there may not be extra costs at all.

uClinux Performance with Cortex M3/M4 micro-controllers

Performance is an important question, but can be tricky to evaluate as it highly depends on your application and MCUs. Emcraft has been working on this several years, so they can give some examples:

• uClinux will typically boot within 2 to 5 seconds from power-up to uClinux command line. The boot time varies with the MCU used and uClinux config.
• The interactive shell feels the same as on a Linux on a PC, and you can run vi without feeling sluggishness to edit files on an NFS share for example.
• Networking is fast enough to copy large files over the network (Ethernet or WiFi) within a reasonable timeframe.
• Thanks to the on-chip DMA engines, good throughput rates are achievable for various I/O devices such as SD Card or USB devices.

Performance is highly dependent on the MCU used, and you could consider the following while selecting the MCU:

• MCUs with on-chip caches, such as Freescale Kinetis K70, will run uClinux much faster than those without cache. For example, you can run Qt/Embedded on a 24-bit 800×480 LCD with touchscreen smoothly with Kinetis K70 MCU.
• Fast on-chip Flash can be used to run critical kernel and application code using XIP (eXecute-In-Place). For example, STmicroelectronics STM32F2/F4 MCUs comes with 1MB eNVM, which can be used to run critical code, whereas less critical code, can be run from external RAM.
• Some of the latest Cortex-M3/M4 MCUs can run code from Quad-SPI Flash memory, with performance very close to on-chip flash memory. So you could use QSPI Flash and Linux XIP capabilities to boost performance of critical code. This has already been achieved with NXP LPC1850 and LPC4350 micro-controllers.
• Some Cortex M3/M4 MCUs have multiple cores and you can use the extra core to offload some of the tasks. For example:
  • NXP LPC4350 comes with a Cortex-M4 core (capable of running uClinux) and a Cortex-M0 core that can be used to offload critical and hard-real time code
  • Microsemi SmartFusion SoC combines a Cortex-M3 core with an FPGA.  uClinux runs on the Cortex M3 MCU, and the FPGA is used for I/O handling and real-time processing.

Power Consumption with uClinux on Cortex M3/M4 MCUs

If you’ve selected a Cortex M3 or M4 MCUs, power consumption is most probably of primary interest, and you don’t want uClinux to drain your power more than is needed.

Let’s have a look at Emcraft’s K70 SoM in a configuration where the Ethernet PHY is not installed on the module:

• K70 @ 120 MHz – 100 mA
• 64 MB LPDRAM – 71 mA
• 128 MB NAND Flash – 25mA

This roughly adds up to 200 mA, and practical tests show the power consumption to be about 80 mA (Serial console only active I/O interface).

When the processor can be put into sleep mode (static time), the power consumption for the same hardware configuration is estimated as follows:

• K70 in stop mode – 0.2 mA
• 64 MB LPDRAM in self-refresh mode – 0.7 mA
• 128 MB NAND Flash in standby mode – 0.05 mA

This roughly adds up to 1 mA. Now we have those estimates, the important question to ask is whether software running on the device will be able to achieve those targets.

The good news is that Linux already supports power management, and can be configured so that the “idle process” can be called when no other processes run, and make the core enter in sleep mode, until further processing is required. The problem is that the kernel use a kernel ticker that wakes up the system 100 times per second (default), but this can be improved by building a “tickless” kernel which will calculate when it needs to wake up. This will reduce the number of timer interrupt dramatically, and improve power consumption so that it can match the power consumption estimates above.

If you have questions or remarks, you are welcome to post comment below or on electronicdesign.com article, as Emcraft will monitor those posts and answer questions. Alternatively, you could also visit Emcraft Systems for further details on their uClinux BSPs and ARM Cortex M3/M4 modules.

Disclosure: This post has been sponsored by Emcraft Systems.

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress