Re:CMSIS and driverlib
We get very little feedback from customers about CMSIS so we don't really know how it is being used or how much it is being used.
With regard to the first post (from October), DriverLib header file definitions were defined 2-3 years before CMSIS was developed. So that is why they are different. The problem is we cannot change the definitions in CMSIS, and if we change in DriverLib then we may end up with a legacy code issue. I will review the problem and see if there is some fairly painless way to solve that particular problem.
With regard to the second post:
how do DriverLib and CMSIS compare?
CMSIS is a set of register definitions. It provides a shorthand for reading and writing processor and peripheral registers. The register definitions for the processor core are common no matter the microcontroller vendor, while the vendor specific registers are all defined by the vendor. So you get commonality for the Cortex-M3 core registers but not for peripherals. CMSIS does nothing to address higher level programming issues (so far). For example there is no easy way to set the UART to 115200 baud rate. You still must write/read all the necessary peripheral registers in order to configure it.
DriverLib provides two equivalents to CMSIS (same concept, different format) for accessing registers. The first is to use the HWREG() set of macros to read and write registers, using macros for names of registers that we defined. For example:
| Code: |
status = HWREG(ADC_BASE + ADC_O_ISC);
|
This is the way we perform all the accesses inside DriverLib. While you can use this method for directly writing register access code, it is a little awkward to write the base plus offset, so we developed another method that makes it easier for direct register programming. This does away with the HWREG macro and just uses register names directory like this:
| Code: |
status = ADC0_ISC_R;
|
The names match the register names in the data sheet so that if you see the register in the data sheet you know what name to use in your code.
So that is the DriverLib equivalent of CMSIS. However DriverLib really provides much more and that is an abstraction of the peripheral so that you don't need to hand code every register read and write to configure or use a peripheral. Instead you call a function which does the work for you.
Some people prefer to code directly to registers and that is fine and we support that. But others find it is more productive to use the DriverLib API for using the peripherals.
will there be a DriverLib version that sits "on top" of CMSIS and (internally) using CMSIS interfaces ? when ?
There is no plan for this at this time. Can you explain how this would be helpful? If you are calling DriverLib functions, then how does it matter whether the register accesses are performed using a CMSIS syntax or a DriverLib syntax?
i think that a DriverLib version "on top" of CMSIS would additionally enhance portability of application that have been developed using DriverLib
Can you explain how this would help portability? And do you mean portability between parts from one vendor, or you mean across vendors? I think CMSIS is a fine idea and it certainly does lend to portability for the parts of code that deal only with the core. But most microcontroller code is related to using peripherals and even if all that is coded using CMSIS, you still probably have to rewrite large amounts of it to change to another vendor microcontroller. So in reality I don't think it really makes the code very portable. Feel free to disagree, I would like to understand this.
At some point, CMSIS may define a peripheral API and when that happens we will re-evaluate and see how that fits in with the DriverLib concept.
login or register to reply
|
