How do I actually get going with STM32 as a beginner?

The short answer is that you need both, but you should start with a dev board. Don't get stuck trying to master C or how microprocessors function entirely on paper first, or you'll just get overwhelmed. You've got basic C skills, and that's enough to get started, especially since the initial projects are just about configuration, not deep algorithmic design. Getting hands on hardware immediatly is the only way to understand why things work the way they do in the real world.

For hardware, ditch the ultra-cheap boards; they're often unreliable and tricky to debug. Spend a bit more and get an official Nucleo or Discovery board. These are designed specifically for learning, and they come with the neccesary tools and support. They integrate the debugging connection and have enough peripherals so you can actually do something useful right away, like talking to a computer via UART. Load up the vendor's development enviornment, like CubeIDE, and just run one of their examples. You won't break it, and that's how you learn the toolchain first.

Once you have the board and the IDE running, start with the simplest projects: blink an LED, then make it blink at diferent rates, then get the board to communicate simple text over the serial port. Use those small wins to understand the process flow: hardware setup -> configuring clocks and peripherals in the tool -> writing minimal code -> seeing the result. This practical loop is how you bridge the gap between textbook theory and actual embedded engineering. If you feel like you're missing a foundational concept, don't try to read a whole book on microcontrollers. Instead, read documentation on the specific components you are using. For example, look up the datasheet for the GPIO registers on your specific chip once you reach the point where the high-level tools stop making sense. That's when you transition from using the shortcuts to understanding the mechanism underneath. Most people find things click after a few weeks of consistent, small projects, not after months of planning.

One thing I'd add is pick a tiny project goal early, not just random tutorial hopping. When I started I bounced between videos for weeks and retained nothing. Then I set myself 'make the board log temperature to my laptop' and suddenly every problem had a purpose. Also don't blow money on a big pile of sensors and modules upfront, you'll barely use half of it in the first couple months. A breadboard, some jumpers and a few LEDs will keep you busy longer than you'd think.

I totally agree with the advice about skipping the pure theory phase and jumping onto a proper Nucleo board. Getting the hardware running first is crucial. When I started using CubeIDE, I figured configuring the clocks would be simple, but the first time I tried to get a basic GPIO peripheral working, I spent a whole day just fighting the clock setup and getting the correct linker script to fire up. It taught me immediately that the toolchain is almost as big a learning curve as the chip itself. It's those tiny, fiddly configuration steps that really make you understand why embedded code is different from standard computer programming!

When I finally got past the blinking LED, I ran into a wall trying to get a specific timer working. CubeIDE just kept giving me errors, even after I tried every setting in the graphical tool. I wasted about three hours before I realized I needed to actually look at the reference manual for that specific peripheral. It wasn't about the high-level code, it was about understanding the specific clock prescaler setting the tool was hiding.

That’s when it started to click—realizing the tool is just a helpful shortcut, but you have to know what it's shortcutting around. If you hit a block that the IDE just can't fix, grab the chip documentation; it saves tons of frustration.

One habit that saved me alot of time later on was writing down every change I made to a project, even just a text file per session with what I toggled in the configuration tool and what the symptom was. Embedded debugging is mostly about narrowing down where the fault lives, and after a two week break you will genuinely not remember whether that peripheral worked before or after you touched the clock settings. It feels pedantic at first but it turns a vague 'it stopped working' into a checkable sequence, which is most of the battle when you are learning alone without anyone to ask.