2014-03-04 02:32 AM
I had a quick glance into the new format ST libs that come with STM32cube. We have some projects using the Std peripheral libs and wonder if they should be refurbished to be used with the new HAL libs. I'm a little concerned of the maturity of the new libs and also the work which is involved, and also wonder if the same functionality is covered as with the now declared NRND libs.
Some questions: is there a document which would point out the differences best with a quick guide how to rework existing projects? Has anybody succesfully made the shift? Werner2014-03-04 06:57 AM
Has anybody successfully made the shift?
I have not, waiting for some compelling driver to invest the time/effort to transition, currently not seeing that, old code is working fine, and is well characterized.2014-03-04 07:07 AM
A quick compare to the functionality of the GPIO lib shows, the new stuff is similar but not equal. The HAL lib features HAL_GPIO_TogglePin, but does not support 16bit read write of Ports as the Std peripheral lib did (I checked the Stm32F10x_GPIO.c)
2015-05-19 10:56 AM
2015-05-19 01:15 PM
For existing code that works, I don't see any advantage.
For new code, using the STM32Cube seems to be the correct choice. Despite some immaturity (which is gradually being beaten out of the code), this appears to be the direction that STM is investing its effort.Probably want a comment from an STM person here. :)2015-05-21 01:13 AM
It seems to depend on which chip you are using. The STM32F4 code seems to mature, while I am very much missing support for the STM32F207 which I am using (no updates for over a year now). I had my project more than half finished with the SPL, when I unfortunately was convinced by ST arguments about ''future portability '' etc. to rewrite all with Cube drivers. Some problems mentioned in the F4 release notes still exist in the F2 code.
Some drivers only barely hide registers, like the CAN driver. For some an argument for ST could be project and code generation with the STM32Cube application. I must say that compared to the Dave tool from Infineon I had used 15 years ago on a C515 this is a joke. 15 Years ago I could define all CAN message objects and filters on Dave, today I am calling functions after wading through layers of typedefs because there is no documentation for the F2 drivers. Regards, Ralph2015-05-21 02:12 AM
> STM32F207 which I am using (no updates for over a year now).
STM32F2x5/7 and STM32F4x5/7 are nearly the same MCUs with different Cortex-M cores and different amount of SRAM. The peripherals and the pinout are the same if I'm not wrong. So porting the STM32CubeF4 updates to STM32CubeF2 should be trivial. I wonder too why ST are not updating it.2015-05-22 04:02 PM
What to make of the issue that ST has said the Standard Peripheral Library code is at end of life, is depreciated, not to be used in new designs, etc? This seems to say that at some near date, those libraries will go stale for bug fixes, additions, etc.
If one does not have an intellectual investment in the legacy libraries, and has a new-start project, then should one take a risk and use the legacy libraries? Or hand-code using the HAL? Or use CubeMX to auto-generate as pin maps change during product protypting?