• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 3078 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex Microcontroller Peripherals Interface Standard (CMPIS)

Kool King
Note: This was originally posted on 23rd November 2012 at http://forums.arm.com

The need for a Cortex Microcontroller [size="3"]Peripherals Interface Standard (CMPIS)[/size]

Personally I got scared after reading this topic about ARM Cortex-M processors and CMSIS:
http://www.avrfreaks...wtopic&t=127016

At  first, CMSIS appeared to me as a standard interface between the  programmer and Cortex-M controllers including their peripherals.
Little  by little I have realized that despite the fact CMSIS makes some order  in the world of ARM microcontrollers, produced by many companies, it  leaves the peripherals at the mercy of each vendor. There are hundreds  of API functions for setting and working with peripherals just for a  single manufacturer. For example, if it happens someone starts with ARM  controllers produced by TI and learns Stellaris Peripheral Driver  Library ( http://www.ti.com/li...9o/spmu019o.pdf  ) and after some time he has to move to NXP LPC ARMs he is simply  obliged to assimilate a new set of APIs different from the one Stellaris  uses.

I understand vendors desire to add various, more or less  exotic features, to peripherals to make their ARM based controller  distinct from those built by other manufacturers but  a set of common  basic API functions for :Timers, ADCs, I/O ports, etc., able to make  each peripheral functional at minimum, will make the life of programmer  much easier when they have to port an application from one Cortex-M to  another.
At the moment, even with CMSIS, adapting a source code  written for an ARM uC to another is nearly as difficult as porting a  program between two unrelated microcontrollers.
Parents
  • Arm Employee Badge
    Note: This was originally posted on 23rd November 2012 at http://forums.arm.com

    You are right, we have not addressed API's for peripherals so far, we only  addressed the way Peripheral Registers and Peripheral Interrupts are exposed.

    The reasons behind are complex:
    • an API may introduce overhead that reduces ultimately the performance; I/O pins can be typically altered by just writing to the related Peripheral Registers, but each company uses a different I/O Port concept.
    • more complex Peripherals need clock and frequently DMA; however these are shared by many peripherals.  APIs that focus just on a peripheral are therefore insufficient.
    • SiP like to differentiate with peripherals; therefore there is not much support when we try to standardize peripherals.
    CMSIS provides today:
    • a consistent way to program CORE peripherals
    • a standard way to startup a system
    • access to special processor instructions
    • allow migration between the various Cortex-M processors
    • a standard set of Digital Signal Processing (DSP) functions
    • a standard way to define Peripheral Views for Debuggers
    We are going to extend CMSIS further over time. For example, we have extended CMSIS recently with an RTOS API and we think that a standardization of a higher-level interface (drivers) for complex peripherals might be the way forward.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 23rd November 2012 at http://forums.arm.com

    You are right, we have not addressed API's for peripherals so far, we only  addressed the way Peripheral Registers and Peripheral Interrupts are exposed.

    The reasons behind are complex:
    • an API may introduce overhead that reduces ultimately the performance; I/O pins can be typically altered by just writing to the related Peripheral Registers, but each company uses a different I/O Port concept.
    • more complex Peripherals need clock and frequently DMA; however these are shared by many peripherals.  APIs that focus just on a peripheral are therefore insufficient.
    • SiP like to differentiate with peripherals; therefore there is not much support when we try to standardize peripherals.
    CMSIS provides today:
    • a consistent way to program CORE peripherals
    • a standard way to startup a system
    • access to special processor instructions
    • allow migration between the various Cortex-M processors
    • a standard set of Digital Signal Processing (DSP) functions
    • a standard way to define Peripheral Views for Debuggers
    We are going to extend CMSIS further over time. For example, we have extended CMSIS recently with an RTOS API and we think that a standardization of a higher-level interface (drivers) for complex peripherals might be the way forward.
Children
No data