Does anyone use CMSIS-Driver specification?

In the CMSIS-Driver specification, all interface structs and functions are described as plain C.

But the function calls simply won't work in plain C, they must be C++  in order to receive the hidden "this" parameter.

Same with callbacks - they must receive reference to their "this" object.

So the question - does anybody actually implement drivers per this spec, if yes then how? C or C++?



  • First, AFAIK, all the CMSIS stuff is pure C.  So you shouldn't see any code (directly in the CMSIS driver stuff) that uses "this."

    I would say that the driver specification, which puts all the functions for a device into a data structure like:

    /* USART Driver */
    extern ARM_DRIVER_USART Driver_USART3;

    Certainly does look like it's missing some sort of backward reference to the particular instance.   I found an LPC implementation of the ARM_DRIVER_USART, and it does the obvious (and depressingly inefficient):

    static int32_t USART0_Send (const void *data, uint32_t num) {
        return USART_Send (data, num, &USART0_Resources);
    static int32_t USART1_Send (const void *data, uint32_t num) {
      return USART_Send (data, num, &USART1_Resources);

    Sigh.  ( )

    My impression is that the CMSIS-Driver stuff is NOT used often on "simple" peripherals like USARTs, probably for this sort of reason, and because it's VERY general purpose and probably hardly ever that close to what developers actually want.  More complex drivers (Ethernet, USB) are harder to write quickly on your own, more likely to only have a single instance, and/or be so complex that the added overhead of adding the instance is less significant.

  • Hello Pavel,

    thanks for your inquiry. If you check all packs that are publicly available, there are close to 800 unique CMSIS-Driver components in the packs and more than 25% of all supported devices are covered by CMSIS-Drivers. I would not say that "nobody is using it". For example, NXP adds CMSIS-Drivers for serial interfaces (USART, SPI, I2C) to all of their device family packs.

    Hope this helps,