Application Portability of 32-bit MCUs—Reality or Myth?

In November 2008, ARM® announced the Cortex™ Microcontroller Software Interface Standard (CMSIS). They claim that this standard will reduce software design costs for software development projects for new devices or when porting existing software between Cortex-M based microcontrollers from different chip vendors. This sounds good, but is it true? This article will examine these claims to determine their truth. We will first review the components of a typical microcontroller and then see what can and cannot be achieved by adding an abstraction layer on top of a typical peripheral firmware library.

According to ARM, CMSIS is "a vendor-neutral hardware abstraction layer for the Cortex-M processor family. CMSIS provides a simple and consistent software interface for processors from different silicon vendors and middleware providers. This simplifies software reuse, shortens the learning curve for developers and reduces the time to market for new microcontrollers (MCUs). CMSIS allows silicon vendors to focus on the peripheral features of their products without having to maintain incompatible standards when programming their MCUs."

To put this article in context, we need to understand how microcontrollers are designed. Microcontrollers are highly integrated system solutions. In fact, they can be called System on Chip (SoC). Like any SoC, the functionality of the chip is defined by the hardware peripherals that are integrated with the CPU core. Of course, the performance and architecture of the CPU core determine the kind of code that can be executed on the chip, but the chip interacts with the rest of the system through the peripherals. The flexibility of the microcontroller peripherals makes it a unique SoC. Because of this flexibility, the setup and control of microcontrollers can be quite complex. A large number of registers need to be set before any actual operation can take place. To help designers with this task, chip manufacturers provide firmware libraries that simplify code development. These libraries include all the functions necessary to set up all the registers and control various parts of the microcontroller. Because each chip manufacturer's microcontrollers have different peripherals and functions, each manufacturer provides a unique library to differentiate their products from their competitors. Let's look at what parts of the microcontroller differentiate one manufacturer from another.

Each MCU manufacturer has its own way of implementing the overall system integration (i.e., system bus, clock tree, and memory), even when the CPU core is the same. With these implementations, each manufacturer builds on their strengths to make their MCU a better solution for the customer. Let's examine each system component:

• The clock tree provides the clock pulses for the system to coordinate the timing of all other functions. The clock tree is designed to optimize the system speed and enable the system to operate economically. The structure of the clock tree is directly affected by the functions and peripherals contained in the chip and the problem the chip is designed to solve. Therefore, the clock tree structure varies from manufacturer to manufacturer. In addition, the clock tree registers need to be programmed with the appropriate values ​​before any operation can take place.

• The architecture of the system bus defines how all MCU functions are integrated. Some manufacturers use one or more peripheral buses, depending on the peripherals being integrated. All of this changes the kind and number of registers that need to be set to make the most of all available features.

• Although all microcontrollers have both nonvolatile memory (such as Flash) and volatile memory (such as SRAM), each manufacturer's specific integration is different. Some manufacturers connect Flash memory directly to the core and the bus matrix, while others connect it to the system bus or bus matrix. RAM is sometimes divided into two separate memory banks to allow simultaneous access by the core and peripherals. These different memory organizations can affect the way code is written, which often has a direct impact on the performance of the application when designers move from one manufacturer to another. Each manufacturer provides a range of standard and specialized hardware peripherals on its microcontrollers.

• Standard peripherals provide common functionality, such as serial communication via UART or SPI. These peripherals can also be timers or PWMs. Standard peripherals are common across all MCU manufacturers, but they may have certain enhancements that provide customers with greater flexibility and/or additional functionality. Like any other part of a microcontroller, standard peripherals have their own registers. Although the functionality of a standard peripheral may be the same, almost every manufacturer implements it differently, resulting in a different register structure across MCU vendors’ products.

• Specialized peripherals are used for specific tasks that are unique to certain applications. For example, brushless motor control PWM, I2S for audio playback, or encryption/decryption. Depending on the complexity, these specialized peripherals may have only a few registers or more than 30 registers.

As mentioned earlier, each MCU manufacturer has its own peripheral firmware library to help customers implement designs and quickly enter the prototyping stage. The firmware library includes code developed by the chip manufacturer to set all the registers in various parts of the chip, such as clocks, buses, and peripherals. Function calls are provided to easily set each register to help developers focus on entering the parameters required by the application. The function is responsible for writing these parameters to the corresponding memory location. By using the functions in the firmware library, developers do not have to understand all the registers and their locations to make the chip run properly. This saves time and focuses on more application-specific tasks, such as developing appropriate algorithms for the application.

The peripheral firmware library also includes functions for controlling the peripherals (also done through registers). Again, developers do not need to worry about the bits and cells of the registers, just choose the right function for their code. Abstraction layers can be applied to the peripheral firmware library to help simplify code development, which is where CMSIS comes into play. But there is still a question: does this create code compatibility issues?

Now that we have a clear idea of ​​what each microcontroller manufacturer offers, we can look at what, if anything, the abstraction layer can do for the designer. First, let's look at what CMSIS claims to provide, keeping in mind the system architecture, peripherals, and firmware libraries described earlier.

For CMSIS version 1.3

1. Kernel Peripheral Access Layer: Contains name definitions, address definitions, and auxiliary functions for accessing kernel registers and peripherals. It also defines a device-independent interface for the RTOS kernel, including debug channel definitions.

2. These software layers are extended by silicon partners through:

    a) Device peripheral access layer, which provides the definition of all device peripherals;

    b) Access functions for peripherals (optional): Provides additional helper functions for peripherals.

After reading this description carefully, we can see that CMSIS provides a common language by which different elements of an MCU can be described. Next, we look at some of the features included in MCUs produced by two different "silicon partners" (MCU manufacturers using the ARM Cortex-M processor core).

It is obvious that even though both 32-bit MCU manufacturers use the Cortex-M3 core, there are still major functional differences. The functions listed in the table are the most standard functions of microcontrollers, but even so they are still different. This means that even if both manufacturers use the same core, the software needs to be adjusted to run the most basic routines, such as toggling I/O or using the UART. It is not possible to port the software between A and B without some degree of code rewriting and just adjusting the basic parameters.

By definition, CMSIS provides a standardized language for accessing core elements, but silicon partners/MCU manufacturers must provide their own firmware to interact with device peripherals. The two most basic functions of any MCU involve (1) how to relate the system architecture to the peripherals, and (2) how to

How to structure the MCU peripherals to achieve the desired control and/or functionality. This is the problem that firmware libraries provided by manufacturers can help solve, and it is the core of the code compatibility problem. Adding abstraction layers to these libraries can help improve portability, but they cannot solve all functional differences between two MCUs. Any advanced peripheral function cannot be ported to another MCU where the function does not exist, regardless of the presence of an abstraction layer. These enhancements implemented by microcontroller manufacturers help differentiate the MCU from competitors and help designers improve their solutions. However, this can lead to code incompatibility.

The concept of an abstraction layer is related to the design of operating systems. It creates a standard way for an operating system to access the processor (on which it is running) and simplifies the process of changing processors. It is important to know that a processor (microprocessor unit, MPU) is the least integrated core of a system element, which makes processors from different manufacturers much more similar than MCUs. In addition, the code running on the processor is software, not firmware. That is, the code does not usually control any hardware. On the other hand,

Microcontrollers are systems on a chip, which means that the core and integrated peripherals are more closely connected. For MCUs, the concept of abstraction layers makes the most sense if you are running an RTOS. On the other hand, using an RTOS decouples the application code from the hardware, removing the strict control that is common in microcontroller applications.