Hello, we are starting a new project based on STM32F4, till this date we had used original STM32 standard peripheral library with Keil RTX, as it was till MDK 5.10. In 5.11, I know that there is a new CMSIS (incompatible with original StdPeriph lib), and ST Micro released their new HAL library STM32CubeF4.
In Keil application note there is a statement on merging STM32CubeF4 code with new CMSIS and integrating it into MDK, which should result in a Keil pack v.2.0 and higher, which will have this new HAL library included.
In what time this new HAL library will be available in Keil MDK ? We would like not to start programming for the old library, if a completely different API has to be released.
Thank you.
Best regards, Pavel Komurka
Note that you can use any C/C++ library that you have source code access to without worrying about if Keil has a download link for the library.
The bigger elephant in the room is when will ST release a relatively bug free HAL/CUBE library that anyone would want to use for a commercial/critical project? When you think you can answer that question, you might be able too determine where it makes sense to direct your development effort in the here-and-now.
Yes, that was the first thing to do. I have copied the new HAL library into Keil with new CMSIS under new folder, and set specific settings to compile it. It compiles and works without any warning or error. So it is completely possible to use it "by hand". Doing this will thus remove support for USB stack, as it uses the original old STM32 peripheral library.
And yes, there is another problem - stability of the new HAL. I was always wondering, if programming for Cortex-M processors should be that complex. Peripherals are very often hard to understand, and reference manuals doesn't always provide answers for many things they should. Peripheral behaviour then leads to bugs due to misunderstanding the concept. STM32 silicon is here for some while, and any toolchain manufacturer, and silicon manufacturer himself, failed to add complex software support for it. ST to this date did the library twice, and I still do not believe that it will be perfect.
I was always wondering if it will not be better to write our own code to all peripherals we need, thus removing any dependency on silicon/toolchain manufacturer, and maintain clean, stable and understandable code.