Betaflight Flight Controller Manufacturer Design Guidelines

Version Change Register

Version #	Revision Date	Changes, Reasons, and Notes
Draft 0.1	14 May 2022	Initial Draft Format
Draft 0.2	04 June 2022	Revise format to Final Format
Draft 0.3	12 June 2022	Update Visual Media and Tables
Draft 0.4	21 October 2022	Update format, add information
Draft 0.5	24 October 2022	Add additional information
Draft 0.6	06 November 2022	Add cloud build information
Draft 0.7	17 November 2022	Remove off-board hardware defines
Draft 0.8	01 January 2023	Update Baro and CC2500
Draft 0.9	14 January 2023	Add FC LEDs
Draft 1.0	26 January 2023	Add Signal Rules
Draft 1.1	10 December 2023	Add LSM6DSV16X and LPS22DF
Draft 1.2	13 January 2024	Add Mag and Baro hardware note
Draft 1.3	23 October 2024	Update MCU recommendations
Draft 1.4	06 November 2024	Add LED pin resource warning
Draft 1.5	13 January 2025	Update ADC/gyro recommendations
Draft 1.6	18 February 2025	Add W25N02K flash define
Draft 1.7	27 March 2025	Update FC review policy
Draft 1.8	01 April 2025	Update I2C Device Info
Draft 1.9	12 September 2025	Update motor requirements
Draft 2.0	12 November 2025	GPIO usage clarifications
Draft 2.1	29 March 2026	Update sensors
Draft 2.2	05 July 2026	Sync sensor defines with firmware master; add LSM6DSK320X
Draft 2.3	12 August 2026	Add BMI270 shared-footprint alignment define; add supported MCU platform table
Version 3.0	28 September 2026	Align with the Hardware Policy: guidance is Preferred, Not accepted for new designs, Not recommended or Warned against; manufacturers remain free to distribute their own firmware

Thank you for considering or continuing your development of Betaflight capable flight control hardware.

info

These guidelines sit under the Betaflight Hardware Policy: we fix Betaflight, manufacturers support their hardware, and pilots own their builds. Every board in the firmware flasher is Betaflight Supported, Manufacturer supported or Legacy, and the guidance in this document is Preferred, Not accepted for new designs, Not recommended (accepted only in specific circumstances) or Warned against (advice that a config review cannot enforce). The cloud build carries designs the Betaflight team has reviewed and accepted, see Cloud Build Acceptance. A manufacturer remains free to distribute their own firmware for any design, see Two Routes to Pilots. This applies to new designs from 28 September 2026; existing boards keep their status.

Betaflight is an open source project that is free to use and does not incur a license cost, however for the most successful release of a new flight controller or complete ready-to-fly product that is using Betaflight, it remains immensely beneficial to provide representative production samples or pre-production testing units to the Betaflight development team for testing and development feedback.

For a board to be Betaflight Supported, hardware samples representative of the final configuration must be provided to designated members of the Betaflight development team when requested. It is strongly recommended that samples of development hardware or production-representative examples are evaluated positively before accepting pre-orders or releasing products. Many of the same benefits can be provided for inclusive hardware packages, including flight control stacks, or ready-to-fly craft.

Sharing schematics/layouts with the reviewers will also be beneficial and improve the quality of the review.

This provides the Betaflight team with an opportunity to ensure that the hardware and firmware behave 100% as expected in the representative configuration, as well as support verification of custom defaults required for firmware operation. It also lets the team reproduce firmware bugs that a manufacturer raises on behalf of its customers, while support for the hardware itself stays with the manufacturer.

Additional benefits are also present in the form of allowing experienced active pilots with backgrounds in engineering of these systems to assist with aspects of the development process particularly in respect to real world use the products will be subjected to.

Note: Manufacturers may use the same target for multiple flight controller designs; however, each new flight controller must go through the review process to be Betaflight Supported, regardless of whether it uses an existing target.

Finally, boards that follow our best-practice guidance and have been reviewed by our development team are shown as Betaflight Supported in the firmware flasher of the Betaflight App, so pilots can find them when choosing hardware. This covers flight controllers, including AIOs and the flight controllers supplied in stacks and ready-to-fly craft. This strategy is designed to help manufacturers optimise their hardware, direct pilots to well-designed hardware, and reduce support requests to the Betaflight team, who serve a user base of over a hundred thousand users.

1 Important Terms and Conditions

1.1 Intent

The goal of these guidelines for Betaflight Flight Controller hardware and firmware targets, and of Betaflight Supported status, is to ensure that hardware design supports correct operation of Betaflight features and supports an improved user experience for ‘connecting’, flashing, programming, and flying.

The cutting edge flight performance achieved by Betaflight relies on proper hardware design, microcontroller resource allocation, and the ability of end-users to correctly configure the software with Betaflight.

Achieving state of the art performance requires minimizing latency in craft response to perturbations and command inputs, efficient filtering to remove oscillations from flight control calculations, and leveraging the capabilities of peripheral components to enhance the flight experience. For example, features such as advanced RPM filtering, RPM Dynamic Idle and Multi-Dynamic Notch rely on achieving microsecond scale timing jitter for best performance while simultaneously communicating with electronic speed controllers using bidirectional DShot, determining craft attitude and calculating optimal mixer outputs, as well as operating the myriad of desired user peripherals. This symphony of delicately scheduled operations can be achieved reliably with proper flight controller design.

1.2 Important Terms and Glossary

Term	Definition	Reference
ADC	Analog to Digital Converter
BEC	Battery Elimination Circuit	Electronic voltage regulator circuit that provides a specified voltage to a single output power rail
Bidirectional DSHOT	Two-Way DSHOT communication protocol to enable Electronic Speed Controller telemetry to be sent back to the flight controller	wiki
Bit Bang	Bit-banging refers to any instance of utilizing GPIO functionality to digitally create signals in place of dedicated hardware. This can alleviate some specific data buffer timing requirements
DSHOT	Digital Shot Communication Protocol used for Flight Controller to Electronic Speed Controller	wiki
ESC	Electronic Speed Controller	https://us.aspina-group.com/en/learning-zone/columns/what-is/021/
FPV	First Person View	This can also refer to the complete avionics-telemetry supplied via a camera & video transmission system
GPIO	General Purpose Input/Output	Reconfigurable digital signal pin that can be selected from an MCU pin
IMU	Inertial Measurement Unit	Inertial Navigation hardware systems using combined gyroscope and accelerometer unit intended to provide accurate estimates of angular rates, acceleration, and orientation. These can also incorporate magnetometers, barometers, and GPS signals
I2C	Inter-Integrated Circuit synchronous serial communication protocol used for connecting microcontroller CPU to peripheral devices
MCU	Micro Controller Unit	Single integrated circuit microprocessor with integrated processor, memory, and programmable input/output modules
SPI Bus	Serial Peripheral Interface that enables MCU to interface with ADC, DAC, registers, RAM storage, and GPIO	https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html
PCB	Printed Circuit Board	May also refer to a populated PCB with components
PDB	Power Distribution Board	A PCB intended to provide power distribution to electronic speed controller, flight controller, and other peripheral elements
VDD	Voltage - Operating Voltage for a particular chip
VDD_IO	Voltage range permissible as I/O Supply voltage (Typically 3.3V or less)

2 Engaging with the Betaflight Development Team

2.1 Betaflight Supported Review Process - Example

This is the path to Betaflight Supported status. A board that does not go through it can still be accepted into the cloud build as Manufacturer supported, if it meets the Cloud Build Acceptance criteria.

• Manufacturer initiates contact with Betaflight developer(s) at [email protected]

• Betaflight team will establish a closed Discord channel for ongoing private discussion between key members of the development team and manufacturer designees. Work in progress schematics, PCB renders, and similar documentation prior to initial production provides opportunities for early feedback.

• Before submitting a target design, review it carefully against these guidelines. A new design that uses anything not accepted for new designs is not accepted into the cloud build, and anything not recommended is accepted only within its limits, see Cloud Build Acceptance.

• Initial Submission

  • This will require key information to be available, such as specific MCU arrangement (e.g. SPI Bus allocations) may be required in order to support complete feature sets.

  • Desired Target name, MCU type, and which target architecture to be used required.

    • Optionally, if any Official Betaflight Presets are to be requested with this hardware, what specific configurations will be used, and a rough plan of what complete system hardware will be provided to support these efforts.

  • Initial PR for target implementation will need to also include a maintainer, with the intention of providing permission to make future edits on the target.

• Request for specific targets

  • If the flight controller design is intended to have a dedicated Betaflight target, then a new target submission can accompany the process. For additional information, see target submission requirements.

