Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit

* STM32H730/STM32H750 - Fix use of USE_LP_UART1 instead of USE_LPUART1.

* STM32H723 - Prepare for being able to build for using non-internal-flash
config storage.

* STM32H723 - Prepare for using non-default strings.

* STM32H723 - Disable 'use custom defaults' when using USE_EXST.

* STM32H723 - Disable CUSTOM_DEFAULTS_EXTENDED when EXST is used.

* OCTOSPI - Add initialisation code.

* Add support for RAM_CODE.

* STM32H730 - Add support for RAM_CODE via the .ram_code attribute.

* OCTOSPI - Proof-of-concept for disabling/enabling memory mapped mode on
a running system.

NOTE: The HAL libs are compiled into a memory mapped region, and this cannot be used for OctoSPI access when memory mapped mode is disabled.

* OCTOSPI - Drop HAL support after determining that it's not suitable for
the memory mapped flash use-case.

* OCTOSPI - Sometimes, when disabling memory map mode, the abort fails.
Handle this by disabling the OSPI peripheral first and re-enabling it

* SD/FLASH - Update comments regarding possible solutions to the catch-22
issue with SD/SPI/QUADSPI/OCTOSPI pin configurations.

* OCTOSPI - Use device instance directly.

* OCTOSPI - Prepare W25Q flash driver for octospi support.

* OCTOSPI - Add octospi flash detection.

Note: The method to detect flash chips is similar to the method used for
QUADSPI and as such the code was used as a base. However the initial
OCTOSPI implementation doesn't support the non-memory-mapped use-case so
the un-tested code is gated with `USE_OCTOSPI_EXPERIMENTAL`.

The key differences are:
* uses octospi api not quadspi api.
* flash chip clock speeds should not be changed for memory-mapped flash
chips, bootloader already set it correctly.
* only certain flash chips are capable of memory mapped support.

* W25Q - Ensure w25q128fv_readRegister returns 0 if the receive fails.

* OCTOSPI - Implement octoSpiTransmit1LINE, octoSpiReceive1LINE and

* OCTOSPI - Specify device from init.

* OCTOSPI - More fixes and work on init.

Current status is that memory mapped mode is disabled and flash chip is
detected, but w25q128fv_detect should not be calling w25q128fv_reset.

* FLASH - Add comment regarding wasted flash space on targets that only
use one bus type for the flash chip.

* FLASH - Split `detect` into `identify` and `configure`.

* OCTOSPI - Extract flashMemoryMappedModeEnable/Disable to separate

* FLASH - Reduce size of targets that don't support the use of multiple
flash interfaces.

* Single-flash-chip targets usually only support one type of io
* Without this, compiler warnings are generated in `flashSpiInit` for
targets that only use flash chip drivers that support quadspi or octospi
that don't even use SPI for flash.

* FLASH - Use MMFLASH_CODE/DATA to conditionally move code/data to RAM.

Only targets compiled to support memory mapped flash chips need the some
specific code in RAM.  Otherwise the code/data should be in the normal
linker section.

* FLASH - W25Q Prepare for memory mapped flash usage.

* Wait/Delay functions must work with interrupts disabled.
* Code used for reading/writing must run from RAM.

* OCTOSPI - Implement remaining required methods.

* OCTOSPI - Fixes for earlier code (not last commit).

* FLASH - W25Q update timeout values from Datasheet Rev L.

* FLASH - Prepare flash driver for use when memory mapped flash is

* System - Prepare microsISR for use when memory mapped flash is disabled.


* Flash - Fix incorrect gating on cli flash commands.

When compiling with USE_FLASH_CHIP and without USE_FLASHFS there were
compiler warnings.

* MMFLASH - Fix release-mode build.

* FLASH - Allow SPI pins to be reconfigured when using CONFIG_IN_MEMORY_MAPPED_FLASH.

MMFLASH only works via QuadSPI/OctoSPI peripherals.

