Peripherals are fundamental to migration.
Many designs begin by specifying the functions the system will provide and how users will access them.
This will determine the necessary circuitry and the peripherals that need to be integrated into the microcontroller to control them. If, for example, the designer wants to include an industrial Human-Machine Interface (HMI), the microcontroller will need to support an LCD and some buttons or a touchscreen; a machine communication interface; LEDs; and an audible alarm or other audio component. Therefore, the microcontroller will need to integrate a CAN controller for communication; an A/D converter for the touchscreen; and a PWM timer for the audible alarm. The greater the functionality of the peripheral, the less external circuitry will be needed, which can reduce the amount of code the designer has to write. Therefore, with an audible alarm, it is simpler to adjust a PWM to achieve the same result.
Typically, designers want to know two fundamental pieces of information about the kernel: Is it fast enough to execute all the software tasks necessary to support all the features offered by the final product? And does it perform all these tasks efficiently? If the answer to both questions is yes, then most designers won't be too concerned about the type of kernel being used.
More relevant is the amount of existing software and firmware that can be migrated from one kernel to another to provide peripheral support. Since most of the 32-bit microcontroller code is written in C, much of it can be recompiled for any kernel. However, each microcontroller manufacturer will have peripheral functions and programming models exclusive to its own products, regardless of the kernel used. This is what makes code portability a challenge.
Firmware Portability:
Each microcontroller manufacturer supplies a firmware library containing the code to configure and run the peripherals integrated into their microcontroller. However, each manufacturer also implements these peripherals differently, and each peripheral may have different functions. This means that porting an application from one microcontroller to another is not a simple task.
ARM has addressed this issue by defining a standard firmware abstraction layer called the Cortex™ Microcontroller Software Interface Standard (CMSIS), which has been adopted by all microcontroller manufacturers using Cortex-M cores and is used in their firmware libraries. However, this standard does not address the challenges of peripheral portability, nor has it established a standard naming convention for variables or functions. As a result, it does little to reduce the effort and work required to port an application between different ARM microcontroller vendors.
Portability Projects:
While microcontroller vendors may use the same ARM core, they have no incentive to simplify portability to another vendor's microcontroller. The challenge of making a design portable thus falls to the design engineer. To simplify portability, the designer could implement an abstraction layer to create a standard programming interface between the microcontroller, peripheral hardware, and application code. There are at least two ways to accomplish this:
- A compensation or coverage layer can be developed for translation between the microcontroller manufacturer's peripheral library and the application code. While this is probably the most time-efficient solution, it will add more code to the command and data paths.
- Define a standard function and variable naming method and apply it to each peripheral library. While this avoids adding code, it can be time-consuming, especially for complex peripherals.
Portability must be part of the development process from the earliest stages. In addition to firmware/software, there's the issue of pin compatibility, which generally involves re-laying the printed circuit board when switching from one microcontroller supplier to another. External components such as capacitors and regulators may also need to be replaced.
Real-world portability:
Easy portability between 32-bit microcontrollers from different vendors remains a wish list for the industry until peripheral and firmware library portability issues are resolved. Until then, designers must take responsibility for the portability of their designs. One way to mitigate this is to choose a microcontroller that facilitates migration to other microcontrollers within the same manufacturer's product line.
For example, Microchip recently simplified its C compiler portfolio with the MPLAB® XC package, which offers a compiler for each of its 8-, 16-, and 32-bit architectures and supports every PIC® microcontroller and dsPIC® digital signal controller (DSC). This, combined with cross-architecture compatibility to conserve code development investment and multi-package pin compatibility to simplify printed circuit board layout for direct replacement, makes it ideal for this purpose.
Therefore, while designers are still waiting for a standard core to be completed with standard peripherals and firmware, they can at least make future-proof designs by evaluating the cost/benefit ratio of migrating to a single manufacturer's catalog at the start of each project.
