New HAL libraries vs Std Peripheral libraries

[ingwmeier]

Posted on March 04, 2014 at 11:32

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? Werner

[Tesla DeLorean]

Posted on March 04, 2014 at 15:57

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.

[ingwmeier]

Posted on March 04, 2014 at 16:07

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)

[este00]

Posted on May 19, 2015 at 19:56 Any update on this? Are there compelling reasons to use the STM32 Standard Lib over the latest STM32CubeMX? I see the pros for MX as integration between different STM32 parts.... Downside and issue I'm faced with is portability to RTOS and compilers. For example Rowley has the CTL/Tasking Library/RTOS and it surely could be made to work with the CubeMX HAL, but it's currently designed to work with the standard libs, is it worth changing that around? If I only plan on using one STM32 part, is CubeMX just a pain to try and integrate?  The standard lib does look slightly cleaner to me.

[mduffy]

Posted on May 19, 2015 at 22:15

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. :-)

[rchris]

Posted on May 21, 2015 at 10:13

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, Ralph

[qwer.asdf]

Posted on May 21, 2015 at 11:12

> 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.

[childresss]

Posted on May 23, 2015 at 01:02

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?