Over the past few years, there has been a lot of talk about standardization on a single core platform to simplify the migration of designs from one MCU vendor to another.
The interesting thing is, in all of this talk there is no mention of the peripherals. But peripherals are at the heart of what it really takes to port an application from one MCU vendor to another.
It’s all about the peripherals
When an engineer starts a new design, he will begin by looking at its functional requirements. What is the system supposed to do? How does the user interact with it? So on and so forth.
Based on this, he will determine the circuitry needed and the on-chip MCU peripherals that are required to control these circuits. For example, an industrial HMI (Human Machine Interface) device will need to support a LCD, buttons and/or a touch screen, communication to the machine, LEDs, a speaker/buzzer, etc.
All of these functions will require some kind of peripheral on the MCU, e.g., a CAN controller for communication, an ADC for a touch screen, a PWM timer for a buzzer, etc.
The more functionality a peripheral has, the less external circuitry is needed, which, in some cases, reduces the amount of code that needs to be written. For example, utilizing a special buzzer mode is easier than having to set up a PWM for the same purpose.
The core requirements are usually straightforward. While very important, the designer is quite abstracted from the core itself. The core really must meet two basic criteria.
Is it fast enough to perform all of the software tasks that are required to create the best user experience? And, does it perform all of these tasks efficiently? The type of core is irrelevant beyond this, as long as it meets these two performance requirements.
Of course, there is also a firmware/software side to the core. Legacy code is something the engineer has to consider. How much work can he save by using existing code? This question is not linked to the core directly, but rather to the peripherals, as most 32-bit MCU code is written in C and as such can be recompiled to any core.
Each MCU manufacturer will have peripheral features and programming models that are unique to its own products, regardless of the core that is being employed, which is what really makes the code hard to port.
Firmware libraries
To help the engineer, each MCU manufacturer supplies a firmware library that contains code to set up and use the various on-chip MCU peripherals. Because these peripherals are implemented in different ways by each manufacturer, and even have different features, porting an application from one MCU to another is not trivial.
ARM has been trying to ease porting efforts by defining a firmware abstraction layer standard called the Cortex Microcontroller Software Interface Standard (CMSIS), and the MCU manufacturers that use the Cortex-M series of cores have adopted it in their firmware libraries.
Unfortunately, this standard does not address the difficulty of porting peripherals, nor does it have a standard naming convention on variables or functions. As a result, there is no easy way to move from one firmware library to another without significant work.
In fact, this standard makes almost no improvement in the effort it takes to port an application among ARM MCU vendors. After all, there is no benefit to the MCU manufacturers in making it too easy to move to another vendor’s product.
Design for portability
Since the MCU manufacturer will not simplify portability to another vendor’s product, it is up to the design engineer to make the design portable. This can be achieved by implementing an abstraction layer that creates a standard programming interface between the hardware (i.e., MCU peripherals) and the application code. There are at least two ways to approach this:
1) Develop a shim layer or wrapper to translate between the MCU manufacturer’s peripheral library and your code. This is probably the most time-efficient solution, but it will add more code in the command and data paths.
2) Define a standard function and variable naming scheme, and apply it to each peripheral library. This avoids adding code, but can be very time consuming, depending on how complex your peripheral usage is.
Portability is not trivial and has to be part of the development process from day one. On top of the firmware/software side, there is the question of pin-to-pin compatibility, which almost always means re-layout of the PCB when moving from one MCU vendor to another. And, there might also be requirements for different external parts, such as capacitors and regulators.
Bottom line
Portability between 32-bit MCU vendors is equally difficult, regardless of the core being used. It is all about the peripherals and related firmware libraries. Each MCU manufacturer will do his best to make the design process as easy as possible by supplying firmware libraries and application notes.
They will also try to make their parts such that you can move between their own families with minimal effort. But portability to a competing solution is something they will not be interested in making too simple.
This is something the design engineer will have to own, and thus should evaluate the cost/benefits of doing so at the beginning of each project.
Information is shared by www.irvs.info
No comments:
Post a Comment