* EXST - Disable the 2GB workaround which is now causing a different

The error we get with 'remove-section' enabled is:

"error in private header data: sorry, cannot handle this file".  The
cause of this new error in the objcopy codebase is an out of memory
condition, somehow the 2GB files and this error are related but the root
cause of both is still unknown.

* OCTOSPI - Add support for STM32H723.

* STM32H723 - Add linker scripts for EXST usage.

* NucleoH723ZG - Add build script to demonstrate OCTOSPI and Memory Mapped
flash support.

* FLASH - WUse the size in bits to set the size of the buffer.

* FLASH - Fix typo in W25N driver defines.

Was using W28N instead of W25N

* OCTOSPI - Fix missing semilcolon when compiling without

* OCTPSPI - Fix missing call to 'memoryMappedModeInit'.

* SPRacingH7RF - Add example build script to allow for testing prior to
unified target / cloud-build support.


Failed to load latest commit information.


Latest version Build License: GPL v3 Join us on Discord!

Betaflight is flight controller software (firmware) used to fly multi-rotor craft and fixed wing craft.

This fork differs from Baseflight and Cleanflight in that it focuses on flight performance, leading-edge feature additions, and wide target support.


Date Event
01-11-2022 Firmware 4.4 Feature freeze
29-01-2023 Firmware 4.4 Release


Requirements for the submission of new and updated targets

The following new requirements for pull requests adding new targets or modifying existing targets are put in place from now on:

  1. Read the hardware specification

  2. No new F3 based targets will be accepted;

  3. For any new target that is to be added, only a Unified Target config into needs to be submitted. See the instructions for how to create a Unified Target configuration. If there is no Unified Target for the MCU type of the new target (see instructions above), then a 'legacy' format target definition into src/main/target/ has to be submitted as well;

  4. For changes to existing targets, the change needs to be applied to the Unified Target config in If no Unified Target configuration for the target exists, a new Unified Target configuration will have to be created and submitted. If there is no Unified Target for the MCU type of the new target (see instructions above), then an update to the 'legacy' format target definition in src/main/target/ has to be submitted alongside the update to the Unified Target configuration.


Betaflight has the following features:

  • Multi-color RGB LED strip support (each LED can be a different color using variable length WS2811 Addressable RGB strips - use for Orientation Indicators, Low Battery Warning, Flight Mode Status, Initialization Troubleshooting, etc)
  • DShot (150, 300 and 600), Multishot, Oneshot (125 and 42) and Proshot1000 motor protocol support
  • Blackbox flight recorder logging (to onboard flash or external microSD card where equipped)
  • Support for targets that use the STM32 F4, G4, F7 and H7 processors
  • PWM, PPM, SPI, and Serial (SBus, SumH, SumD, Spektrum 1024/2048, XBus, etc) RX connection with failsafe detection
  • Multiple telemetry protocols (CRSF, FrSky, HoTT smart-port, MSP, etc)
  • RSSI via ADC - Uses ADC to read PWM RSSI signals, tested with FrSky D4R-II, X8R, X4R-SB, & XSR
  • OSD support & configuration without needing third-party OSD software/firmware/comm devices
  • OLED Displays - Display information on: Battery voltage/current/mAh, profile, rate profile, mode, version, sensors, etc
  • In-flight manual PID tuning and rate adjustment
  • PID and filter tuning using sliders
  • Rate profiles and in-flight selection of them
  • Configurable serial ports for Serial RX, Telemetry, ESC telemetry, MSP, GPS, OSD, Sonar, etc - Use most devices on any port, softserial included
  • VTX support for Unify Pro and IRC Tramp
  • and MUCH, MUCH more.

Installation & Documentation


Support and Developers Channel

There's a dedicated Discord server here:

We also have a Facebook Group. Join us to get a place to talk about Betaflight, ask configuration questions, or just hang out with fellow pilots.