• Production Representative Samples

  • To complete the review for Betaflight Supported, representative hardware samples of initial production run, or pre-production batches which are representative of the final release design, must be furnished to designated Betaflight development team member(s) when requested, to conduct final validation.

  • This will indirectly provide access to the adjacent benefits of leveraging Betaflight developer expertise by using this hardware in complete systems, including flight testing as desired and comprehensive blackbox log analysis. For configurations requiring specific hardware to be tested (e.g. a Bind & Fly or Plug & Play UAS), providing complete representative hardware systems is best.

• Reporting of performance

  • With sufficient test time using the final product, developers can confirm that it meets our guidelines and performance expectations.

• Submission

  • Once the review is complete, the board is marked Betaflight Supported, and the Betaflight App shows that status in the firmware flasher
    • If new target(s) and/or presets have been added, pull requests will be evaluated, completed, and merged. New Betaflight Supported boards, and fixes to them, can reach the cloud build between releases

• Target Maintenance

  • After review and release, the designated contact provides continuing support to end users and keeps the target working as Betaflight moves forward. The Betaflight team does not provide end-user hardware support, even for Betaflight Supported boards; it fixes the firmware bugs that the manufacturer raises with it

2.2 Adjacent Benefits and Opportunities

Betaflight developers are likely to provide significant indirect benefits for manufacturers adhering to this program. These benefits could include reviews of board designs, pad location recommendations, evaluation of EMI behaviors in builds, analysis of Blackbox logging outputs, and even insights into forward compatibility with other subsystems used in complete builds.

Improved customer experience with software interactions, development of presets for BNF multicopter configurations, and validation with specific FPV and RC segments of craft to ensure customer experience will be positive. The key integration aspects of supporting various remote control and video combinations can only be fully validated with testing hardware samples.

This thorough testing by expert team members will help verify the design on the way to Betaflight Supported status. Betaflight Supported status is valuable promotion for the manufacturer, so we urge manufacturers to take up this opportunity and work with us.

3.0 Flight Controller Design Guidelines

These guidelines provide best practices for physical, electrical, and documentation support of flight controllers. If your design needs to depart from them, we invite you to talk to the Betaflight developers early in the design and prototyping process, at [email protected]. It is much easier to find a good approach together before production than after it.

3.1 Best Practices for Flight Controller Design and Performance

When asked to review hardware our first action will be to review schematics/layouts against the application notes for the applicable data sheets. The specifics of how the hardware is interconnected is of course going to be driven by a number of constraints, such as recommended pinouts, as outlined below, but it is essential that good design practices are followed with respect to providing good quality power regulation, appropriate use of ground/power planes, decoupling component positioning etc. Manufacturers are expected to adhere to industry best practices and comply with manufacturer datasheets for components in the absence of any Betaflight-specific guidance below.

3.1.1 Physical Configuration

Primary configurations that place the inertial motion unit and other EMI-sensitive components on the side of the PCB that should be mounted away from the electronic speed controller performs best in vertically stacked configurations. Similarly, physically larger components such as inverters in more protected locations from impacts or adjacent PCB boards in stacked build configurations is recommended.

The commonly accepted and used board layouts include 16x16mm for M2 hardware (perpendicularly aligned), 25.4x25.4mm for M2 hardware (typically diagonally aligned), 20x20mm for M2 or M3 hardware (perpendicularly aligned), and 30.5x30.5mm for M3 hardware (perpendicularly aligned). In the case of 20x20 boards, selecting a hardware mounting size should be informed by the ability to use threaded inserts and shock-absorbing grommets in oversized holes, while dedicated M2 mounting limits mounting options if hardware is capable of being used in larger craft that tend to utilize M3 mounting.

Boards with oversized holes (e.g. M4 holes and silicone inserts for M3 stack mounting) experience longer service life and experience fewer failures due to PCB deformation during impacts. For standalone flight controllers, integrated ‘AIO’ flight controllers, and even adjacent configurations provided as ‘stacks’ with additional PCBs, this architecture has been proven to be the most robust over time.

Board layouts should provide redundancy for all critical functions. For example, solder locations with identical pin arrangements to JST connector located adjacent to the JST header mounting is strongly recommended, providing end-users significant added value and opportunities to produce more robust craft. Castellations and use of mounting pads with through holes or edge continuity are also strongly recommended, especially with more compact flight controller designs.

For board layouts implementing transistor PINIO functionality for ‘pit switch’ or similar behaviors, solder bridge options are strongly recommended to enable users to select output voltage, or physically bypass the switching functionality by connecting to voltage sources. Particularly for video systems, it is strongly recommended to avoid performing this switching on the ground, due to interference concerns demonstrated with inconsistent ground planes.

If providing direct mounting support for receivers, the following specification should be followed: the pin sequence must be GND, 5V, UART RX, UART TX with a 2.54mm pin pitch, and permit receivers sized up to 12x20mm. This matches the pad order of CRSF Nano and ELRS Nano receivers, which label their own pads GND, 5V, TX, RX, so each receiver pad lands on its crossed partner on the same UART (receiver TX to FC RX, receiver RX to FC TX). This direct-mount order deliberately differs from the 4-pin JST SH serial connector in the Betaflight Connector Standard (5V, GND, RX, TX), because it follows the receivers' pad layout rather than the connector standard's power-first order.

Rules:

• GND should be as close to a signal as possible.
• High speed signals should be away from power.
• Keep similar signals next to each other.
• Always minimize current flow path.

info

For connector pinout please refer to the Betaflight Connector Standard

3.1.2 Inertial Measurement Unit (IMU) Selection

Selecting the right IMU for a flight controller is crucial for optimal flight performance. The InvenSense MPU-6000, the long-time standard, has reached end-of-life. As a replacement, we strongly recommend the ICM-42688-P (see below). Where the ICM-42688-P cannot be sourced, the STMicroelectronics LSM6DSK320X is the preferred second source (see below). Gyros must communicate via SPI, because the firmware does not support I2C gyros, so a board with its gyro on I2C is not accepted into the cloud build. Legacy gyros are end of life. The MPU-6500 is not accepted for new designs. A genuine MPU-6000 is still accepted, and the ICM-2060x parts are not recommended. Existing boards that use any of them keep their status.

note

The Bosch BMI-270 IMU is not recommended, because its gyroscope is uncalibrated. As a result, when gyro is integrated to return a change in attitude, the new attitude estimate can be in error, sometimes as much as 5% or 10%. This causes an angle offset until the accelerometer data can be used. It is accepted only as a second source on an ICM-42688-P footprint, see 4.2.1.1.

Boards that second-source a BMI270 on an ICM-42688-P footprint should note that the two parts do not share axis orientation. See BMI270 on a shared ICM-42688-P footprint for the config define that compensates for this.

3.1.2.1 Future IMU Options and How to Select Preferred Options

As the MPU-6000 is EOL, the currently recommended IMU for most applications is the TDK InvenSense ICM-42688-P. This gyro has been proven in many designs to provide excellent performance with low noise and good durability. In all cases, it is strongly recommended that the gyro be powered from its own LDO. For the ICM-42688-P, this is required for Betaflight Supported. See below for more on electrical noise considerations.

The ICM-42688-P also supports an external clock input, which can yield increased stability and performance. If your design allows, consider adding external clock support. See the following PR for more info: https://github.com/betaflight/betaflight/pull/13912

In the config this is USE_GYRO_CLKIN together with GYRO_1_CLKIN_PIN (and GYRO_2_CLKIN_PIN for a second gyro). The firmware drives the clock at a fixed 32 kHz and currently applies it only to the ICM-42688-P, so other parts on the same footprint gain nothing from the circuit.

note

Using a single timer with 4 channels dedicated to dual gyro FSYNC/INT pins for such a timer would be ideal

Alternative IMU: STMicroelectronics LSM6DSK320X

Where the ICM-42688-P is unavailable, the STMicroelectronics LSM6DSK320X is the preferred second source (define USE_ACCGYRO_LSM6DSK320X, which shares the LSM6DSV16X driver). It is a modern 6-axis SPI IMU with a high gyro output data rate and a dual accelerometer that adds a ±320 g high-g range. As with any IMU, it must be powered from its own LDO and validated in a representative flight environment in collaboration with the Betaflight development team. The ICM-42688-P remains the reference gyro for maximum flight performance — its lower gyro noise, native 8 kHz sampling, and external-clock input are what the current Betaflight filtering and tuning pipeline is built around — so the LSM6DSK320X is best treated as a second-source / availability-driven option rather than a performance upgrade.

Future IMU selection should be carried out with close involvement of the Betaflight development group. Early hardware validation samples should be explored in collaboration with Betaflight developers to determine the suitability of these IMU units in relevant environments. The ability to customize IMU lowpass filtering and operate within the same GRMS/Shock environment allows for maximum portability of existing filtering and tune schemes, but this development must occur with complete hardware samples and flown in representative flight regimes in order to replicate the EMI environment end-users will experience.

