just for my clarification : if i use those CMSIS libraries , i can later migrate my code to another arm processor from different vendor (ex: ti, nxp ..)
ARM, Ltd designs and licenses the ARM core designs to various manufacturers whom then package the ARM core design with several peripheral modules, this maintains a certain level of cross manufacturer compatibility, thorough the standardization of common core architecture, assembly languages, etc. However, there maybe variations in the naming of various core register or bit identifiers, particularly in specific compiler header files. Of course, the manufacturer added peripherals and features tend to be specific to that manufacture, therefore while not terribly difficult, porting code from one vendor's ARM to another, will typically require some code modifications and identifier substitutions. The CMSIS libraries can greatly simply this task by providing a common API across all ARM Cortex-Mx devices, regardless of the manufacturer.
while the stm32cube is specific for ST and doesn't provide easy migration , right ??
Correct, the STM32CubeFx libraries are specific to the ARM Cortex-Mx devices manufactured by ST.
also does using stm32cube provide an advantage of libraries for the peripherals found on ST version of the ARM processor , i understand that different vendors have same processor but different peripherals right ??
Perhaps, although my experience with the STM32CubeFx is limited in comparison with the CMSIS libraries, I suspect the STM32CubeFx libraries may provide a bit greater flexibility with peripheral configuration as they are geared specifically towards STM32 ARM Cortex-Mx devices.
So CMSIS libraries are targeted toward the more general (or common) core ?
No, the CMSIS libraries are actually composed of several modules, CMSIS-CORE, CMSIS-SVD, CMSIS-DAP, CMSIS-DSP, CMSIS-DRIVER and CMSIS-RTOS, along with code templates.
CMSIS - Cortex Microcontroller Software Interface Standard
The ARM® Cortex® Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer for the Cortex-M processor series and specifies debugger interfaces. Creation of software is a major cost factor in the embedded industry. By standardizing the software interfaces across all Cortex-M silicon vendor products, especially when creating new projects or migrating existing software to a new device, means significant cost reductions.
The CMSIS enables consistent and simple software interfaces to the processor for interface peripherals, real-time operating systems, and middleware. It simplifies software re-use, reducing the learning curve for new microcontroller developers and cutting the time-to-market for devices.
what about combining both ??
I believe the STM32CubeFx libraries have incorporated several modules of the CMSIS libraries and provided them as examples, I would recommend downloading the STM32CubeF4 and taking a look.
STM32CubeF4
ST also offers the STM32CubeMx, which is a GUI to help generate the necessary header files with the required pin and hardware configurations. I've not had the time or opportunity to test it as yet.
If you have not already, you might consider purchasing a JTAG/SWI programmer/debugger, as in circuit debugging of complex applications is almost a necessity. There are several on the market, some even open source devices, however my preference is for the Segger J-Link, almost all offer driver support for KEIL, so that is rarely an issue.
Segger Debug Probes - J-Link and J-Trace
Segger also offers an educational license version of their J-Link, the J-Link EDU which is functionally identical with their professional version.
Segger J-Link EDU
ST also markets a JTAG/SWI programmer/debugger specific to their devices, I have not had any experience with their device, other than the embedded version on their Discovery series of dev boards.
BigDog