I chose the STM32F405RGT6 because it solved more problems than it caused during the build — and that’s what you want in a late‑night prototype.

At first it was about raw capability: the Cortex‑M4 with FPU meant I could finally move Kalman/complementary filters and PID math from slow, hacked fixes into reliable, floating‑point code that ran smoothly in flight. That reduced tuning time and gave noticeably cleaner stabilization. The chip’s real‑time peripherals (multiple timers, PWM channels, DMA) made generating jitter‑free motor outputs and synchronized sensor sampling straightforward — crucial once I started testing DShot and tight control loops.

Practical constraints drove the choice too. The RGT6 package provided enough GPIO and flexible remapping so I could add OSD, VTX, extra UARTs and several SPI/I2C devices without endless board re-routes. When the OSD ended up on “slow” pins I could either lower an SPI clock in software or remap resources — options the STM32 toolchain and HAL made easy to try. On the hardware side, built‑in ADCs let me monitor battery voltage and shunt current without adding another MCU, which simplified the ESC integration and telemetry.

Development velocity mattered: CubeMX, STM32CubeIDE, a mature HAL and a huge community meant I spent less time on boilerplate and more time on flight logic, debugging motor sync issues, and improving ESC timing. The chip’s cost and availability kept the project realistic for small prototype runs (JLCPCB + small batches of boards).

In short — it was a pragmatic pick: enough compute for advanced control, the peripherals and I/O flexibility to integrate sensors and video/telemetry, and tooling that let me iterate fast. That combination turned late‑night sketches into a flying, extensible platform.