I'm using SPL still - should I go to STM32Cube now? (experienced users opinios)

[uc2013135191]

Posted on July 09, 2016 at 15:04

Hi everyone,

So I usually check a bit of the forum with issues related to the STM32Cube and opinions, but I haven't done that in a while.

So I would like to hear the opinion of some veteran users about how the STM32Cube is now. I have been using the Standard Peripheral Library for the F0 and F4 (I tried for the F1 but gave up on it).

[Nesrine M_O]

Posted on July 13, 2016 at 15:38

Hi afonso.luis.002,

I encourage you to migrate to the STM32Cube HAL software solution as the new platforms like F7, L4 doesn’t support SPL.

-Syrine-

[AvaTar]

Posted on July 13, 2016 at 15:55

> I encourage you to migrate to the STM32Cube HAL software solution as the new platforms like F7, L4 doesn’t support SPL.

 

ST employees are expected to push the products of their company.

Just look around, read the bug reports, complaints, and comments of experienced users, and decide for yourself.

Perhaps you fare better without any ST library ...

[Tesla DeLorean]

Posted on July 13, 2016 at 17:22

I have a long standing position on this, won't rehash it again here.

Unless you have a compelling reason to migrate all your code to the new paradigm, don't. The SPL is solid, with no appreciable bit-rot.

If you are refactoring your code and design, expand your mind to other parts and opportunities for change.

[uc2013135191]

Posted on July 18, 2016 at 00:28

I am still studying actually, I only used the STM32 for some hobby projects, nothing fancy so I am not really that stuck to the SPL.

I'm just considering to be able to use the newer parts and maybe some ease into porting code into different series.

[Christopher Pappas]

Posted on July 18, 2016 at 03:17

If you are not yet working with STM32F7 series MCUs, just use SPL for now, and slowly migrate your code from SPL to HAL. I have been doing this for the past 7 months, very unpleasant experience and lots of tricks needed to patch all of HALs bugs, but about 80% of my SPL code is working ok in HAL now.

[AvaTar]

Posted on July 18, 2016 at 08:49

> If you are not yet working with STM32F7 series MCUs, just use SPL for now, and

 

> slowly migrate your code from SPL to HAL. I have been doing this for the past 7

 

> months, very unpleasant experience and lots of tricks needed to patch all of HALs

 

> bugs, but about 80% of my SPL code is working ok in HAL now.

 

Familiarizing myself with the F7, I will go entirely without Cube.

The SPL was ''thin'' enough to leave important architectural decision to the developer.

Cube enforces far too much of it's own design concepts, at least for my taste.

However, that is expected from a ''Monkey Click Button'' framework (to quote clive1 here ...).

[Christopher Pappas]

Posted on July 18, 2016 at 19:13

Is there a top-secret hidden link to SPL for F7? I would switch back in a heartbeat if there was. How can anyone write code for F7 if STM only provides HAL drivers? 

[uc2013135191]

Posted on July 18, 2016 at 19:19

I tried it out a bit for the F0.

Played the basics with LEDs and buttons and then tried to adapt a portion of code I made for a I2C IMU (yes starting with I2C in a STM32...). The tiny API is made so there is a driver part you must fill in, then just use the''methods'' (well it's not a class) which call the low level driver functions.

Well after trying out what the package has, both HAL and LL I must say I liked a lot the LL because it's very similar to a API I use for another ARM. It was much easier to adapt how I wanted it.

Now let's try again with HAL. Confusion settles. As of now my conclusion (probably not the right word but let's roll with it) is that:

1st case: you want to use the MX generator to keep changing peripheral configs.

You have a problem with the HAL_I2C_MspInit (or other equivalent functions for other peripherals). Like, your API can't handle the I2C config at all if you don't use the MX to set up the I2C - if you customize the HAL_I2C_MspInit yourself then next time you use MX again your custom code is gone (or is it? Can you add macros to keep it?).

Anyhow you are adding your config to a file from the library not the files of your API

2nd case: Use MX to just generate the initial project. I like this one actually. Like the emptiest project, just config the workspace for me (well then why not just use a template?)

3rd case: Use the LL or register level programming. Apparently you lose portability? So... what's the point of this? Is the LL much more optimized than it's better than the SPL (so far I liked it more in terms of how you use it but that's arguing one of the least important points)

[AvaTar]

Posted on July 19, 2016 at 07:31

> 3rd case: Use the LL or register level programming.

 

Another point comes up here. There is no such LL library code for F7 MCUs yet. At least for F746, except of two small header files. ST obviously can't keep up providing Cube/library code for all the MCUs and variants.