A consumer drone contains four small motors, each paired with a tiny square circuit board slightly larger than a thumbnail, plus a central flight controller board in the middle. The flight controller runs algorithms, processes camera feeds, connects to GPS—the computing tasks you’re familiar with. But the four small circuit boards—ESCs, electronic speed controllers—do something entirely different, and it is precisely this task that determines why you can’t put a Raspberry Pi there.
The physics of motor control is fundamentally simple, with no arcane mysteries: coils in the stator are energized to become electromagnets, attracting or repelling the permanent magnets on the rotor, and the rotor turns—this is the principle taught in middle school physics. The real trouble comes later: after the rotor rotates past a certain angle, you must immediately switch to energizing the next set of coils to keep pulling the rotor forward—otherwise the attractive force points in the wrong direction, and the rotor stops turning or even reverses. This act of “switching which set of coils gets energized” is called commutation.
Commutation as a principle is not complicated, but in practical control it imposes an extremely stringent requirement: it must be precise at every moment.
If it’s too early—energized before the magnetic fields align—the resulting force is angled, containing a component that drags the rotor backward, leading to inefficiency, overheating, and vibration. If too late, the rotor has already passed the optimal angle before energizing, wasting a stretch of rotation with little useful torque. If severely late, missing by an entire electrical cycle, the energized phase is completely wrong, producing reverse torque—equivalent to slamming the brakes on an accelerating car. Worse still, control degenerates into chaos, with random-direction forces hammering away, current spikes surging, potentially burning out the driver transistors outright.
So the precision of the commutation timing is never about performance optimization—it is the fundamental prerequisite for whether the motor can run at all.
Traditional brushed motors used an ingenious design: a segmented copper ring called a commutator is mounted on the rotor shaft, with two fixed carbon brushes pressing against it from the outside. As the rotor turns, the commutator segments in contact with the brushes naturally change, and the direction of current flow switches automatically. Commutation is handled entirely by mechanical structure. Give it two wires with voltage and it spins; reverse the polarity and it spins the other way; adjust PWM duty cycle and it changes speed. Control is trivially simple—one MOSFET and a basic driver circuit will do.
The trade-off is that carbon brushes and the commutator inevitably wear down, producing carbon dust and sparks; sparks generate electromagnetic interference; efficiency is relatively low and lifespan is limited; and precise position and torque control are out of reach. For toy cars and small fans, these trade-offs are perfectly acceptable, but for drones and robotic arms they fall far short.
BLDC and PMSM motors—the brushless motors now widely used in drones and robots—have no brushes and no commutators. The rotor is a permanent magnet and the stator has fixed coils. No mechanical structure handles commutation timing anymore—an electronic controller must read the rotor’s current position in real time, calculate which phases to energize, and precisely output three-phase PWM voltages through 6 power switch transistors (three half-bridges).
This means the controller must be trapped in an endless loop: read position → calculate commutation → update PWM output → read position → calculate commutation → update PWM output… And this loop must complete fully within every single PWM cycle. The typical PWM frequency for brushless motors ranges from 16 to 25 kHz, meaning every 40 to 62 microseconds, an entire round of sampling and computation must be finished.
If any round fails to complete within its time window, the next round can only reuse the previous round’s stale data. The rotor has moved to a new position, but the controller is still outputting voltages calculated from an outdated position—the commutation timing goes wrong instantly, and the physical consequences are the vibration, wasted rotation, and reverse torque described earlier.
Here a natural question arises: a Raspberry Pi is a 2.4GHz quad-core, while an STM32 is only a few-hundred-MHz single-core—purely in terms of raw compute, the Raspberry Pi is clearly far more powerful, so why isn’t it used in drones?
The answer lies in the operational nature of motor control: what it demands is not how fast the average computation runs, but that every single computation must complete within a strict deadline. These are two fundamentally different things.
A Raspberry Pi runs a full Linux system. Someone has measured its GPIO interrupt latency: the fastest is 9 to 11 microseconds, and there is noticeable jitter. When a graphical desktop is running in the background, USB is transmitting data, and the kernel scheduler is frantically switching threads, any sudden interruption can cause a single interrupt response latency to spike to tens or even hundreds of microseconds. Even with Linux’s so-called “real-time” mechanisms enabled (such as SCHED_FIFO, mlockall, or the PREEMPT_RT patch), the system remains fundamentally “best-effort”—the kernel still retains the scheduling abstraction layer, still gets preempted at any moment by driver interrupts, DMA operations, or memory management, with no mechanism that can guarantee it will never miss a deadline in the worst case.
Suppose a Linux system only needs 5 microseconds on average to complete one round of commutation calculation—but every so often it gets interrupted by some kernel event for 200 microseconds. During those 200 microseconds, that means 4 consecutive PWM cycles are all using stale commutation data. The motor is fed the wrong phase for 4 cycles straight, instantly producing current spikes and torque jitter—in severe cases even burning out the power transistors. The problem was never about how low the average latency is, but about that one burst of worst-case behavior.
ARM is actually not a single design, but is split into two product lines targeting entirely different scenarios: Cortex-A and Cortex-M.
Cortex-A is the “Application” core, equipped with an MMU (Memory Management Unit), supporting virtual memory, capable of running a full Linux system, with power consumption in the watt range—this is what powers Raspberry Pis, phones, and tablets. Its ultimate goal is maximizing general-purpose computing throughput. Cortex-M, on the other hand, is the “Microcontroller” core, without an MMU, not running Linux, with interrupt latency of mere tens to hundreds of nanoseconds, power consumption down to milliwatts, and extremely strong determinism. The STM32 is the quintessential representative of the Cortex-M product line.
The NVIC (Nested Vectored Interrupt Controller) on Cortex-M implements hardware-level preemption: once a higher-priority interrupt signal arrives, the CPU, after completing the current instruction, immediately jumps to the interrupt service routine—with no “kernel scheduling” software layer in between, no background process able to cut in line, response time entirely determined by hardware, and the latency nearly identical every single time. Even if tested ten thousand times, the jitter is negligible.
This is the real meaning of “determinism” in hard real-time—it doesn’t mean the absolute speed is high, but that the response is guaranteed stable enough, guaranteed never to miss an iteration.
The STM32’s peripheral architecture pushes this determinism to the extreme: timer overflow events can automatically trigger ADC sampling, and once ADC sampling completes, it can automatically trigger DMA to move the data into memory—all without any CPU software involvement at all—like a purely hardware-driven firing-pin assembly line, where one node’s trigger automatically pulls the next. The entire chain does not rely on any software scheduling and can never be interrupted by kernel events cutting in. In contrast, the Raspberry Pi’s GPIO, PWM, and ADC mostly require operating system drivers and software libraries to manipulate, with multiple layers of software abstraction in between—each layer a potential source of latency jitter.
In the STM32G4 series, specifically designed for motor control, the chip even integrates a CORDIC module for hardware-accelerated sin/cos/atan computation, along with an FMAC module dedicated to digital filtering, and its high-resolution timer can generate PWM waveforms with stepping precision of 2.1 nanoseconds. These are by no means general-purpose computing capabilities—they are purpose-built hardware circuits tailored specifically for the motor control pipeline.
Even in STM32’s higher-end product lines, such as the 480MHz H7 or the 800MHz N6, though their compute power approaches that of low-end application processors, they still lack an MMU, still don’t run Linux, and still operate in bare-metal or RTOS environments. This positioning of “ample compute power without any Linux baggage” lands precisely in the sweet spot that industrial real-time control demands most.
Having covered chip architecture to this point, the next natural question is: since controllers and motors are almost always used together, why not just integrate the controller directly into the motor?
In fact, such integrated solutions have long existed in industry. The 12V cooling fan on a computer motherboard, for instance, uses a BLDC motor paired with a simple control IC internally and spins automatically once powered; drone ESCs follow a similar approach, only needing commands from a single signal wire; the drive wheels of robot vacuums and the brushless motors in washing machines also adopt integrated designs. In the industrial automation domain, there are even more fully-featured “smart motors” or “integrated servos” such as Teknic ClearPath, Maxon EPOS, and Allen-Bradley Kinetix, which package the motor, encoder, FOC controller, and power driver circuitry all into a single enclosure, accepting commands over a serial bus—typical per-unit pricing ranges from $300 to $1500.
But in many high-performance or application-specific scenarios, integrated solutions exact a steep physical price.
The first cost is thermal dissipation: power MOSFETs generate intense heat during high-frequency switching, and the motor coils themselves produce significant copper and iron losses during operation—shoved together into a cramped sealed space, both are extremely difficult to cool, and the nearby capacitors and control ICs see their lifespan plunge off a cliff under prolonged high temperatures. The second cost is mechanical vibration: the sustained high-frequency vibration from a running motor readily causes solder joints on the control PCB to fatigue and crack under long-term stress. The third cost is electromagnetic interference: the high-voltage, high-current PWM switching noise from MOSFETs is a powerful source of interference, while the current signals sampled by the ADC are often in the millivolt range—tightly coupled together, the strong electromagnetic noise can easily drown out the faint current signals, leading the entire closed-loop control to distort and collapse. The fourth cost is flexibility: a motor of the same specification, if used respectively in a drone, a robotic arm joint, a CNC spindle, or an electric bicycle, demands entirely different control parameters and algorithmic strategies. An integrated solution, once its firmware is burned in or its hardware is fixed, requires scrapping the entire unit when switching applications. The fifth cost is repairability: the power electronic components on the circuit board are the parts most susceptible to overcurrent and overheating damage, while the motor’s copper windings themselves are extremely durable. With a separated design, you only need to replace the control board—a few dollars—but with an integrated solution, if a MOSFET burns out, you have to throw away the entire expensive motor.
Thus, the industry’s most classic and widely adopted approach remains the “three-tier separated architecture”: the bottom tier is the power layer, where 6 MOSFETs form a three-phase half-bridge responsible for switching high currents on the order of 50A; the middle tier is the driver layer, where gate drivers amplify the MCU’s 3.3V logic-level output to a drive voltage sufficient to rapidly switch the MOSFET gate; the top tier is the control layer, where the STM32 reads sensor currents and rotor position, executes commutation and FOC algorithms, and outputs PWM commands. The STM32 resides solely in the control layer—it is not the controller itself, but the controller’s core brain. Even inside those advanced integrated servos, there may well be an STM32 running—it’s just that what you’re buying is a “motor with a brain,” where the STM32 serves as the neurons, not the entire organ.
On the separated-controller path where the controller and motor remain independent, the key reason STM32 has become the mainstream choice in industry is that its peripheral architecture is purpose-built entirely for the motor control hardware pipeline. The ESP32, while also capable of simple motor control, was designed primarily for WiFi and BLE wireless connectivity, running FreeRTOS and a complex wireless protocol stack under the hood—its interrupt response determinism cannot compare with Cortex-M running bare-metal. The ESP32 is an excellent “wireless connectivity glue,” while the STM32 is a “Swiss Army knife” specialized for industrial control—their respective sweet spots are entirely different.
In actual development, if an off-the-shelf integrated servo perfectly matches the requirements, purchasing it directly is undoubtedly the most time-saving approach. However, the control parameters and algorithmic frameworks of integrated servos are often pre-packaged and locked down by the manufacturer, leaving users only with the exposed outer-layer interfaces. When you need to simultaneously implement precise torque control, position control, and compliant backdrivability for a custom robotic arm joint, you will find it nearly impossible to locate an off-the-shelf integrated solution that directly meets the requirements under a $300 budget. If you have deep understanding of the underlying principles and chip architecture, you can design and build a control system meeting specific physical constraints yourself based on an STM32 and discrete driver boards; otherwise, you can only passively wait for some other manufacturer to turn that specific need into a commercial product before you can buy it.
The essence of this capability gap is not about whether to reinvent the wheel, but about whether, when high-level abstractions fail to meet specific physical constraints, you hold in your hands the technical means to directly break down and bypass those limitations.
Look again at that small circuit board just larger than a thumbnail inside the drone. Within every 40-to-62-microsecond time window, it precisely runs through an entire round: read rotor position, calculate commutation timing, update 6 channels of PWM duty cycles—cycle after cycle, never missing a single round. The Raspberry Pi running Linux cannot do this because the operating system’s scheduler cannot provide a worst-case temporal guarantee; the microcontroller can do it because its hardware architecture guarantees that every response arrives on time, within the deadline imposed by the physical world. One is general-purpose computing that pursues average speed; the other is hard real-time response that guarantees every iteration is never too slow. In the harsh physical world of motor control, the chasm between these two determines whether the motor can hover steadily—or lose control amidst jitter.