The IMU sensors, designed for applications outside of sUAS, are typically subjected to very harsh electromagnetic environments. Ensuring electromagnetic compatibility when using these immediately adjacent to ultrasonically switched power MOSFET devices, constantly operational radio frequency devices (such as remote control and FPV video systems), under thermal stresses of moving over 1kW through the complete flight stack, are a nontrivial operation. In order to minimize risks of flyaway and brownout behaviors which can be observed if IMU data filtering and power delivery are inadequate, proper circuit design and validation testing must be performed.

note

Advised power supply design for ICM-42xxx IMU. (also applies to others)

These IMU require a stable and clean power supply to function correctly, provided with this they are very capable IMU for flight controller use. Refer to the datasheets for recommended power filtering / bypass caps. Peak to peak noise of under 50uV on the supply should be the ideal goal.
Considerations for a suitable LDO are at least 500mA rated output allowing for extra capacitors on the output, two 20nF.
A PSRR >70dB down as low as 1Hz is preferred.
Where space allows, a dedicated LDO and circuit is advised for the IMU. For ICM-42688-P this is required for Betaflight Supported.

3.1.3 Other Sensors

3.1.3.1 I2C Devices and I2C Buses

Barometers and magnetometers should use I2C, not SPI. Betaflight operates with a fast (800 kHz) I2C bus speed by default, making proper pull-up resistor selection critical to prevent signal loss. The optimal pull-up values depend on bus capacitance, but 4.7kΩ is a recommended starting point. I2C is a shared bus, meaning multiple devices can communicate over the same two-wire interface (SCL and SDA). However, for reliable communication, careful attention must be given to signal integrity and noise immunity. Excessive bus capacitance, improper PCB layout, or insufficient pull-up resistance can lead to communication errors or device malfunctions.

When designing a flight controller with I2C sensors, manufacturers should:

• Keep I2C traces as short as possible to minimize capacitance and signal degradation.

• Use a ground plane beneath I2C traces to reduce noise and improve signal integrity.

• Avoid routing I2C traces near high-noise sources such as motor drivers and power regulation circuits.

• Select appropriate pull-up resistor values based on the number of devices and overall bus capacitance. In cases where multiple devices share the bus, adjusting pull-up values (e.g., lowering to 2.2kΩ or raising to 10kΩ) may be necessary to achieve optimal signal quality.

Additionally, manufacturers should test the stability of the I2C bus under realistic operating conditions, including different temperature and voltage scenarios, to ensure robustness and reliability in flight.

Barometer selection

The Bosch BMP280 is a commonly used barometer. The 'real' unit is marked "Bosch BMP280" on the metal case. Sometimes it is replaced with a 'clone' which mimic the BMP280 in appearance, and reports the same I2C address and data structures, so that they show up as being a BMP280 in Betaflight. Manufacturers should only say that a board has a BMP280 barometer if it is a 'real' Bosch manufactured barometer. If a clone of the BMP280 is used, the name of the barometer used must be shown, e.g. A7L01, ASK03, and the manufacturer must confirm that the clone is as accurate as the original Bosch BMP280. Clones are warned against because their accuracy varies, and should not be used. Because a clone uses the same driver as the original, this cannot be checked at the target level, so it is guidance rather than a condition of cloud build acceptance.

The recommended I2C address for the BMP280 is 0x76, with SDO grounded, permitting automatic address identification by Betaflight.

note

If only one I2C bus is available and shared between an onboard barometer and an external connector for a magnetometer or other device, it is advisable to include a method for changing the barometer’s I2C address in case of conflicts. This can be achieved by incorporating jumper pads or a zero-ohm resistor, allowing for easy reconfiguration. Providing this flexibility ensures broader compatibility with external sensors and prevents address conflicts that could disrupt communication.

The plastic-cased, individually calibrated Infineon DPS310 provides a significant improvement in absolute and relative altitude accuracy, and much lower noise levels, compared to the BMP280. Each individual Infineon DPS310 is programmed with custom temperature correction coefficients at the time of its manufacture, ensuring exceptionally accurate temperature measurement, and thereby very accurate pressure measurement in response to temperature changes.

Unfortunately, we note that many manufacturers are using 'clones' of the DPS310, typically with an integral metal case that has a small hole. Because these devices report the same I2C ID as the 'real' DPS310, and use the same control and data registers, Betaflight reports them as being DPS310's, and will return pressure values. However, unlike the real DPS310, logging has shown that these clones typically report incorrect temperature readings, most likely because the custom temperature coefficients for the chip are not written individually at production time. Incorrect temperature readings may lead to altitude errors. A number users have reported inappropriate barometer readings with these clones.

The Infineon DPS310 was replaced with the Infineon DPS368 in late 2019, and the DPS368 has even greater accuracy than the DPS310.

note

A board that uses a clone must not be advertised as having a DPS310. Metal-cased clones are warned against because of the temperature errors described above, and should not be used. We strongly recommend the latest Infineon DPS368 barometer, or the earlier Infineon DPS310, both of which are marked 'Infineon' and are supplied in a plastic case.

Magnetometer selection

The IST8310 magnetometer has an unusual axis orientation, where the Y axis is 180 degrees rotated compared to all the other commonly used magnetometers. The user must use custom mag orientation values for correct functioning of the IST8310. It is not possible for the user to just apply a simple rotation to correct the IST8310. For this reason we do not recommend using the IST8310 magnetometer with Betaflight.

note

The use of magnetometers with non-standard axis orientations is not recommended.

Note also that the IST8310 magnetometer can be configured with any one of four I2C addresses. Betaflight will only connect to the IST8310 automatically if the default I2C address of 0x0E is used. If any of the other three I2C addresses (0x0C, 0x0D, 0x0F) are used, the user will need to custom enter either 12, 13 or 15 as the mag_i2c_address value, or it will not work.

The QMC5883L has 'normal' axis orientation and works well.

The naming rule for barometers applies to magnetometers too: name the part actually fitted. A board must not be advertised with a magnetometer it does not use, and clones are warned against and should not be used.

note

Where a barometer or magnetometer has a configurable I2C address, always use the default address, so that it can be automatically detected in Betaflight

3.1.4 Electrical Isolation for Sensor Components

Separate VDD from VDD_IO Implement additional filtering on VDD if using a single 3v reg for MCU and Sensor

3.1.4.1 Regulated Power and LDO Power Configurations

A key aspect of flight controller performance and longevity is design of the low powered rails that supply power to inertial motion units and the MCU. Providing robust low-ripple power to these devices provides the maximum performance potential and hardware longevity for operation in the challenging EMI environments present on these craft.

Similarly, 3.3V, 5V, and 9-12V BEC power needs to provide consistent power at the intended current draw. For example, 3.3V 500mA is a recommended minimum current. ‘4.5V’ (5V USB supplied power) should be capable of powering a receiver and GPS unit, which may require over 700mA.

Standard battery powered 5V rails should provide at least 1A, preferably 1.5A to 2A in order to provide higher current if anticipated to be used with a large number of peripherals (such as LED strips, 5V powered FPV Video Systems, or as source power to HD cameras).

Providing a 10V 2A BEC is also strongly recommended with flight controller designs, as this supports high definition video systems, and even enables better analog video system power options. Each of these can be optionally connected to PINIO, pit switches, and/or jumper pad setups that enable end-users to select constant-on or transistor-switched behavior, particularly if located to support video transmission systems. This is most easily accomplished by connecting the BEC EN pin to a free GPIO configured as PINIO.

Such 10V regulators should function at full rated current down to 10V input voltage to support the BEC output from some ESCs.

Again, providing robust low-ripple power to these devices provides the maximum performance potential and hardware longevity for operation in the challenging EMI environments present on these craft.

3.1.4.2 ADC Circuitry (e.g. for Vbat and Current Sensors)

All ADC inputs (e.g. VBAT, CURR, RSSI) should be equipped with 100nF bypass caps to minimize noise.

The recommended Vbat voltage divider for most designs is 100K/10K. Note the tolerance of the resistors used here affects the accuracy of the voltage scale set in the config file.

3.1.4.3 Supporting Additional Features

Numerous standard features have become common with flight controller design, for example Barometers to supplement IMU functionality to provide more accurate altitude estimates, PINIO transistor switched output pads, LED pads, or additional PWM/Motor outputs. A MAX7456 chip for monochrome analogue On-Screen Display (OSD) is optional, for boards aimed at analogue video builds. The Betaflight Connector Standard recommends placing the analogue OSD on the VTX instead, as digital video systems do, and a board without an onboard OSD does not need the analogue camera connectors.

