Opting for ARM software scalability

Behind much of the success of ARM architecture is a scalable software model, where in theory the same code runs on the smallest member of the family to the largest. In practice, there are profiles, and a variety of hardware execution units, and resource constraints in low power scenarios that enter the picture. As a result, operating systems have evolved very differently.

Going “bare metal” or with a very compact kernel solves some of the problem at the low end; developers can work close to the hardware and #ifdef around support for variations in resources. If one needs more advanced features, such as graphics, connectivity stacks, and virtualization, or is hoping to build on value from somewhere in the open source community, an operating system with a defined set of APIs becomes much more important.

Coming from the other direction, full featured operating systems haven’t scaled down well to microcontrollers, with the biggest roadblock partitioned memory requiring an MMU implementation. The ability to virtualize memory and harden against task crashes is a huge plus, as the popularity of Linux and Android attest. With improvements in processor speed, the term “real-time” on larger cores has become more of an issue of controlling background tasks instead of interrupt response and context switching times.

Scanning the commercial and open systems offerings for operating systems usually provides a very different answer in support for ARM Cortex-M versus ARM Cortex-A, even leaving out the latest 64-bit ARMv8 discussion. There are, of course, a handful of operating systems that straddle the boundary, generally in the vein of microkernels scaling up.

One of the optional hardware execution units in the Cortex-M architecture is a memory protection unit (MPU), available on Cortex-M4, Cortex-M3, and Cortex-M0+ cores. It provides eight protection regions, which can implement the basics of access rules and task protection running out of flash without creating a full-blown virtual memory model and the complexity of MMU programming.

Mentor Graphics has just extended their Nucleus RTOS into this space, offering the same reliability from their experience with industrial and medical applications in MCU territory. By leveraging the MPU, they are bringing the same process model across the ARM spectrum. Developers still have access to the more advanced features of Nucleus on bigger ARM cores, including a multicore framework for mixing and matching operating systems.

The key observation here is in smaller devices, applications often don’t need a huge number of tasks and memory partitions – but having just a few may make a difference between either risking integrity of an application, or having to go up to a much bigger and hungrier SoC. MCU vendors are generally seeing the light, offering the optional MPU on Cortex-M as standard fare, and enabling a lightweight version of the same techniques previously only on larger Cortex-A cores. It is another example of how MCU and SoC space is starting to blur.

Hardware and software teams need to carefully think through use cases when deciding what to include and what to omit. There may be short term savings in opting out of some execution units when tailoring an ARM implementation, but in the long term those features may emerge as very valuable. We will likely see more of these fine-grain decisions – memory protection, encryption, and DSP extensions among the candidates for support – favoring inclusion moving forward, helping software scale better across ARM processor families.

Related articles:

The Secret Essence of an IoT Design

More “toddlers” innovating on the IoT