Thread necromancy, but relevant (I hope).
I bit the bullet a few months ago, and did a few new projects from scratch using CubeMX and the new HAL.
At first, it's quite a pleasant experience actually. Using CubeMX to figure out the perfect STM chip for the project is very nice, and pin-selection for the various AFs is very pleasant. Gone is the days of using the datasheets for figuring out pin-assignments.
The ease-of-use here even lead to slightly better PCB layouts, as I could play around a bit with the pin-assignments during layouting to get it more efficient.
As for the HAL, it's a learning-curve, and once you figure out that the actual documentation is at the top of the .c files (not .h), it's pretty straight-forward.
HOWEVER... In my opinion, the HAL is far from production ready. I keep running into missing functionality when I go beyond the very basic stuff, and downright nasty bugs.
The two very obvious examples that comes to mind is implementing an i2c slave (as in, the stm32 acts as a slave). To my surprise, the HAL doesn't have a mechanism to do to this, nor to manually do i2c re-starts. Had to bang the registers directly for that.
The other example is implementing an multi-channel ADC with DMA transfers. This is fairly simple to do with the HAL, especially after CubeMX generated all the setup code for it. And, it actually works. Problem is... It only works _once_. If you reset the cpu-core (as in, hot reboot), the HAL doesn't reset/initialize the ADCs correctly, and it stops working. Power-cycle, and it works again. Once..
Power-management is also a bit of a hassle using the HAL.
Now, while I still occasionally use the HAL for quick and simple tests and proof-of-concepts, everything that goes beyond that uses StdPeriph, at least in my shop (and by extension, my workplace, as I get to make those decisions there.
).
However, I still use CubeMX all the time. Just not the code it spits out.
/J