FPV drone flight controllers (FC) often have letter+number combinations in their name. For example: Mamba F405, RDQ Bardwell F7, or Matek H743. The bolded text refers to the microcontroller (MCU) used. The MCU is the computer, and input/output hub of the flight controller. The most popular MCU on FPV drones is the STM-32. The STM32 lineup is divided into several families, each indicated by a letter and number. The families are displayed below, with the ones commonly used by FCs highlighted in orange:
Note that none of the low-power families are used on FCs - they're generally slower, and are designed to do shorts bursts of activity bordered by long periods of sleep. You could build a FC with them, but no one does, since others are more suitable. Also note that none of the ones listed as Cortex-M0 are used - these are slow and lack features; they're designed for cheap, simple devices. The F1 and F2 families aren't used on new FCs since they're very old.
Each STM32 family contains many variants that have different combinations of features, physical sizes ("packages"), and amounts of memory. All STM32s use ARM Cortex-M processors, which are suitable for realtime tasks without a full operating system. They also include a large selection range of communication peripherals. This is perfect for flight-controllers, since they need to communicate with multiple sensors and systems, and do so with low latency.
The MCU is likely to be the largest component on your FC. It's a black square, and may or may not have visible pins extending from its edges. Example STM32H7 MCU, in a 144-pin Quad Flat Package:
Here's a breakdown of STM32 families, focusing on use in drone FCs:
The H7 family is, by far, the highest-performing one. It's also the most expensive, and is one of the newest. H7s operate at 480-550Mhz, and use a Cortex-M7 processor. Cortex-M7 processors do more operations at a given speed than Cortex-M4s, so if you're comparing speed in Mhz to a F4 or G4 for example, it's even faster than the numbers imply! H7s also include the largest selection of onboard peripherals (like communication buses like UART, SPI, I2C etc), and many features not used by FCs. Most H7 variants come in large physical sizes, but a few smaller sizes are available, including ones with pins under the MCU to save space. Highlights below for this and other sections are common; details depend on variant.
Highlights: 480-550Mhz Cortex-M7. 128k-2MB flash. 1MB RAM. Launched in 2017.
Bottom line: H7s have no drawbacks for use in FCs other than price. They're modern, fast, have lots of memory, and are available in small enough sizes. Does this mean you should always buy an H7 flight controller if not on a budget? No... See the Practical effect of MCU speed section below.
G4 is one of the newest STM32s. It has a large selection of peripherals, and advanced features like hardware filtering (most of which are not taken advantage of by FC firware yet), but is significantly slower than H7, and most variants have less memory. It's also cheaper. You can think of the G4 as a modern replacement for F4.
Highlights: 170Mhz Cortex-M4. 512k flash. 128k RAM. Launched in 2019.
Bottom line: G4 is a strong choice for new FCs. It's cheaper than H7, but slower. Not suitable for Ardupilot, due to its low amount of flash memory. Like H7, programming for G4 is easier due to flexible DMA access, and modern peripheral design. It includes a math accelerator that could be taken advantage of in the future.
F7s use a Cortex-M7, giving them high performance. It's pin-compatible with F4, and is designed to be a faster version of it.
Highlights: 216Mhz Cortex-M7. 512k-1MB flash. 256k-512k RAM. Launched in 2014.
Bottom line: F7s have strong performance, and are a solid choice when shopping for a FC. They've been replaced by H7, and are not suitable for use in new FC designs. They can be thought of as a faster F4.
F4 use a Cortex-M7, giving them high performance. They've been twice-superseded as a performance-oriented MCU, by F7, then H7. They feature older internal peripheral designs which are less flexible to code for, but this is transparent to end users. Note that the F411 variant is used on many FCs. It's significantly slower than other F4s, but is cheaper. The F401, used on some FCs, is the slowest of the lineup, at 84Mhz.
Highlights: 84-180Mhz Cortex-M4. 512k-1MB flash. 128k-256k RAM. Launched in 2011.
Bottom line: F4s work well on existing FCs, but are not suitable for new designs. Their end-of-life cycle will arrive sooner than other MCUs, at which point they'll no longer be produced.
You might also find F3 FCs available - these aren't a good choice due to low speed, low memory, and being superseded by newer variants like G4.
The choice of MCU in your flight controller is unlikely to make a noticeable difference in how your drone performs. Most flight controller firmware like Betaflight is I/O bound. This means that waiting for response from sensors and the ESC takes up comparatively more time than computations, like PID loops and filtering. Betaflight is able to perform all the computations it needs, without using all of the MCU's power. So, most of the beast-of-an-MCU that is the H7's processing power isn't taken advantage of. (At this time!)
You can think of a flight controller processor as event-driven: its default state is waiting for a signal. That signal might be readings being available from the IMU. Or a timer that periodically indicates it's time to adjust power to the motors. Or radio signals received from the controller. Once one of these happens, an interrupt tells the processor to perform computation. Typically for FCs, this computation is short, and the processor goes back to an idle state before the next event happens.
Higher control loop rates place more demand on the processor, since this is where most of the computation happens. Higher rates than 8kHz don't make sense currently, due to common IMUs updating at a maximum rate of 8kHz. Some support faster rates, but with higher amounts of noise that negate the advantage of a faster rate. With this in mind, you can't take advantage of a faster IMU by using a higher control rate.
Here are some examples of features used by Betaflight that can increase computation load. If enabling these on F401 or F411 (The slowest of the ones listed above), you may need to decrease the control rate to 2kHz. You should be able to retain an 8kHz rate with them enabled on other MCUs:
Unless the waiting time between events is all taken up by computations, or the computations get in each other's way, you can use any of the MCUs above without a noticeable difference in flight performance or capabilities.
Despite the STM32 line evolving over time, there's a strong degree of backwards compatibility. Coding for the various MCUs above is similar. For example, H7 and G4 code is almost identical, with some exceptions like clock setup and flash programming. F4 diverges from the newer ones, but is still similar in many areas. G4 and H7 have a distinct advantage for firmware coders and board designers in that their direct-memory-access (DMA) controller - used for things like IMU readings, motor signals, radio reception etc - is more flexible.
MCUs have varying amounts of flash storage, even within families. Note that this is flash inside the MCU itself; not external flash used as a "black box". For example, the STM32H7 can have between 128kb and 2Mb of flash storage, depending on the variant! Flash storage is where the firmware (eg Betaflight) is stored and run from.
Currently, you need at least 512k of flash to use Betaflight, and between 1M and 2M of flash to use Ardupilot, depending on features desired. Having more flash than is required by your firmware doesn't have any advantages; make sure the FC you buy has enough (MCU-internal) flash to support the firmware you plan to use.
This high requirement is due to these firmwares flashing most features on every FC, regardless of which ones are needed. For example, flash is taken up by code for multiple radio protocols, IMUs etc, even though you're likely to only use one of each. Currently, Betaflight builds that use Unified targets take up more space than those using Legacy targets.
Most MCUs are available in a variety of sizes and connection-types. Package size and pin count are poor indications of MCU speed and capabilities - they mainly indicates how many external connections are available. FCs usually use smaller variants to save board space and weight. 48-pin QFP and QFN ones are common. QFP has exposed pins at the edges; QFN has hidden connections under each edge. QFN is slightly smaller and has better thermal properties, given the same pin count.
Ball Grid Array (BGA) packages use a grid of connections under the whole FC - this allows them to have many more pins for a given size. It may be harder for FC producers to work with BGAs, since you can't visually inspect the connections. They have a noticeable practical advantage for FCs: They can fit 100 pins on a package smaller than typical 48-pin QFN or QFP. This gives the board designer more flexibility, and can be used to expose more communication lines - eg UART, SPI, I2C, or CAN.
Here are some example packages. Note that that the QFN-32 has too few pins for most FC uses. MCUs are available in much larger packages than the ones shown here, but these usually take up too much board space for use in FCs. Notice how the BGA package is comparatively small for its number of pins, and how the QFN-48 package takes up less space than the QFP-48 one.
When shopping for a flight controller, package size is related to how many communication lines are available. You might notice that FCs that have more of these lines available will use a larger MCU.
I hope this article clarifies the differences between the various MCU types used by flight controllers, and why you might care (or not) about which ones to look for. For now, it doesn't matter much, but you might see more sophisticated firmware in the future that takes advantage of more computation power and features.
