Skip to content

Conversation

ot0tot
Copy link
Contributor

@ot0tot ot0tot commented May 14, 2025

Summary by CodeRabbit

  • New Features
    • Added support for the AXISFLYINGECOF4 flight controller board with full hardware configuration.
    • Enabled onboard sensors and peripherals: accelerometer, gyroscope, dual barometers, flash logging, and OSD.
    • Provided comprehensive pin and peripheral mappings, default system parameters, and peripheral instance assignments for the new board.

Co-authored-by: Mark Haslinghuis <[email protected]>
Copy link
Contributor

coderabbitai bot commented May 19, 2025

Walkthrough

Adds a new board configuration header for AXISFLYINGECOF4 that defines MCU, board identifiers, enabled sensors/peripherals, detailed pin mappings, timer-to-pin mappings, ADC/I2C/SPI instances, and several default system macros.

Changes

Cohort / File(s) Change Summary
New board config
configs/AXISFLYINGECOF4/config.h
Added a complete board-specific configuration header: sets FC_TARGET_MCU, BOARD_NAME, MANUFACTURER_ID; enables sensors (ICM42688P accel/gyro, BMP280/DPS310 baro), FLASH (M25P16), MAX7456 OSD; defines beeper, motor, servo, LED, camera, UART, I2C, SPI, ADC, CS pins; TIMER_PIN_MAPPING; ADC/I2C/SPI instance selections; default blackbox, meter, beeper, and clock macros; PINIO box settings and user box name.

Sequence Diagram(s)

sequenceDiagram
    participant Firmware
    participant BoardConfig as ConfigHeader
    participant MCU_Hardware as Hardware

    Firmware->>BoardConfig: Include and read macros
    BoardConfig-->>Firmware: Provide pin maps, peripheral & sensor selections
    Firmware->>MCU_Hardware: Initialize clocks, timers, GPIO, SPI, I2C, ADC, UART per config
    MCU_Hardware-->>Firmware: Peripheral ready / interrupts configured
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

Suggested reviewers

  • nerdCopter
  • blckmn

Poem

"I nibble pins and map each wire,
A tiny hop to make things fly higher.
Macros set, timers sing, motors hum true,
AXISFLYINGECOF4 — take off, woo-hoo! 🐰🚀"

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
configs/AXISFLYINGECOF4/config.h (4)