In order to fully support these additional features, it remains strongly recommended that hardware manufacturers incorporate early developer feedback to ensure complete functionality.

3.1.4.4 SWD Debug Support

In order to aid development of Betaflight firmware, and to debug FC specific issues, it is highly beneficial to have test points for the SWDIO/SWCLK lines together with 3V3 and ground connections to enable connection of a debugger such as a Segger JLink or ST-Link. This speeds up resolution of issues hugely, so if at all possible do not use those pins (PA13/PA14) for other purposes.

3.1.4.5 Blackbox Support

Blackbox storage of at least 8mb should also be standard on all FCs, because tuning problems and flight issues are very hard to diagnose without a blackbox log.

3.1.4.6 LEDs

FCs should implement at least one LED to indicate activity, and LED 0 is required for Betaflight Supported. The second is preferable, and the third optional. Having at least one LED is essential for users to help diagnose basic faults. More LEDs are beneficial to developers as we can build custom images to help diagnose user reported issues.

Each LED should be connected to a GPIO line. Polarity of the output does not matter.

LED Number	Color	Required
0	Blue	Yes
1	Green	Preferably
2	Amber	No

For details of the use of these LEDs, please see the FC LEDs documentation

warning

Pin PC13, PC14 and PC15 are supplied through the power switch. Since the switch only sinks a limited amount of current (3 mA), the use of GPIOs PC13 to PC15 in output mode is limited:

• The speed should not exceed 2 MHz with a maximum load of 30 pF
• These GPIOs must not be used as current sources (e.g. to drive an LED).

3.1.5 Current Limiting Resistors

Current-limiting resistors on GPIOs, if used, should not exceed 100 ohms. This is especially true for motor and LED signal pins, where signal levels are marginal to begin with, and UARTs, where low signal levels can cause issues with some digital VTX systems.

3.2 Resource Selection Considerations

warning

A gyro sharing its SPI bus with other devices is not accepted for new designs: transfers on a shared bus block each other, which costs gyro timing and flight performance, so a new design that does this is not accepted into the cloud build. Give the gyro its own SPI bus. Sharing between other devices also blocks, and a MAX7456 sharing a bus with blackbox flash has been a common source of support issues, so keep those two apart where possible.

warning

STM32 F4 and F7 designs with more than 4 motor outputs are not accepted for new designs, because these MCUs do not have enough timers and DMA streams to go round. A new design of this kind is not accepted into the cloud build. F4 and F7 remain fine for budget boards and AIOs with 4 motor outputs. The STM32F411 is not accepted for new designs because of its limited IO and flash, and remains fine on existing boards.

For high IO or more than 4 motor outputs, the STM32 H7 (H743) is preferred. For small or budget boards, the STM32 G4, AT32F435 and RP2350 are preferred where their resources suit the design. The STM32 H5 has no official release binaries yet, so talk to the team before designing around it. For the full list of platforms and their suitability, see 4.4.

BITBANG is the new default on non-F4 MCUs (the APM32 F4 family behaves like the STM32 F4 here) and FC designers should use as few GPIO PORTS as possible to avoid needing a DMA stream per GPIO port. i.e.

• 8 motors on 1 GPIO port is optimal.
• M1-M4 must use 1 GPIO port, and preferably one 4-channel timer with DMA. A new design that spreads M1-M4 over more than one port is not accepted into the cloud build.
• M5-M8 may be split across GPIO ports, for example on wing flight controllers or boards also designed for ArduPilot or INAV, though each extra port needs another DMA stream.

There is also a choice between using advanced timers or not, TIM1/TIM8 are advanced and get used by DSHOT BITBANG.

It may be optimal to use TIM1 + TIM8 for all motors so that the other timers are always free. Or it may be optimal to use timers other than TIM1/TIM8 for motors so that TIM1/TIM8 are free for other uses when DSHOT BITBANG is not used.

note

When DSHOT BITBANG is used, the advanced timers (TIM1/TIM8) use DMA to drive the GPIO signals directly, the GPIO pins' timer AF modes are not used. The timer(s) used by DSHOT BITBANG can drive GPIO signals on any GPIO pins, even if they do not have timer AF signals. TIM1 has inter-peripheral connectivity that other timers do not have.

3.2.1 Assigning Resource by Priority

Appropriate resource allocation ensures maximum flexibility in the selection of the modes available to users (for example with DSHOT) and also minimizes conflicts in timer and DMA stream allocation.

Assign motor channels with highest priority.

Note: STM32F4 and STM32F7 designs with more than 4 motor outputs are not accepted for new designs, see 3.2.

3.2.1.1 F4 Resource Selection

As F4 MCUs do not support UART inversion, a hardware inverter must be added in order to support inverted serial protocols such as SBUS, SmartPort, and F.Port. This functionality is not required for Betaflight Supported, but if included any pins that implement inversion should be clearly marked, and ideally not result in reduced capability of that UART when used with non-inverted peripherals.

Bidirectional DShot is off in the firmware defaults, but the recommended configuration uses it, and a config can turn it on with #define DEFAULT_DSHOT_TELEMETRY DSHOT_TELEMETRY_ON. With it enabled, F4 boards are expected to run a 4kHz PID loop with DSHOT300 (see 4.1). This requires proper Motor Resource allocation to enable bidirectional DShot communication.

If using Bitbanged DShot, when SPI Bus #1 is to be used for the gyro, care must be taken to ensure that motor pins are assigned to appropriate timers. This is because Bitbanged DSHOT uses DMA2 to write to GPIO ports. If this is enabled, it is not possible to enable DMA on an SPI bus using DMA2. Practically speaking this means that we can’t support DMA on SPI bus 1 (which uses DMA2) on F405 and F411 processors. It is better to put any devices that share a bus on another SPI bus, and keep SPI bus 1, which is typically used for the gyro, for the gyro alone. Bitbanged DShot communication protocol will always use Timer 1 and Timer 8 - do not use these pins for any other functions.

Further reading: Section 2.1.10 of the errata at https://www.st.com/resource/en/errata_sheet/dm00037591-stm32f405407xx-and-stm32f415417xx-device-limitations-stmicroelectronics.pdf

Corruption may occur on DMA2 if AHB peripherals (e.g. GPIO ports) are accessed concurrently with APB peripherals (e.g. SPI busses). Practically, this means that all pins should be on the same port, or at most two ports, so that only one (or two) DMA streams are required for bitbanged operation.

3.2.1.2 F7 Resource Selection

F7 series MCUs provide greater flexibility in resource assignments and do not require hardware inverters in order to support inverted serial protocols. They also do not exhibit the SPI 1 DMA limitations of F4 processors.

Bitbanged DShot communication protocol will always use TIM1 and/or TIM8 - At least one of these timers must be available for use.

3.2.1.3 Resource Selection on MCUs With Flexible DMA Routing

G4, H7 and AT32F435 series MCUs include a DMAMUX, and the newer H5, C5, N6 and X32M7 families provide the equally flexible GPDMA/LPDMA scheme, both of which allow for flexible DMA stream allocation. Therefore, only timer conflicts between motor outputs and other outputs need to be avoided.

RP2350 (PICO) and ESP32 do not drive DShot from timers at all — RP2350 uses PIO state machines — so the timer and bitbang guidance above does not apply to those platforms.

note

STM32 F4 MCUs (and the APM32 F4 family) should use PWM-based DShot by default, due to a chip errata that prevents peripherals on DMA2 (usually gyro on SPI1) from using DMA when bitbanged DShot is used. All other timer-driven MCUs (F7, G4, H7, H5, C5, N6, AT32F435, X32M7) should use bitbanged DShot by default for the best performance and most efficient use of timer and DMA resources.

3.2.2 Select appropriate default UARTs to avoid hijacking USB DFU

When selecting UARTs, for the default RX connection or to route to JST sockets, care should be taken to avoid those MCU pins which may interfere with USB DFU.

The DFU protocol will attach to any bootloader UART which is sending traffic, not only the USB DFU connection. This is a design feature of the ROM bootloader on the STM32 and AT32 MCUs listed in the table below, and cannot be disabled.

Meaning that any receiver or GPS unit attached to UART1 or UART3 (by default on F405 boards) can "hijack" DFU and make the MCU think that the serial UART should be used for DFU traffic instead of USB.

Avoiding this means selecting appropriate UARTs for default connectors so the pilot will be unlikely to connect receivers or GPS units to these ports. This is mainly a problem for peripherals which are powered from the 4v5 pads and so are powered on when USB is attached. The symptoms pilots see, and their workarounds, are described in DFU Hijacking.

