The surprising differences between ARM MCU cores that appear to be identical
There are many reasons why the ARM Cortex-M series of processor cores has come to dominate the market for 32bit microcontrollers. Across the many varieties of Cortex-M cores, design engineers can choose from an array of performance, power consumption and communications capabilities, allowing them to find an ARM based MCU which will be suitable for almost any application. And, by standardizing on the Cortex-M family, OEMs not only benefit from a common instruction set, but also from an ecosystem of libraries, tools and firmware with which thousands of embedded engineers are already familiar.
One reason commonly put forward for using Cortex-M based MCUs is their potential for code portability: the common Cortex-M instruction set and ARM’s Cortex Microcontroller Software Interface Standard – or CMSIS – are important parts of the company’s efforts to highlight to the embedded world that code developed for one ARM based MCU can be ported readily to another without the need for substantial modification.
In a typical scenario, an OEM might want to upgrade an existing product by adding additional features, but these features often require new peripherals – for instance a touch sensing controller or an LCD controller –and these are not available from the existing MCU. This might require a move to a different Cortex-M3-based controller and it’s not unreasonable for designers to therefore assume that the firmware and application code running on the first device will run easily on the second. After all, both cores are called ARM Cortex-M3, so they must surely be the same?
Likewise, a designer who has developed a system on an ARM Cortex-M0+ core knows the capabilities, performance and features of that core. This designer might assume they can use any vendor’s MCU which features a Cortex-M0+ core in a new project, confident that the CPU will offer exactly the same capabilities, performance and features.
Unfortunately, these assumptions are not always valid. The label ‘ARM Cortex-M3’ is not attached to a unique and reproducible piece of hardware; it is, in fact, simply a naming convention. ARM attaches the label ‘ARM Cortex-M3’ to a bundle of elements of intellectual property and licensees can then configure this IP for use in each MCU which they produce.
Clearly, there are strict limits to the number and extent of the flavours of the core that the licensee can make – the structure of the core, for example, is largely fixed by ARM. Nevertheless, it is better not to think of an ARM Cortex-M3, for instance, as being a single core; rather, consider it as an IP platform on which each MCU manufacturer builds its own hardware.
This means that it is important to understand at the outset of a design how the differences in core configuration can affect the performance of the application. In effect, the designer is choosing not from a selection of handful of ARM Cortex-M cores, but from hundreds of permutations of core configurations – in some ways, it can be like assembling a structure from a kit. In making this choice, advice from ARM Certified Engineers at distributors or other service suppliers can be extremely helpful.
So what are some of the most surprising differences in core implementations in the latest MCUs based on the Cortex-M?
Make the right choice
These are examples of some of the most important configuration options that MCU manufacturers have to decide on for each product they develop. They show how important it is to make the right selection of Cortex-M series core, no matter from which manufacturer’s MCU family the designer is choosing.
At the beginning of every new design project, designers will save themselves a lot of time and trouble in the later stages of the development if they study carefully the datasheet of the MCU they are intending to use – and especially the sections which describe the features and functions of the core.
While past experience with a Cortex-M core is some guide to future uses of the same type of Cortex-M core, there might be differences. Designers might well run into problems unless they take these differences into account at the very start of their project.
News on theme: