• State Accepted Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 142 subscribers
  • Views 8005 views
  • Users 0 members are here
Options
Related
How was your experience today?

Does anyone use CMSIS-Driver specification?

Pavel A

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

arm-software.github.io/.../theoryOperation.html

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++?

Thanks,

--pa

Parents
  • 0

    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.  ( https://github.com/ARM-software/NXP_LPC/blob/master/LPC1800/CMSIS/Driver/USART_LPC18xx.c )

    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.

Reply
  • 0

    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.  ( https://github.com/ARM-software/NXP_LPC/blob/master/LPC1800/CMSIS/Driver/USART_LPC18xx.c )

    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.

Children
No data