More details on STM32 Bootloaders can be found in Application Note AN2606 https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

AT32 Bootloaders are described in section 2.5 (Boot modes) of the AT32F435/437 datasheet https://www.arterychip.com/download/DS/DS_AT32F435_437_V2.12_EN.pdf

MCU	Pins
STM32F411	(PA09, PA10), (PD05, PD06)
STM32F405	(PA09, PA10), (PB10, PB11), (PC10, PC11)
STM32F7xx	(PA09, PA10), (PB10, PB11), (PC10, PC11)
STM32G47x	(PA09, PA10), (PA02, PA03), (PC10, PC11)
STM32H56x	(PA09, PA10), (PA02, PA03), (PD08, PD09)
STM32H72x	(PA09, PA10), (PA02, PA03), (PB10, PB11), (PD08, PD09)
STM32H73x	(PA09, PA10), (PA02, PA03), (PB10, PB11), (PD08, PD09)
STM32H74x	(PA09, PA10), (PB14, PB15), (PA02, PA03), (PB10, PB11)
AT32F435	(PA09, PA10), (PA02, PA03), (PB10, PB11)

The table covers the families where a UART can hijack the ROM bootloader. Check the relevant bootloader application note for any family not listed. Note that some newer platforms do not use USB DFU at all — RP2350 boards enter their bootloader through BOOTSEL and present a UF2 mass-storage device, and ESP32 parts use a serial bootloader — so this specific failure mode does not apply to them.

3.3 Markings, Version Numbers, and Documentation

It is highly recommended that the flight controller Manufacturer Name, Board Name, and Board Design Revision be marked clearly on the flight controller itself. Where possible, indicating the firmware target name, or selecting a firmware target name to minimize confusion reduces the likelihood of an end-user attempting to configure the flight controller with an incorrect target.

3.3.1 Creating Design Revisions and Communicating Changes

Providing sufficient marking and documentation will be required for Betaflight Supported. Screen printing on the flight controller critical information - pin identifiers, board name, revision, and manufacturer will be necessary, with sufficient detail to enable end-users to properly connect devices to the flight controller.

When creating flight controller revisions and improvements, it is strongly recommended that indications and documentations are made available, particularly when pinout changes, output rating changes, or hardware bill of material changes. Any board configuration change requiring a user to change configuration behavior must have an accompanying change in marking to indicate (e.g. changing an IMU, or altering the pinout of solder pads).

Following standard marking practices (e.g. V, VCC, or VBAT for battery voltage, G or GND for ground, T for ESC Telemetry, C for Current Sensing ADC, etc.) is also strongly recommended. Similarly, providing consistent color selections for pin header JST wiring looms, and consistent marking on the PCB is always preferable for robust building and troubleshooting.

Providing a CLI dump file that enables users to reset their flight controller to stock configuration is needed if a dedicated target is not provided. This is particularly relevant if multiple versions of a board which share targets but have significant hardware changes are present, a CLI dump file for each flight controller revision must be made available to users.

3.3.2 Implementing Flight Controller Designs for Ready-To-Fly Craft

3.3.2.1 General Recommendations and Documentation

A good example of properly documenting and supporting ready-to-fly craft would be the way EMAX makes entire CLI dumps of every craft which enables users to revert systems to the as-shipped software configuration.

3.3.2.2 Leveraging the Betaflight Preset System

One of the most powerful tools for end-users that can save significant time and reduce the likelihood of misconfiguration is the Preset system. Developing an Official Betaflight preset and generating a pull request with the assistance of the Betaflight development team allows for end-users to quickly and easily configure their craft. The versatility of selectable options, RC Link presets, and even Tune & Filter presets allow for diverse configurations of RTF craft products to be supported. Applying and using presets not only saves users significant time, but reduces the likelihood of data entry errors or incorrect configurations to be applied, which can be of particular importance for products aimed at less experienced users.

For manufacturers providing configuration presets for flight controllers (strongly recommended), providing documentation of suggested locations to connect peripheral devices, match the provided preset menu selections can greatly assist end-users with proper configuration of their craft. These should include selecting appropriate PID loop rates, DShot data rates, IMU-specific Gyro Lowpass Filtering, Receiver installation (including options with the correct Port, protocol, SerialRX_Inversion, and SerialRX_HalfDuplex), HD FPV MSP port installation, VTX control (including protocol(s), port, and optional pit mode states), GPS (port and protocols), LEDs, and any PINIO type peripheral connections where applicable.

Working with the Betaflight development team provides opportunities to develop presets that can bring RTF craft back to stock configuration, enable users to rapidly configure ‘Plug & Play’ systems based on selected RC link hardware installed per documentation, and even permit Betaflight developers with extensive experience developing precise tunes for craft to generate a range of tunes for that specific product.

3.4 Electronic Speed Controller Compatibility

A significant amount of the flight performance available in current Betaflight is based on leveraging ESC RPM telemetry data in order to use RPM Notch Filters and Dynamic Idle features.

3.4.1 For 32-Bit ESCs (e.g. BLHeli_32 and AM32)

Betaflight supports all 32-bit ESCs currently available, with BLHeli_32 and AM32 configurations, as well as APD configurations being capable of supporting bidirectional DShot, and user-configured operation with bidirectional DShot disabled. Additional DShot extended telemetry will be implemented over time as demonstrated stable, however current extended telemetry options will only be enabled by user selection.

BLHeli AS ceased operations in 2024. No new BLHeli_32 licenses have been issued, and users are no longer able to flash firmware. Manufacturers should no longer be shipping BLHeli_32 ESCs: BLHeli_32 on new products is warned against because it is no longer maintained. ESC firmware is not part of the target, so this is guidance rather than a condition of cloud build acceptance. There are several alternatives, including AM32 and ESCape32 that can be flashed to the same hardware and are fully supported by the open-source community.

3.4.2 For 8-Bit ESCs (e.g. BLHeli_S, Bluejay)

Betaflight will continue to support all current 8-bit ESC configurations. Bidirectional DShot is off in the firmware defaults, but RPM filtering and RPM dynamic idle depend on it, so the ESC firmware should support it.

BLHeli_S without bidirectional DShot on new products is warned against, because it cannot provide the RPM telemetry that RPM filtering needs. As with BLHeli_32, this is guidance, not a condition of cloud build acceptance.

8-bit ESCs with BLHeliS can be flashed with a modern ESC firmware such as Bluejay to support bidirectional DShot.

For hardware, such as AIO boards, which incorporate an ESC and FC, the expectation will be that hardware comes with installed firmware meeting these requirements. The preferred option in this case is Bluejay, due to the ability to adjust PWM frequencies, bidirectional DShot support, and ease of end-user support for other functionality across MCU layouts.

Such boards should also enable bidirectional DShot in their config with #define DEFAULT_DSHOT_TELEMETRY DSHOT_TELEMETRY_ON, so that RPM filtering works out of the box.

If the ESC firmware does not support bidirectional DShot, pilots do not get RPM filtering until they reflash their ESCs. If bidirectional DShot is enabled, whether by the config or by the pilot, and any ESC does not return telemetry, the craft will not arm and the arming flags show DSHOT_TELEM. The solution is reflashing the ESC (strongly recommended) or disabling Bidirectional DShot (not recommended).

3.4.3 For Legacy ESCs

For legacy ESCs that are only capable of OneShot and Multishot utilization, end-users will be required to disable DShot in order to continue with operations. This situation only applies to pre-BLHeli_S ESC architectures, and is not anticipated to be an issue for the vast majority of users. DShot capability has been part of Betaflight since 3.2 (in 2017), therefore legacy support for this hardware will require additional end-user configuration. However, these ESCs are still indirectly supported and may exhibit improved performance with the most recent Betaflight versions despite being unable to take advantage of bidirectional DShot features.

4 Reference Tables

4.1 Rated Looptime and Performance

Rated Performance of specific MCU, IMU, and ESC DShot Protocol Combinations

These are the strongly recommended default configurations.

For stock configurations, and implementations of ready-to-fly craft, the following configurations are the officially recommended configurations.

Importantly, although enabling Bidirectional DShot may require lower PID Loop Rates for F411 and F405 flight controllers, the difference in loop time is 125us or 250us. These are microseconds. The improvements in filtering using RPM Notches alongside Sliding-DFT Multi-Dynamic notches can provide improvements on the scale of milliseconds for phase latency when processing IMU signals to post-filter information that can be used for PID/Mixer calculations. The flight performance of using bidirectional DShot is absolutely worth the PID Looptime Tradeoff, due to that order of magnitude improvement in cumulative signal pathway delay enabled with more targeted notch filtering schema.

Looptime and Performance Recommendation Table:

