• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 18 subscribers
  • Views 618 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

Acceding peripherals by CMSIS

moh you

I just started to use CMSIS in my Project. it seems to me this library should have given me some functions to access the peripherals instead of accessing them directly by using the vendor.h (in my case LPC17xx.h)library to make my code more general and vendor independent. if this concept is correct why I can access to my port by this LPC_GPIOx-> (it's define in LPC17xx.h) and can not use GPIOx-> .
I would Appreciate if you tell me the differences between PIN or GPIO Driver under the Device section in Keil "Manage Run Time Environment" and Core in CMSIS (because as I said I Think CMSIS should give us some functions to access the Ports )

Parents
  • 0

    Just a quick note.

    You can't have any library hiding differences in hardware by just renaming some data type names and then access a generically named pointer.
    So:

    LPC_GPIOx->


    can't become a generic:

    GPIOx->


    Rename of register names and bit field names is only possible when there is a 1-to-1 correlation between available registers, and each register has a 1-to-1 correlation (or if you limit yourself to a common subset).

    That's why libraries normally makes use of function calls, C++ method calls or creative macros to perform actions - and then internally takes care of exactly how to do it. Which also means that the processor may need to perform a number of additional instructions consuming additional bytes of code space just for a translation layer.

    And what to do if you have a need to perform own actions in an ISR?

    In the end, it's a trade-off between a reasonably efficient standard library implementation supporting a generic blend of functionality - or full hardware ownership with tight code being allowed to do 100% of what the hardware supports.

Reply
  • 0

    Just a quick note.

    You can't have any library hiding differences in hardware by just renaming some data type names and then access a generically named pointer.
    So:

    LPC_GPIOx->


    can't become a generic:

    GPIOx->


    Rename of register names and bit field names is only possible when there is a 1-to-1 correlation between available registers, and each register has a 1-to-1 correlation (or if you limit yourself to a common subset).

    That's why libraries normally makes use of function calls, C++ method calls or creative macros to perform actions - and then internally takes care of exactly how to do it. Which also means that the processor may need to perform a number of additional instructions consuming additional bytes of code space just for a translation layer.

    And what to do if you have a need to perform own actions in an ISR?

    In the end, it's a trade-off between a reasonably efficient standard library implementation supporting a generic blend of functionality - or full hardware ownership with tight code being allowed to do 100% of what the hardware supports.

Children