Etiquette: Don't ask to ask and please wait around long enough for a reply - sometimes people are out flying, asleep or at work and can't answer immediately.

Configuration Tool

To configure Betaflight you should use the Betaflight-configurator GUI tool (Windows/OSX/Linux) which can be found here:


Contributions are welcome and encouraged. You can contribute in many ways:

  • implement a new feature in the firmware or in configurator (see below);
  • documentation updates and corrections;
  • How-To guides - received help? Help others!
  • bug reporting & fixes;
  • new feature ideas & suggestions;
  • provide a new translation for configurator, or help us maintain the existing ones (see below).

The best place to start is the Betaflight Discord (registration here). Next place is the github issue tracker:

Before creating new issues please check to see if there is an existing one, search first otherwise you waste people's time when they could be coding instead!

If you want to contribute to our efforts financially, please consider making a donation to us through PayPal.

If you want to contribute financially on an ongoing basis, you should consider becoming a patron for us on Patreon.


Contribution of bugfixes and new features is encouraged. Please be aware that we have a thorough review process for pull requests, and be prepared to explain what you want to achieve with your pull request. Before starting to write code, please read our development guidelines and coding style definition.

GitHub actions are used to run automatic builds


We want to make Betaflight accessible for pilots who are not fluent in English, and for this reason we are currently maintaining translations into 21 languages for Betaflight Configurator: Català, Dansk, Deutsch, Español, Euskera, Français, Galego, Hrvatski, Bahasa Indonesia, Italiano, 日本語, 한국어, Latviešu, Português, Português Brasileiro, polski, Русский язык, Svenska, 简体中文, 繁體中文. We have got a team of volunteer translators who do this work, but additional translators are always welcome to share the workload, and we are keen to add additional languages. If you would like to help us with translations, you have got the following options:

  • if you help by suggesting some updates or improvements to translations in a language you are familiar with, head to crowdin and add your suggested translations there;
  • if you would like to start working on the translation for a new language, or take on responsibility for proof-reading the translation for a language you are very familiar with, please head to the Betaflight Discord chat (registration here), and join the 'translation' channel - the people in there can help you to get a new language added, or set you up as a proof reader.

Hardware Issues

Betaflight does not manufacture or distribute their own hardware. While we are collaborating with and supported by a number of manufacturers, we do not do any kind of hardware support. If you encounter any hardware issues with your flight controller or another component, please contact the manufacturer or supplier of your hardware, or check RCGroups to see if others with the same problem have found a solution.

Betaflight Releases

Open Source / Contributors

Betaflight is software that is open source and is available free of charge without warranty to all users.

Betaflight is forked from Cleanflight, so thanks goes to all those whom have contributed to Cleanflight and its origins.

Origins for this fork (Thanks!):

  • Alexinparis (for MultiWii),
  • timecop (for Baseflight),
  • Dominic Clifton (for Cleanflight),
  • borisbstyle (for Betaflight), and
  • Sambas (for the original STM32F4 port).

The Betaflight Configurator is forked from Cleanflight Configurator and its origins.

Origins for Betaflight Configurator:

  • Dominic Clifton (for Cleanflight configurator), and
  • ctn (for the original Configurator).

Big thanks to current and past contributors:

  • Budden, Martin (martinbudden)
  • Bardwell, Joshua (joshuabardwell)
  • Blackman, Jason (blckmn)
  • ctzsnooze
  • Höglund, Anders (andershoglund)
  • Ledvina, Petr (ledvinap) - IO code awesomeness!
  • kc10kevin
  • Keeble, Gary (MadmanK)
  • Keller, Michael (mikeller) - Configurator brilliance
  • Kravcov, Albert (skaman82) - Configurator brilliance
  • MJ666
  • Nathan (nathantsoi)
  • ravnav
  • sambas - bringing us the F4
  • savaga
  • Stålheim, Anton (KiteAnton)

And many many others who haven't been mentioned....