MCU	IMU	Sampling Rate	Bidirectional DShot Status	PID Loop Rate	DShot Protocol
H7XX	MPU60X0, ICM2060X, ICM42688P	8 kHz	Enabled or Disabled	8 kHz	DShot 600
	BMI-270	3.2 kHz	Enabled or Disabled	3.2 kHz	DShot 300
F722, G474, AT32F435 and similar	MPU60X0, ICM2060X, ICM42688P	8 kHz	Enabled or Disabled	4 kHz	DShot 300
	BMI-270	3.2 kHz	Enabled or Disabled	3.2 kHz	DShot 300
F405	MPU60X0, ICM2060X, ICM42688P	8 kHz	Enabled	4 kHz	DShot 300
	MPU60X0, ICM2060X, ICM42688P	8 kHz	Disabled (not recommended)	8 kHz	DShot 600
	BMI-270	3.2 kHz	Enabled or Disabled	3.2 kHz	DShot 300
F411 UART RX **	MPU60X0, ICM2060X	8 kHz	Enabled	4 kHz	DShot 300
	BMI-270	3.2 kHz	Enabled	3.2 kHz	DShot 300
F411 SPI RX ***	MPU60X0, ICM2060X	8 kHz	Enabled	2 kHz	DShot 300
	MPU60X0, ICM2060X	8 kHz	Disabled (not recommended)	4 kHz	DShot 300
	BMI-270	3.2 kHz	Enabled	1.6 kHz	DShot 300
	BMI-270	3.2 kHz	Disabled (not recommended)	3.2 kHz	DShot 300

note

The F411 and BMI-270 rows, and the legacy gyros (MPU60X0, ICM2060X) in the other rows, are for existing designs. New F411 designs are not accepted, the BMI-270 and ICM-2060x are not recommended, and only a genuine MPU-6000 is still accepted (see 3.1.2 and 3.2).

The IMU column above predates several currently supported parts. For reference, the native gyro output data rates are 8 kHz for the ICM-42688-P, ICM-42605, ICM-42622-P, ICM-42686-P, IIM-42652, IIM-42653, ICM-40609-D, LSM6DSV16X and LSM6DSK320X; 6.4 kHz for the ICM-45605, ICM-45686 and ICM-56686; 6664 Hz for the LSM6DSO; 9 kHz for the legacy ICM-20649; and 3.2 kHz for the BMI270 and BMI160. Treat the 8 kHz parts as equivalent to the ICM-42688-P rows, and agree defaults for the slower parts with the Betaflight team.

** For F411 UART RX applications, using both available UARTs and enabling SoftSerial, Accelerometer, large numbers of OSD elements, and using a larger number of filters, stability may require lowering looprate to 2kHz.

*** SPI receivers are not accepted for new designs, due to challenges in resource allocation and scheduler inconsistency that consistently emerge with SPI RX designs. A new design with an SPI receiver is not accepted into the cloud build. Additionally, there are no RC ecosystems that are actively developing a supported SPI RX solution (ExpressLRS 4.0 and later do not support SPI receivers; FrSky does not support SPI RX over any protocol, and other SPI RX solutions have been fully deprecated).

Note that the use of gyros such as the BMI270 lowers the gyro loop rate from 8kHz to 3.2kHz and therefore may be advantageous for F411 designs.

Targets on the newer platforms (STM32 H5, C5, N6, RP2350, X32M7 and APM32) are not listed above. As a starting point, the N6 and X32M7 are H7-class in compute; the H5 is closer to an F7 despite being a newer part; the C5 is lower again, at roughly half the H5; and APM32 F4 tracks F405. Agree the defaults with the Betaflight team as part of the target review — see 4.4 for the status of each platform.

4.2 Definitions for Targets

As reference please choose the defines for your target from this list as applicable for the target to select appropriate hardware for the cloud build.

warning

Use the exact define names below. A misspelled or non-existent USE_* define is not a build error — it is silently ignored, and the affected sensor simply never gets a driver compiled in, so the hardware appears absent to the user. Check your config against this list, and confirm each sensor is detected on real hardware before release.

4.2.1 Defines for GYRO and ACC

Define at least one gyro and one accelerometer. Gyroscopes must communicate via SPI. Legacy I2C-only parts (e.g. MPU6050) are omitted below, because a board with its gyro not on SPI is not accepted into the cloud build. The obsolete L3GD20 and the SITL/virtual sensors are also omitted, as they are not for new hardware.

The legacy MPU6000, MPU6500, MPU9250 and ICM2060x defines are listed for existing boards; on new designs the MPU6500 is not accepted, the ICM2060x is not recommended, and only a genuine MPU6000 is still accepted (see 3.1.2). The BMI270 define is listed for existing boards and for second-sourcing on a shared footprint (see 4.2.1.1); the BMI270 is not recommended.

// InvenSense / TDK
#define USE_GYRO_SPI_MPU6000
#define USE_ACC_SPI_MPU6000
#define USE_GYRO_SPI_MPU6500
#define USE_ACC_SPI_MPU6500
#define USE_GYRO_SPI_MPU9250
#define USE_ACC_SPI_MPU9250
#define USE_GYRO_SPI_ICM20602      // ICM20601 / ICM20602 / ICM20608G — alias handled by the MPU6500 driver (common_post.h)
#define USE_ACC_SPI_ICM20602       // ICM20601 / ICM20602 / ICM20608G — alias handled by the MPU6500 driver (common_post.h)
#define USE_GYRO_SPI_ICM20649
#define USE_ACC_SPI_ICM20649
#define USE_GYRO_SPI_ICM20689
#define USE_ACC_SPI_ICM20689
#define USE_ACCGYRO_ICM40609D
#define USE_GYRO_SPI_ICM42605
#define USE_ACC_SPI_ICM42605
#define USE_ACCGYRO_ICM42622P
#define USE_ACCGYRO_ICM42686P
#define USE_GYRO_SPI_ICM42688P
#define USE_ACC_SPI_ICM42688P
#define USE_ACCGYRO_IIM42652       // pair with another 426xx define, see note below
#define USE_ACCGYRO_IIM42653
#define USE_ACCGYRO_ICM45605
#define USE_ACCGYRO_ICM45686
#define USE_ACCGYRO_ICM56686
// Bosch
#define USE_ACCGYRO_BMI160
#define USE_ACCGYRO_BMI270
// STMicroelectronics
#define USE_ACCGYRO_LSM6DSO
#define USE_ACCGYRO_LSM6DSV16X
#define USE_ACCGYRO_LSM6DSK320X

Every gyro also needs its bus, chip select and interrupt pin declared (GYRO_<n>_SPI_INSTANCE, GYRO_<n>_CS_PIN, GYRO_<n>_EXTI_PIN), and an alignment (GYRO_<n>_ALIGN). The gyro count is derived from how many GYRO_<n>_CS_PIN defines are present, up to four, and DEFAULT_GYRO_TO_USE selects which one is used by default on a multi-gyro board. See creating a configuration for the details.

warning

Omitting GYRO_<n>_EXTI_PIN is not a build error, but the driver then falls back to polled SPI reads with no DMA and no interrupt-synchronised sampling. Always route and declare an interrupt pin for every gyro.

Additional gyro defines that are easy to miss:

Define	Purpose
USE_GYRO_CLKIN, GYRO_<n>_CLKIN_PIN	External clock input. The firmware only applies it to the ICM-42688-P, at a fixed 32 kHz, even though other parts in the family support it
ICM426XX_CLOCK, ICM456XX_CLOCK, ICM56686_CLOCK, ICM40609_LOCK	Override the default 24 MHz SPI clock where the layout cannot sustain it. Note the inconsistent _LOCK spelling on the ICM-40609 define
ENABLE_42686_EXTENDED_RANGE 1	Switches an ICM-42686-P to ±4000 dps / ±32 g instead of the default ±2000 dps / ±16 g
ENABLE_BMI270_ALIGN_AS_ICM 1	BMI270 axis remap for shared footprints, see below

warning

USE_ACCGYRO_IIM42652 is currently missing from the firmware's SPI detection table. A config that defines it alone will build but detect no gyro, so pair it with another ICM-426xx define (for example USE_GYRO_SPI_ICM42688P) until this is fixed in the firmware.

4.2.1.1 BMI270 on a Shared ICM-42688-P Footprint

The BMI270 and the ICM-42688-P share the LGA-14 PCB footprint but not their sense-axis orientation, so a BMI270 populated on a board laid out for the ICM-42688-P comes up rotated by 90 degrees.

Where one PCB is second-sourced between the two parts, the config can opt in to a CW90 remap of the BMI270 raw data, so that a single board alignment serves either populated chip:

