Could it be happening? Standard Peripheral Library (SPL) for all STM32 mcu's - Page 1
Forum section: electronics / general

author: AlfBaz
author_rank: Super Contributor
timestamp: December 14, 2017, 11:56:29 pm
content: Somebody on ST's forum compiled a short wish list for 2018.https://community.st.com/thread/45439-2018-wish-listSome 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 initiativeYou 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

author: rhb
author_rank: Super Contributor
timestamp: December 15, 2017, 02:17:51 am
content: 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.

author: alexyzhov
author_rank: Newbie
timestamp: December 15, 2017, 03:08:34 am
content: 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.

author: ajb
author_rank: Super Contributor
timestamp: December 15, 2017, 04:09:08 pm
content: 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.

author: jnz
author_rank: Frequent Contributor
timestamp: December 15, 2017, 07:20:55 pm
content: 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.

author: technix
author_rank: Super Contributor
timestamp: December 15, 2017, 07:35:06 pm
content: Quote from: ajb on December 15, 2017, 04:09:08 pmI 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?)

author: andyturk
author_rank: Frequent Contributor
timestamp: December 15, 2017, 09:00:54 pm
content: 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: December 15, 2017, 11:21:56 pm
content: 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 sustainableThe 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

author: AlfBaz
author_rank: Super Contributor
timestamp: December 15, 2017, 11:33:12 pm
content: Quote from: jnz on December 15, 2017, 07:20:55 pmHe 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

author: Vasi
author_rank: Regular Contributor
timestamp: December 18, 2017, 03:01:34 am
content: 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 LLhttps://nucleobytes.blogspot.ro/2017/09/alea-iacta-est.htmlso 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 beginnershttps://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.

author: technix
author_rank: Super Contributor
timestamp: December 18, 2017, 11:43:55 am
content: Quote from: Vasi on December 18, 2017, 03:01:34 amNo wonder why there is so many HAL fanboys, especially on the Chinese STM32 forums.