I beg to differ, Andrew. That saying is just a saying, there's no more truth in it just because it sounds good.
Here's my view:
You may go the path of clicking in the code in any configurator, again provided as convenience/lock by mcu manufacturers, and then trying to build upon that. You may use various "peripheral libraries" and "hardware abstraction layers" out there. And you may also use frameworks such as Arduino, which isolates you from the "nasty details of hardware".
All these methods provide a relatively easy and painless way to accomplish certain groups of tasks. However, they inevitably implement only a limited fraction of the mcu capabilities and cater for a given group of applications, covering whatever their creators deemed to be the "usual cases". As soon as anything out-of-ordinary is to be achieved, these tools tend to become more of an obstacle than help, and usually time/effort for learning the "nasty details" spared at the start are spent usually in a more painful way, to learn not only the underlying details, but also to learn the various couplings between those details and the libraries/frameworks used.
In other words, once you start with Cube/HAL, you probably won't be able to get rid of it, ever; and unless you stick to the "usual" applications for which Cube/HAL caters, you'll regret that decision one day. Hereby, you've been warned.
One thing is true, though: ST refuses to provide normal register-based examples, which makes this path initially unnecessarily harder.
OTOH, I don't see any merit in writing a concurrent "library", if you are a normal user. Just use whatever you need, and then later recycle what you've already written, as appropriate.
JW