// Second-sourced IMU: ICM-42688-P primary, BMI270 alternate on the same footprint
#define USE_GYRO_SPI_ICM42688P
#define USE_ACC_SPI_ICM42688P
#define USE_ACCGYRO_BMI270

// Present the BMI270 with ICM-42688-P axes so one alignment covers both populations
#define ENABLE_BMI270_ALIGN_AS_ICM 1

#define GYRO_1_ALIGN CW180_DEG // the value that is correct for the ICM-42688-P

Value	Behaviour
define omitted, or set to 0	Default. BMI270 raw axes are passed through unchanged.
1	BMI270 raw accelerometer and gyro axes are rotated CW90 to match the ICM-42688-P.

The remap is applied inside the BMI270 driver on every raw-read path (register read, DMA read, FIFO read, and the accelerometer), so GYRO_1_ALIGN then describes the board as if an ICM-42688-P were fitted. The define is evaluated with #if, so it must be given a numeric value — #define ENABLE_BMI270_ALIGN_AS_ICM with no value will not compile. It is a build-wide switch and cannot be set per gyro instance.

warning

This flag is off by default so that no existing board changes its frame of reference. Only set it when you have confirmed the resulting orientation on hardware — changing it for an existing board name will silently rotate every user's craft. CW90 versus CW270 is layout dependent, so bench-verify pitch, roll and yaw signs with the BMI270 fitted before shipping a config that sets it. On boards where a BMI270 and a second gyro are fitted and used together, note that the flag rotates every BMI270 in the build — confirm the two gyros still agree.

