ST seem to have created a light weight API in addition to the HAL ....

STM32Cube low-layer (LL) APIs, a light-weight, optimized, expert-oriented set of APIs designed for both performance and runtime efficiency, are now fully deployed across all existing STM32 series. Usable in standalone or in parallel with STM32Cube HALs (with a few restrictions), they also offer an easy migration path from the STM32 standard peripheral libraries, and it has never been easier to migrate old SPL projects into the Cube environment

really quick skim, they show how to merge section from ll example and its higher equivalent over to a different board.
i didn't see much else, single led blink, then a tripe led blinky.
there is a how to port ll drivers/code video, it did download & i may get a chance to skim that one.
the st play list has 5 or 6 videos from assorted event fairs, a number of intros and a few examples
the link i get from different videos is the same though, something ccl & youtube-dl don't like

I never understood their love for constantly investing in different libraries.

I'm a big fan of spl. It is reasonably structured, with workable documentation and a high degree of similarity from family to family. The bad rep they got on spl in my view is mostly from people who don't know how modern day mcu coding is all about. Those people wouldn't have been big users of those chips.

Instead of refining spl, they abandoned it and moved to Hal, only to see commercial customers pausing at this whole thing. Spl is very easy to be incorporated into the work flow of a large corporation - often done with a middle layer . Hal on the other hand is more appropriate for a one off project as it's incorporation is much harder.

The backlash on Hal I think prompted LL.

The issue this whole thing creates is that people don't want to invest in those libraries knowing St propensity to switch. Each switch means negating of your middleware and your investment.

Personally I have developed nothing under Hal and will unlikely develop anything under LL, unless I see a reasonable runway for LL.

i forced CubeMX to recheck for updates, so off it went and downloaded 300+MB.
to complete the process you now need to re-run CubeMX with administrator rights,
ok linux box, xhost +, su +export DISPLAY=:0.0, and ./CubeMX
off it goes again 300+MB, bla bla
back to me again
new libraries to be installed, off it went for a couple more files, these are 600+MB

now that brought to mind, when did linux distributions go past 700+??MB single cdrom ?
not a redhat, mandrake or debian with umteen extra ones for the software, ok so everything absolutely needed was on
a single or the first cdrom.

i remember downloading single a cdrom at 57.6 kps, i used have something running to bring up the link each time my provider killed the session, stopping before i went off to work at 6am, me restarting the link at 6pm when the no charge time started.
a dvd took most of the week