To add further confusion, consider rust. The flashing and debugging is easier, but the library ecosystem is a bit of a mess. On the plus side for learning, you will get comfortable with data sheets!
Btw, regarding HAL vs register-level programming... I think if you end up not using a HAL, you will end up writing a subset of one naturally as you create practical abstractions. Your call!
Note: There are general 3 types of manuals you will encounter for STM32:
- Reference Manual: Details on the MCU family broadly. Use this as your guide to programming and peripheral capabilities.
- User manual: Details on the specific MCU. Use this for pin mappings, and which peripherals are available on a given package
- Dev board datasheet: If using a dev board, this describes which pins are mapped to which external pins, onboard peripherals etc.
Don't get too overwhelmed with all the STM32 varieties. The family tree is sprawling, but peripherals are usually heavily conserved. With many exceptions to keep things interesting... A lot of the maker-oriented material points towards older ones; I would skip those, as working with the relatively newer ones tends to be a bit easier. (i.e. no reason to use an F3, F4, F0 etc on a new project)
This is good book to start learning. Don't worry too much about using HAL. You can dig deeper by implementing HAL functions yourself. The thing is if you are making a product, using a HAL is generally a good solution. Also keep datasheet of specific microcontroller nearby.
The best way for a beginner to learn X is to not spend time on finding the best way to learn X...
...and instead get to the hard work of learning X.
build my own Smart watch based on a Cortex M33 or M55. QSPI flash, I2C sensors, bluetooth, power management, some DSP
Just start now because actualizing that word salad is a muliti-year project. Alternatively, buy a smart watch instead and be done with it. "Some DSP" is at least a four year degree equivalent.
used a HAL library and it feels like cheating
Cheating how?
Good luck.