I'm looking for a quadcopter microcontroller to use as a flight controller and am comparing a couple of different ones. Went on this website to see what current boards are using: http://www.rcdronegood.com/flight-controller-board-comparison/

However, I'm looking at the ESP32 microcontroller as well which operates at 240 MHz and performs at up to 600DMIPS. For comparison, the STM32-F3 chip only operates at a clock speed of 72MHz and gets 1.25DMIPS/MHz, but apparently works pretty well as a flight controller. But if the ESP32 has better specs why wouldn't we all just use the ESP32? Am I missing something or comparing wrong things? I guess the real question I have is how can I really compare microcontrollers to make sure I'm using the right one for my application?

  • \$\begingroup\$ Comparing just the MCUs is pointless. You compare the MCU/sensors/software as a package. The software implementation on any given MCU may vary widely, so you need to compare the overall spec of the IMU rather than just MCU speed. \$\endgroup\$ Mar 25, 2018 at 17:01
  • \$\begingroup\$ It is 2023 and here is UPDATE: There are FC for ESP32 on github now. They are not perfect and people do not invest much time in ESP32 for the following reason: ESP32 lacks serial ports comparing to STM32F405 \$\endgroup\$
    – Artem
    Feb 12, 2023 at 22:19

3 Answers 3


Your general question is of course too broad to be a fit here, but the specific question of selecting a processor for a quadcopter can be addressed.

Mostly what is missing is awareness of the actual task.

A little historical perspective would show that this was a problem routinely solved with small 8-bit flash-based MCU's like the STM8 and ATmega series. Talking to a packetized 2.4 GHz radio, reading a MEMS sensor or two, damping roll, and optionally restoring "level" are really not computationally demanding or high memory resource tasks - even if you add extras like a flip-button.

However, fairly quickly, most commercial toys and open source projects have moved on from 8 bit processors to 32 bit ones, typically ARM Cortex M0 or M3 devices. This to some degree reflects an industry trend overall - these parts are very inexpensive, and today you often pay primarily for the flash and RAM sizes, not the capability of the core. Most budget toys are flying with STM32's or work-alike GigaDevices parts, a few have Nuvoton, and then there's a whole category using combined Radio/MCU parts undocumented in the west.

In terms of considering the ESP32, this is probably not what you want, for several reasons:

  • It is not a unified flash-based MCU, rather it (usually) requires an external SPI flash, which is one more part you have to source, route, and one more failure point

  • Neither WiFi nor BLE is really suitable for remote-commanded flight. For this you want something that at the air level does not involve sessions and does not involve retries. Lost packets are a certainty, but the proper cure is to just follow them with good up-to-date packets, not to keep trying to send ones containing increasingly stale commands. While there are some options to run these radios in more raw modes, that's not an area that has received much exploration.

  • The documentation and available knowledge still has many unexplored dark corners - especially but not only with regard to the radios.

  • You will be pretty much on your own software wise. Even if your goal is to write a fully custom firmware, being able to quickly port an existing one to your pin mapping lets you validate the circuitry and airframe so that your software work can be just about algorithms and software, rather than facing all the problems at once.

Some features that are typically desired in an MCU are:

  • Fully self contained flash and RAM requiring minimal support components. Having multiple memory sizes in the same package lets you have high memory development units with extra output, and cheaper low memory production ones.

  • Hardware I2C and SPI for talking to sensors and radio (and a UART for debug output is very handy)

  • At least four hardware PWM channels for directly driving brushed motor FETs or providing legacy style servo signals to external speed controllers. (Some modern ESC's use complex signaling which would benefit from DMA-backed interfaces, identifying the proper hardware channels for those is an art itself, but a beginner shouldn't be messing with aircraft large and therefore hazardous enough to use those)

  • Ability to operate at 2.8 volts or less, to allow selecting an LDO voltage headroom when operating from a single cell which may substantially dip under load when flying aggressively late in the discharge cycle.

Before doing original work in this field, you'd be wise to pick up one of the current generation of 15-18 gram $15-20 ducted prop aircraft running on an STM32F0 with labelled SWD port, and an available open source alternative firmware. That gives you plenty of opportunity to learn without the lengthy effort of designing and assembling a tiny board and airframe - and you can of course swap out parts, putting the stock controller on a custom airframe or a custom PCB on the stock airframe. It's also rather helpful to have something tiny enough that you can unclip the SWD leads from and fly right off the lab bench, without having to invest all the time in hauling everything outdoors.

  • \$\begingroup\$ Great answer, lot of nuances I didn't know about the ESP and other MCUs. I will definitely take your suggestion to heart \$\endgroup\$
    – squeegene
    Mar 26, 2018 at 11:23
  • 1
    \$\begingroup\$ You can buy esp32's with flash in a module. I've used hundreds of these modules. You don't need to use wifi/bt you can use espnow. Which I do all the time for low latency transmission. And it has pretty everything you want but 2.8v drop but that's not a real barrier when doing a custom project like this. \$\endgroup\$
    – physiii
    Jan 14, 2021 at 1:28
  • \$\begingroup\$ so.. ESP's have flash and WIFI is essentially OSI layer 0, you can still UDP (OSI layer 4) configured to not retransmit, not ack giving you a "twitch" network (I admit 2.4ghz+ wifi will not have the same range as ISM bands or similar LoRa), they can also be programmed in C (requires flash) or OTA using Lua/Python where Lua/Py are generally preferred within the ESP crowd. that said-the reason ESPs are not widely used is lack of experience, which this post touches on wonderfully. the history of drone development has been entrenched with STMs, and the advice here is solid. \$\endgroup\$
    – wilson0x4d
    Mar 23, 2022 at 21:28
  • \$\begingroup\$ " current generation of 15-18 gram $15-20 ducted prop aircraft" - here in europe i don't think that's realistic, you won't find one for under a hundred bucks \$\endgroup\$
    – jmullee
    Mar 10, 2023 at 15:59

But if the ESP32 has better specs why wouldn't we all just use the ESP32? Besides speed, what other specs are you looking at? Going on only what you mentioned, here are some thoughts on MCU speed.

The faster you clock a device, the higher the drain on the battery will be. If you determine your control response time, you can eventually back that into required MCU speed. This might mean that your 240MHz-capable MCU needs to run at only 100MHz. Or, you could take the Eddie Muntz Approach and apply it to processor speed to come up with the minimum required clock frequency.

Some MCU architectures are better suited than others for certain tasks. Translated, this could mean a higher cpu speed is required to obtain the same overall performance that you'd get from a slower operating MCU based on an architecture that's better suited to your application.

There are many characteristics that must be considered when selecting an MCU besides just its clock speed. Using what you know has been proven to work can save you a lot of R&D.


low power consumption is very important in the choice...

EFM32 MCUs from SiLabs are more suited for ultra-low power applications and especially battery operated systems like quadcopter controllers.

  • 2
    \$\begingroup\$ On the contrary, with the flight motors typically draining the battery in a handful of minutes and the RF circuitry pretty much constantly active, the difference between the power consumption of an ordinary MCU and a low power one is effectively irrelevant. \$\endgroup\$ Nov 2, 2018 at 19:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.