Available from Betaflight 2026.6.1 onwards (PR #15484).

Other BMI270 constraints that matter when sharing a footprint with the ICM-42688-P:

• Maximum SPI clock is 10 MHz, against 24 MHz for the ICM parts. On a shared-footprint board the bus runs at whichever speed the fitted part allows, so the BMI270 variant gets less headroom for gyro reads than its ICM-42688-P sibling.
• The gyro is limited to a 3.2 kHz sample rate (accelerometer 1.6 kHz), so a BMI270-populated board cannot run the 8 kHz gyro loop its ICM-42688-P sibling can — see 4.1.
• The driver accepts chip ID 0x24 only. Clone or re-marked parts that report anything else are not detected, and the board reports no gyro at all.
• The BMI323 is not supported by Betaflight and cannot be used as a substitute.

This define is the way to second-source a BMI270 on an ICM-42688-P footprint, but it only resolves the footprint and axis mismatch. It does not change the BMI270's status: it is not recommended, and this second-source case is the only one in which it is accepted (see 3.1.2).

4.2.2 Defines for FLASH

Define correct flash driver(s) only if physical present on the board.

#define USE_FLASH_M25P16           // NOR SPI: Micron M25P16 (16Mb/2MB) plus a large JEDEC-ID table of compatible NOR chips incl. Winbond W25Qxx, Macronix, GigaDevice, etc. (https://github.com/betaflight/betaflight/blob/master/src/main/drivers/flash/flash_m25p16.c)
#define USE_FLASH_PY25Q128HA       // 128Mb (16MB) PUYA PY25Q128; alias that enables the M25P16 driver (see common_post.h)
#define USE_FLASH_W25Q128FV        // 128Mb (16MB) Winbond 25Q128 / 16Mb (2MB) 25Q16 (use for QuadSPI / OctoSPI; for standard SPI use USE_FLASH_M25P16)
#define USE_FLASH_W25N             // Winbond W25N NAND family driver (also enable the specific chip define below)
#define USE_FLASH_W25N01G          // 1Gb (128MB) Winbond W25N01G NAND
#define USE_FLASH_W25N02K          // 2Gb (256MB) Winbond W25N02K NAND
#define USE_FLASH_W25M             // Winbond W25M stacked-die driver
#define USE_FLASH_W25M512          // 512Mb (64MB, 256Mb x 2 stacked) NOR
#define USE_FLASH_W25M02G          // 2Gb (256MB, 1Gb x 2 stacked) NAND
#define USE_FLASH_MT29F            // Micron MT29F NAND (1 / 2 / 4Gb, 3.3V and 1.8V variants)
#define USE_FLASH_MX66UW1G45G      // 1Gb (128MB) Macronix MX66UW1G45G OctoSPI NOR (see OctoSPI note below)

The bus interface (USE_FLASH_SPI, USE_FLASH_QUADSPI, USE_FLASH_OCTOSPI) is normally provided by the target platform — enable the per-chip driver above that matches the fitted part. Declare the wiring with FLASH_CS_PIN plus FLASH_SPI_INSTANCE, FLASH_QUADSPI_INSTANCE or FLASH_OCTOSPI_INSTANCE as appropriate.

The USE_FLASH_M25P16 driver carries a large JEDEC ID table that also covers Micron, PUYA, Zbit, Infineon/Cypress S25FL, BergMicro, Boyamicro, XMC, Zetta, FMSH, XTX and Giantec parts, and the USE_FLASH_W25Q128FV, USE_FLASH_PY25Q128HA and USE_FLASH_W25M512 defines imply it. The USE_FLASH_W25N NAND driver likewise covers the Macronix MX35LF2GE4AD as well as the Winbond parts.

OctoSPI/XSPI boot-flash chips (e.g. the Macronix MX66UW1G45G) are not selected with a config.h #define. Instead, set OCTOSPI_FLASH_CHIP := MX66UW1G45G in the target's config.mk; the build emits the matching USE_FLASH_* define automatically (needed for chips that cannot be probed via JEDEC RDID at runtime).

4.2.3 Defines for BARO

Define a barometer only if physical present on the board. Betaflight strongly recommends I2C for barometer connections. The exception is the ST LPS22HB / LPS25 family (USE_BARO_SPI_LPS), which the firmware supports on SPI only.

warning

The chip defines below do not enable the barometer subsystem on their own — unlike the rangefinder defines there is no bottom-up rule. A config that lists a baro chip but not USE_BARO compiles with no barometer driver at all. The same applies to USE_MAG in 4.2.4.

#define USE_BARO
#define USE_BARO_BMP085            // legacy, I2C only (not recommended for new designs)
#define USE_BARO_MS5611
#define USE_BARO_SPI_MS5611
#define USE_BARO_BMP280
#define USE_BARO_SPI_BMP280
#define USE_BARO_BMP388
#define USE_BARO_SPI_BMP388
#define USE_BARO_SPI_LPS           // ST LPS22HB / LPS25 family, SPI only (no I2C variant)
#define USE_BARO_QMP6988
#define USE_BARO_SPI_QMP6988
#define USE_BARO_DPS310            // one driver covers DPS310, DPS368 and SPL07-003 (no separate DPS368 define)
#define USE_BARO_SPI_DPS310
#define USE_BARO_SPA06_003         // SPA06-003; shares the SPL07-003 register map and implies USE_BARO_DPS310
#define USE_BARO_2SMBP_02B
#define USE_BARO_SPI_2SMBP_02B
#define USE_BARO_LPS22DF
#define USE_BARO_SPI_LPS22DF
#define USE_BARO_BMP580
#define USE_BARO_SPI_BMP580
#define USE_BARO_BMP581
#define USE_BARO_SPI_BMP581

The bus and, where needed, the address are declared separately — BARO_I2C_INSTANCE, which must always be given because it falls back to I2C_DEVICE and that is I2CINVALID unless the config defines it, or BARO_SPI_INSTANCE and BARO_CS_PIN for SPI parts, and DEFAULT_BARO_I2C_ADDRESS (decimal) where the fitted part cannot use its default address. DEFAULT_BARO_DEVICE pins which driver is used, and the BMP085 additionally needs BARO_XCLR_PIN.

warning

The BMP580 and BMP581 default to I2C address 0x47 (or 0x46 with SDO low), not the 0x76/0x77 used by most other barometers. Plan the bus accordingly.

Also note that the SPI variants of these two parts (USE_BARO_SPI_BMP580 / USE_BARO_SPI_BMP581) do not currently reach the driver's SPI initialisation in firmware. Use these parts on I2C, which is the recommended connection anyway.

4.2.4 Defines for MAG

Define a magnetometer only if physical present on the board. Betaflight strongly recommends I2C for magnetometer connections.

#define USE_MAG_DATA_READY_SIGNAL
#define USE_MAG_HMC5883
#define USE_MAG_SPI_HMC5883
#define USE_MAG_QMC5883            // hybrid, kept for backwards compatibility (enables both QMC5883L and QMC5883P)
#define USE_MAG_QMC5883L
#define USE_MAG_QMC5883P
#define USE_MAG_LIS2MDL
#define USE_MAG_LIS3MDL
#define USE_MAG_AK8963
#define USE_MAG_MPU925X_AK8963
#define USE_MAG_SPI_AK8963
#define USE_MAG_AK8975
#define USE_MAG_IST8310
#define USE_MAG_MMC560X

For the QMC5883, prefer the chip-specific USE_MAG_QMC5883L or USE_MAG_QMC5883P for the part actually fitted. USE_MAG_QMC5883 is a hybrid define retained for backwards compatibility — the firmware expands it to enable both drivers (see common_post.h) — so existing configs that use it continue to build. Note that the two parts use different default I2C addresses: 0x0D for the QMC5883L and 0x2C for the QMC5883P.

As with the barometer, USE_MAG itself must be defined for any compass driver to be built. The bus is declared with MAG_I2C_INSTANCE, which like the barometer has no usable default and must always be given, or MAG_SPI_INSTANCE and MAG_CS_PIN for an SPI part, and MAG_I2C_ADDRESS (decimal) overrides the address where the default cannot be used. Note the two are distinct: the uppercase MAG_I2C_ADDRESS build define only sets the shipped default for the runtime mag_i2c_address setting, which a user can change from the CLI. So a board fitted with, say, an IST8310 at 0x0C is recoverable in the field with set mag_i2c_address = 12 followed by save, but only if the user knows to do it — see 3.1.3.1 for why the default address is strongly preferred. MAG_INT_EXTI declares a data-ready interrupt pin, which is only used when USE_MAG_DATA_READY_SIGNAL is defined. Board-relative orientation is set with MAG_ALIGN, or per axis with MAG_ALIGN_ROLL / MAG_ALIGN_PITCH / MAG_ALIGN_YAW.

4.2.5 Defines for SX1280

These defines are for existing boards with an onboard SPI ExpressLRS receiver. SPI receivers are not accepted for new designs, see 4.1. For SPI based SX1280 target designs add the following defines. For 900 MHz ExpressLRS hardware based on the SX127x, add USE_RX_SX127X as well (both may be defined for dual-band designs):

#define USE_RX_EXPRESSLRS
#define USE_RX_EXPRESSLRS_TELEMETRY
#define USE_RX_SX1280
#define USE_RX_SX127X
#define RX_CHANNELS_AETR

4.2.6 Defines for OSD

Only for boards with an onboard MAX7456 analogue OSD, which is optional (see 3.1.4.3).

#define USE_MAX7456

4.2.7 Defines for SDCARD

#define USE_SDCARD

4.2.8 Defines for CC2500

This define is for existing boards with an onboard SPI CC2500 receiver. SPI receivers are not accepted for new designs, see 4.1. For SPI based CC2500 target designs add the following define:

#define USE_RX_CC2500

4.2.9 Defines for Rangefinder and Optical Flow

Define these only if the corresponding sensor is physically present on the board.

#define USE_RANGEFINDER
#define USE_RANGEFINDER_HCSR04     // HC-SR04 ultrasonic (GPIO trigger/echo pins)
#define USE_RANGEFINDER_TF         // Benewake TFmini / TF02 / TFnova (UART, LIDAR function)
#define USE_RANGEFINDER_MT         // Micoair MTF-01 / MTF-02 (UART, via MSP; also provides optical flow)
#define USE_RANGEFINDER_NOOPLOOP   // Nooploop TOFSense (UART, LIDAR function)
#define USE_RANGEFINDER_UPT1       // UPT1 (UART, LIDAR function; also provides optical flow)
#define USE_OPTICALFLOW
#define USE_OPTICALFLOW_MT         // Micoair MTF-01 / MTF-02 optical flow (pair with USE_RANGEFINDER_MT)
#define USE_OPTICALFLOW_UPT1       // UPT1 optical flow (pair with USE_RANGEFINDER_UPT1)

4.3 Usage of the Cloud Build API

See reference to cloud build API

4.4 Supported MCU Platforms and Targets

Betaflight is no longer an ST-only firmware. The table below lists every platform in the firmware, the target names accepted as FC_TARGET_MCU in a config.h, and how suitable each is for a new commercial flight controller design. Being buildable is not the same as being recommended: several platforms exist for development work only.

Platform	FC_TARGET_MCU values	Flash	Suitability for new designs
STM32 F4	STM32F411, STM32F405, STM32F446	512 KB / 1 MB / 512 KB	Fine for budget boards and AIOs with 4 motor outputs. More than 4 motors, or F411, is not accepted for new designs
STM32 F7	STM32F722, STM32F745	512 KB / 1 MB	Fine for budget boards and AIOs with 4 motor outputs. More than 4 motors is not accepted for new designs
STM32 G4	STM32G474	512 KB	Preferred for small and budget boards
STM32 H7	STM32H723, STM32H725, STM32H730, STM32H735, STM32H743, STM32H750, STM32H753, STM32H757	1 MB – 2 MB (H730/H750 128 KB internal)	Preferred (H743) for high IO and more than 4 motor outputs
STM32 H5	STM32H562, STM32H563	2 MB	New. Currently excluded from CI, so no official release binaries yet. Talk to the team before designing around it
STM32 C5	STM32C562, STM32C591, STM32C5A3	512 KB – 1 MB	Developer preview. No production flight controllers
STM32 N6	STM32N657	No internal user flash; app lives in external XSPI	Developer preview. Requires a signed first-stage bootloader
AT32	AT32F435G, AT32F435M	1 MB / 4 MB	Preferred for small and budget boards, with flexible DMA routing
APM32	APM32F405, APM32F407, APM32F425, APM32F427	1 MB	Available in firmware, but no official configs exist. Shares the F4 DMA restrictions
PICO	RP2350A, RP2350B	External QSPI, 4 MB / 8 MB	Preferred for small and budget boards. DShot is driven from PIO state machines, not timers
X32	X32M7B	2 MB XIP NOR	Experimental
ESP32	ESP32WROOM, ESP32S3, ESP32C5, ESP32P4	4 MB – 16 MB	Experimental. Excluded from CI, so no official release binaries
SIMULATOR	SITL	n/a	Software simulation only, not hardware

warning

Targets excluded from CI (STM32H562, STM32H563, STM32C591 and all ESP32 variants at the time of writing) produce no official release firmware, because release assets are the CI artifacts. Talk to the Betaflight team before planning a product around one of these.

Practical consequences to design around:

• STM32H730 and STM32H750 have only 128 KB of internal flash. They require an external memory-mapped flash and the EXST (bootloader-relocated) build arrangement, which adds complexity for both you and the end user.
• STM32N657 has no internal user flash at all. The application runs from external XSPI and needs a signed first-stage bootloader.
• STM32H757 is dual core. Betaflight runs standalone on the M7; the M4 is left halted.
• 512 KB is the practical floor. The F722 and G474 targets are already compiled at reduced optimisation to fit 512 KB, which constrains how many features a cloud build can include.
• AT32F435M offers 4 MB of flash against 1 MB on AT32F435G, which matters for feature-rich cloud builds.
• Do not advertise GD32 support. A vendor SDK is present in the tree but there is no GD32 platform.

DMA and DShot behaviour differs by family, which affects pin planning:

Family	DMA routing	DShot default
STM32 F4, F7, APM32 F4	Fixed stream map — plan pin, timer and DMA together	F4 and APM32 F4 only enable bitbang when bidirectional DShot telemetry is enabled; F7 uses bitbang
STM32 G4, H7, H5, C5, N6, AT32F435, X32M7	Flexible (DMAMUX, or GPDMA/LPDMA on H5/C5/N6)	Bitbang
PICO (RP2350)	n/a for motors	Driven from PIO state machines — timer and bitbang guidance does not apply
ESP32	n/a for motors	Platform-specific driver — timer and bitbang guidance does not apply

Gyro external clock input (GYRO_CLKIN) is available on STM32, AT32, RP2350 and X32M7, but not on APM32 or ESP32.

5 Information for Marketing Purposes

• Betaflight is free, open-source flight control software for every kind of drone, from racing and freestyle to cinematic filming, long range, micros and wings.

• The Betaflight name and logos are registered trademarks and may not be used in any commercial products or services without written permission from Betaflight. Using a Betaflight logo on a product requires both that permission and adherence to Betaflight standards, such as the Connector Standard. The exception is the connector logo, which indicates adherence to the Connector Standard and may be used once the Betaflight team has verified that the product meets it.

• Betaflight is a fork of Baseflight and Cleanflight, with an emphasis focused on flight performance, leading-edge feature additions, and wide target support. Combining cutting edge flight performance with diverse hardware support, Betaflight is the leading solution for high performance small unmanned aircraft.

• This project is operated and maintained by volunteers, with community support from pilots with a diverse range of flight goals.

• Pilots flying Betaflight have won every major FAI, MultiGP, and other major FPV multirotor racing event since 2019.