1-21: Include SPDX license identifier
Adding an SPDX tag (// SPDX-License-Identifier: GPL-3.0-or-later) at the top complements the existing GPL header and helps automated tooling recognize the license.


28-37: Clarify barometer support and sensor grouping
You’ve enabled both BMP280 and DPS310 barometer macros—confirm that the board has two separate barometers or a shared bus. If only one is populated, remove the unused USE_BARO_* macro. Also consider adding comment headers to group ACC, GYRO, BARO, FLASH, and OSD feature macros.


39-76: Group related pin definitions with comments
For readability and maintainability, add comment headers (e.g., // Motors, // Servos, // UART, // I2C) above each block of pin definitions so others can quickly locate and modify sections.


102-102: Remove or document commented-out alignment macro
The //#define GYRO_1_ALIGN CW180_DEG line is left in but inactive. Either delete it or add a TODO explaining when/why it should be enabled.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 01685cd and ea4b94e.

📒 Files selected for processing (1)
  • configs/AXISFLYINGECOF4/config.h (1 hunks)
🔇 Additional comments (7)
configs/AXISFLYINGECOF4/config.h (7)

22-22: Verify include-guard style consistency
This file uses #pragma once. Please confirm that existing Betaflight config headers adopt #pragma once rather than traditional #ifndef/​#define/​#endif guards to maintain consistency.


24-26: Validate target MCU and board identifiers
Ensure that FC_TARGET_MCU = STM32F405, BOARD_NAME = AXISFLYINGECOF4, and MANUFACTURER_ID = AXFL match the naming conventions and exact device part numbers used across the codebase (e.g., STM32F405RG vs. generic STM32F405).


77-85: Validate timer-to-pin mapping accuracy
Please confirm that each TIMER_PIN_MAP entry correctly maps the chosen pin to the intended timer instance and channel on the STM32F405. A mis-map here could disable PWM outputs.


87-96: Verify ADC and I²C instance selections
Double-check that ADC3 supports channels on PC1/PC2 (VBAT/CURR) and that both barometer and magnetometer can share I2CDEV_1 without bus conflicts.


97-100: Confirm pin-IO box configuration and user name
Ensure that PINIO1_BOX = 40, PINIO1_CONFIG = 129, and BOX_USER1_NAME = "VTX PWR" correctly represent the hardware wiring and UI label.


104-104: FLASH_SPI_INSTANCE defined correctly
Defining FLASH_SPI_INSTANCE as SPI3 satisfies the earlier suggestion and matches the hardware wiring for the M25P16 flash chip.


39-76:

✅ Verification successful

Verify unique and conflict-free pin assignments
Conflicting pin definitions can cause hardware collisions. Run this script to detect duplicate _PIN values in this file:


🏁 Script executed:

#!/bin/bash
# Detect duplicate pin assignments
awk '/#define .*_PIN/ {print $2, $3}' configs/AXISFLYINGECOF4/config.h | sort | uniq -d

Length of output: 89


No duplicate pin assignments detected
Verified with the provided script—there are no conflicting _PIN definitions in configs/AXISFLYINGECOF4/config.h.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
configs/AXISFLYINGECOF4/config.h (1)

101-103: SPI instance assignments look correct (gyro SPI1, OSD SPI2, flash SPI3)

The SPI instance layout matches common F405 designs and addresses the prior suggestion to place flash on SPI3.

🧹 Nitpick comments (2)
configs/AXISFLYINGECOF4/config.h (2)

28-38: Barometer drivers: consider trimming to the actual onboard sensor to save flash

Both BMP280 and DPS310 are enabled. If the production board only ships with one of these parts, consider enabling just that driver to reduce binary size and potential probe ambiguity. If different batches ship with either, keeping both is fine.

Optionally narrow to a single baro (example keeping DPS310):

 #define USE_BARO
-#define USE_BARO_BMP280
 #define USE_BARO_DPS310

If BMP280 is the one actually used, invert the change accordingly.


28-31: Gyro/acc alignment not specified — confirm default orientation

No explicit GYRO_1_ALIGN/ACC_1_ALIGN is set; default is CW0_DEG. Please confirm the ICM42688P physical orientation on this board. If CW0_DEG is correct, we can keep it implicit or define it explicitly for clarity.

I can add the explicit macro once you confirm:

 #define USE_GYRO
 #define USE_GYRO_SPI_ICM42688P
+// Uncomment if you want to document the verified physical orientation explicitly:
+//#define GYRO_1_ALIGN CW0_DEG
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ea4b94e and 233212c.

📒 Files selected for processing (1)
  • configs/AXISFLYINGECOF4/config.h (1 hunks)
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-14T16:16:56.822Z
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-14T16:16:50.628Z
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:29-35
Timestamp: 2025-07-14T16:16:50.628Z
Learning: CW0_DEG is not a universal default gyro alignment setting in Betaflight configurations. Different boards use different gyro alignments (CW0_DEG, CW90_DEG, CW180_DEG, CW270_DEG, CW0_DEG_FLIP, etc.) based on their physical sensor mounting orientation.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-05-31T17:01:39.423Z
Learnt from: haslinghuis
PR: betaflight/config#798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0) 
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-14T15:41:14.364Z
Learnt from: ot0tot
PR: betaflight/config#834
File: configs/RADIOLINKF405/config.h:79-88
Timestamp: 2025-07-14T15:41:14.364Z
Learning: In STM32F405 configurations, PB1 typically maps to TIM3_CH4 and PC9 typically maps to TIM8_CH4. These are different timers and do not share DMA resources, so there is no conflict when both pins are used simultaneously (e.g., PB1 for LED_STRIP and PC9 for MOTOR4).

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-06-23T18:43:31.746Z
Learnt from: haslinghuis
PR: betaflight/config#822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines (like ESC_SENSOR_UART, MSP_UART, GPS_UART, etc.) use valid SERIAL_PORT identifiers that match those defined in the Betaflight codebase at src/main/io/serial.h. Common valid identifiers include SERIAL_PORT_USART1, SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, etc. Invalid identifiers like SERIAL_PORT_UART3 (should be SERIAL_PORT_USART3) will cause build failures.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines use valid identifiers from the serialPortIdentifier_e enum in src/main/io/serial.h. Valid identifiers include: SERIAL_PORT_USB_VCP (20), SERIAL_PORT_SOFTSERIAL1 (30), SERIAL_PORT_SOFTSERIAL2 (31), SERIAL_PORT_LPUART1 (40), SERIAL_PORT_UART0 (50, if SERIAL_UART_FIRST_INDEX == 0), SERIAL_PORT_USART1 (51 or 50), SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, SERIAL_PORT_USART6, SERIAL_PORT_USART7, SERIAL_PORT_USART8, SERIAL_PORT_UART9, SERIAL_PORT_USART10. While some aliases exist (like SERIAL_PORT_UART3 = SERIAL_PORT_USART3), prefer using the primary identifiers as referenced in the serialPortIdentifiers array to avoid build failures.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: For Betaflight configurations, blackbox logging via SPI3 and LED_STRIP functionality can be mutually exclusive due to DMA stream conflicts on STM32F4 targets. This hardware limitation should be identified during timer configuration reviews.

Applied to files:

  • configs/AXISFLYINGECOF4/config.h
🔇 Additional comments (3)
configs/AXISFLYINGECOF4/config.h (3)

24-27: BOARD_NAME matches directory name — good catch and LGTM

Verified BOARD_NAME equals the containing directory (AXISFLYINGECOF4). This ensures proper board detection and config loading in Betaflight.


48-56: UART2 TX is not defined — verify hardware intent

Only UART2_RX_PIN (PA3) is defined; UART2_TX_PIN is absent. If this is intentional (e.g., dedicated SBUS input with no TX routed), all good. If TX is available on the board, add its pin (commonly PA2 on STM32F405).


77-86: Verify TIMER_PIN_MAPPING indices and default Blackbox device

Please double-check the following before merging:

• Confirm that each TIMER_PIN_MAP entry in configs/AXISFLYINGECOF4/config.h (PC6, PC7, PC8, PC9, PB10, PB11, PB6, PB0) corresponds to a valid “fullTimerHardware” index and channel in your timer mapping implementation (e.g. src/platform/STM32/timer_stm32f4xx.c).
• This board does not override DEFAULT_BLACKBOX_DEVICE, so it will use the global default (usually BLACKBOX_DEVICE_SDCARD or FLASH depending on your target). Verify that driving the LED strip on PB6 (TIM4_CH1 with DMA) does not collide with the DMA stream used for your Blackbox interface (SDIO or SPI3).

@haslinghuis haslinghuis requested a review from nerdCopter August 19, 2025 16:35
@haslinghuis haslinghuis merged commit 0a79266 into betaflight:master Aug 22, 2025
2 checks passed
This was referenced Aug 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants