In November of 2008, ARM announced the availability of the Cortex Microcontroller Software Interface Standard (CMSIS). They claim that this will reduce the cost of designing software when creating projects for new devices or migrating existing software between Cortex-M based microcontrollers from different silicon vendors. This sounds very good, but is it valid? This paper investigates these claims to determine just how valid they are. This paper also looks at the components of a typical microcontroller and then see just what can or cannot be gained by adding an abstraction layer on top of the typical peripheral firmware libraries.
I'm not surprised that this technical paper is from Microchip given that they decided to go with a Mips core for the PIC32 while almost everyone else went with a Cortex-M3. I doubt this paper would exist if the PIC32 was Arm based.
Seemed to be a very lightweight editorial not really a "Paper"... I am currently working with four different Cortex M3 processors from two vendors.
While the peripherals are a little different for each, I use the same compiler/debugger tool chain from IAR all of them. Because of that, my job is greatly simplified. (Tool familiarity, firmware build machine setup, tool cost savings, code generation is consistent as well as a host of other benefits.) Creating an abstraction layer for the unique peripheral differences is not that big of a project. In addition, portable code is do-able and not very difficult to write.
Let me get this right.
I can source ARM-based microprocessors from a variety of companies with a broad range of different peripherals and I will have to do some porting between them as they're not all identical and the CMSIS abstraction layer is not great.
Or I can buy from Microchip and I won't have any portability issues because I can't buy similar parts from anyone else?
Or is it perhaps that I will always have portability issues even if I buy only 32-bit Microchip parts?
FWIW, so far I've had fewer nasty surprises moving between ARM processors from Atmel, NXP, STM and TI, from Cortex-M0 to Cortex-A8 than I used to have getting some of the old 8-bit PICs to work across different parts.
But then that's just my personal experience.
Microchip Technology Inc. is a leading provider of microcontroller, digital signal controller, analog and serial EEPROM devices, providing low-risk product development, lower total... Read More
Technical Paper / Application Note
0
4
Download to Print
Add to bookmarks
4 comments
write a commentcharly5139 Posted Jan 19, 2011
Yes, it's a myth...
reply
emmsys Posted Jan 26, 2011
I'm not surprised that this technical paper is from Microchip given that they decided to go with a Mips core for the PIC32 while almost everyone else went with a Cortex-M3. I doubt this paper would exist if the PIC32 was Arm based.
reply
someEmbeddedGuy Posted Mar 1, 2011
Seemed to be a very lightweight editorial not really a "Paper"... I am currently working with four different Cortex M3 processors from two vendors. While the peripherals are a little different for each, I use the same compiler/debugger tool chain from IAR all of them. Because of that, my job is greatly simplified. (Tool familiarity, firmware build machine setup, tool cost savings, code generation is consistent as well as a host of other benefits.) Creating an abstraction layer for the unique peripheral differences is not that big of a project. In addition, portable code is do-able and not very difficult to write.
reply
GordonScott Posted Sep 7, 2012
Let me get this right. I can source ARM-based microprocessors from a variety of companies with a broad range of different peripherals and I will have to do some porting between them as they're not all identical and the CMSIS abstraction layer is not great. Or I can buy from Microchip and I won't have any portability issues because I can't buy similar parts from anyone else? Or is it perhaps that I will always have portability issues even if I buy only 32-bit Microchip parts? FWIW, so far I've had fewer nasty surprises moving between ARM processors from Atmel, NXP, STM and TI, from Cortex-M0 to Cortex-A8 than I used to have getting some of the old 8-bit PICs to work across different parts. But then that's just my personal experience.
reply