Could it be happening? Standard Peripheral Library (SPL) for all STM32 mcu's

[AlfBaz]

Somebody on ST's forum compiled a short wish list for 2018.
https://community.st.com/thread/45439-2018-wish-list

Some of the points sound a bit fanciful but number one
"SPL (Standard Peripheral Libraries) For all your MCU's (F7 and H7). Each discovery board should have examples in SPL"

To which an ST moderator replied
"Thanks for the initiative
 You already anticipated out actions"

Obviously the reply was not to any point in the wish list particularly, but the above SPL support request certainly looks the easiest to grant

[rhb]

Examples for each board is both the easiest for ST and the highest value as it makes it easier to design in their products.  I'm greatly enjoying watching all the MCU OEMs compete for adoption.  We should all thank the Arduino developers for putting the fear of lost sales in the OEMs.

[alexyzhov]

Personally speaking, SPL is much better than the HAL.
Over packaging makes me tired to understand the source code. I hate HAL, and APIs like VL53L0x.

[ajb]

I don't even need an SPL, but better explanations of how peripherals work with examples using registers would be really nice.  Really, even one of those two would be a big frustration saver.

I don't really trust ST to make a graceful transition to Yet Another Framework.  As it is, their libraries and documentation are badly fragmented between different versions of Cube/HAL, and at least initially making something else the main focus is only going to make that worse.  I don't believe they have the long term focus to finish it before starting on Yet Another Framework MX. 

[jnz]

He listed 5 things, they said you anticipated our actions... Maybe I'm just being a programmer here but that doesn't mean ALL 5 things.

I mean... they have HAL, Cube to deploy it, and LL drivers for people that complained about HAL. Does anyone REALLY think they're going to walk away from all of that? I'm skeptical.

[technix]

I don't even need an SPL, but better explanations of how peripherals work with examples using registers would be really nice.  Really, even one of those two would be a big frustration saver.

I don't really trust ST to make a graceful transition to Yet Another Framework.  As it is, their libraries and documentation are badly fragmented between different versions of Cube/HAL, and at least initially making something else the main focus is only going to make that worse.  I don't believe they have the long term focus to finish it before starting on Yet Another Framework MX.

I second that. There have been a few times that I got bitten in the ass by the HAL and SPL. (Remember the time I asked about USB on STM32F042? That was because of the sheer bloat of HAL.)

Yet there are a lot of HAL and LL fanboys out there in China that enforces that all STM32 code must be written using HAL. Having squabbles with them online is infuriating and tiring. They turn blind eyes to my solid demonstrations of the sheer bloat of HAL, ignore the less than 20 line diff of various drivers across different chips claiming porting drivers are hard and time consuming, and shove every “benefit” listed on ST’s marketing slides down my throat. (Why does this also sound like my opinion on the PSoC holy wall of text?)

[andyturk]

I think ST does a better job at documentation than some other Cortex-M vendors I've worked with. Their datasheets aren't perfect, but they do often have some implementation detail that helps write drivers that work. I've also been looking at the LL "library" implementation... it's handy when ST moves a flag bit between registers for a new product family. The LL API doesn't do much, so it's relatively easy to see what's going on.

For more in-depth learnings, I pull out the ChibiOS source. I think Giovanni (ChibiOS founder) used to work at ST and knows where the bodies are buried. He writes very clear code too.

[AlfBaz]

I just wish they would stop moving on to the new thing while old thing is still broken.

I had a serious shot at cubemx hal and it is fairly impressive until you start reviewing the code it generates. Do I invest time studying this abstraction that may or may not exist in a year's time I do I just hit the metal and study the datasheet. Without a doubt the latter is more sustainable

The SPL code is all over the place, just finding the latest version is difficult. I found newer revisions packaged into some appnote's download than what's available from the spl download page.
Even here, when you dig down, you find abstraction on the already abstracted. Do we really need #defines of #defines of #defines? or calling a function that simply calls another function that simply calls another function that simply pokes the original parameter value into a register (and usually in the most contrived manner conceivable)

Thanks to a post on another thread by Andy, I decided to look into STs CMSIS SVD files. They haven't even got them right. They flag the MMU and FPU as not present on a chip that definitely has both. Chip revision number is incorrect and bitwidths of bitfields greater than one are defined individually, where's the use case for that?

Create a rock solid base and build on that please

[AlfBaz]

He listed 5 things, they said you anticipated our actions... Maybe I'm just being a programmer here but that doesn't mean ALL 5 things.

I mean... they have HAL, Cube to deploy it, and LL drivers for people that complained about HAL. Does anyone REALLY think they're going to walk away from all of that? I'm skeptical.

He did indeed list 5 things but the main thrust of the post is about the SPL as emphasized by the umpteen  "please" at the end of it.
There's no reason why they couldn't do both and I for one would welcome it BUT, if they have limited resources I would prefer they finish implementing LL in cube before assigning labour to anything else.
If done properly LL could make the SPL obsolete but I suspect that wont be the case

[Vasi]

SPL won't gonna happen! There is LL that is quite good and they started to add support for it in the CubeMX. The problem is, when LL will become a threat to HAL, they will stop adding support for it. I wrote an application in HAL that had 8K code size and it downsized to 2K when I ported that to LL https://nucleobytes.blogspot.ro/2017/09/alea-iacta-est.html so for me, here is where my adventure in HAL ends for good.

At 4.23.0 version, CubeMX still offers a "Makefile" project generation, independent of any IDE, that will easily allow you to add your own libraries. But at this version they broke it intentionally, adding garbage in the Makefile to scare the beginners https://community.st.com/thread/43473-undefined-reference-to-llrccgetsystemclocksfreq . I still continued to develop applications and libraries this way, archived them and posted in that thread, but after a weekend of moderation, the forum got "crashed" Monday. When it went back, my post was gone. So I'm pretty sure that they don't want this way of doing things to be spread among beginners as it will mean pretty much the end of HAL.

So they will continue pushing HAL as they recently acquired TrueSTUDIO and it will be offered for free in the professional form. Of course, I still have to wait to see the next version of CubeMX and the way things are progressing to make any statements, but this is what I experienced with them 'till now.

[technix]

SPL won't gonna happen! There is LL that is quite good and they started to add support for it in the CubeMX. The problem is, when LL will become a threat to HAL, they will stop adding support for it. I wrote an application in HAL that had 8K code size and it downsized to 2K when I ported that to LL so for me, here is where my adventure in HAL ends for good.

At 4.23.0 version, CubeMX still offers a "Makefile" project generation, independent of any IDE, that will easily allow you to add your own libraries. But at this version they broke it intentionally, adding garbage in the Makefile to scare the beginners https://community.st.com/thread/43473-undefined-reference-to-llrccgetsystemclocksfreq . I still continued to develop applications and libraries this way, archived them and posted in that thread, but after a weekend of moderation, the forum got "crashed" Monday. When it went back, my post was gone. So I'm pretty sure that they don't want this way of doing things to be spread among beginners as it will mean pretty much the end of HAL.

So they will continue pushing HAL as they recently acquired TrueSTUDIO and it will be offered for free in the professional form. Of course, I still have to wait to see the next version of CubeMX and the way things are progressing to make any statements, but this is what I experienced with them 'till now.

No wonder why there is so many HAL fanboys, especially on the Chinese STM32 forums.