Skip to content

HUMMINGBIRD AIO 255 UART Definition Fix #831

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

LYNHQQ
Copy link
Contributor

@LYNHQQ LYNHQQ commented Jul 11, 2025

UART7 has an incorrect default configuration. It should not be set to ESC telemetry by default. Please remove this default.

Summary by CodeRabbit

  • New Features
    • Added support for the HUMMINGBIRD_AIO255 flight controller board, including hardware configuration for sensors, flash memory, OSD, motor outputs, LEDs, UARTs, I2C, SPI, and ADC inputs.
    • Enabled compatibility with specific sensors (ICM42688P), multiple flash chips, and the MAX7456 OSD.
    • Default settings for blackbox logging, voltage/current sensing, and other peripherals are now included for this board.

Copy link

coderabbitai bot commented Jul 11, 2025

Walkthrough

A new configuration header file for the HUMMINGBIRD_AIO255 flight controller board has been added. This file defines the MCU, board identifiers, supported sensors, peripheral pin assignments, timer mappings, communication bus instances, and default device settings for integration with the Betaflight firmware.

Changes

File(s) Change Summary
configs/HUMMINGBIRD_AIO255/config.h Added new board configuration header for HUMMINGBIRD_AIO255, specifying MCU, sensors, pin mappings, timers, buses, and default values

Sequence Diagram(s)

sequenceDiagram
    participant Betaflight as Betaflight Firmware
    participant Config as HUMMINGBIRD_AIO255 config.h
    participant MCU as AT32F435G
    participant Sensors as ICM42688P, Flash, OSD, etc.

    Betaflight->>Config: Load board-specific macros and settings
    Config->>MCU: Set target MCU and system clock
    Config->>Sensors: Enable/assign sensors and peripherals (Gyro, Accelerometer, Flash, OSD)
    Config->>Betaflight: Provide pin mappings, timers, bus assignments
    Betaflight->>MCU: Initialize hardware according to config.h
    Betaflight->>Sensors: Communicate via assigned pins/buses
Loading

Possibly related PRs

  • betaflight/config#793: Adds a new configuration header for a different flight controller board with similar structure and purpose.
  • betaflight/config#805: Adds configuration for another HUMMINGBIRD board with similar MCU and sensor setup but different pin assignments.
  • betaflight/config#806: Adds the same configuration header for HUMMINGBIRD_AIO255, indicating a direct overlap.

Suggested reviewers

  • haslinghuis
  • sugaarK

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b33c306 and e2568de.

📒 Files selected for processing (1)
  • configs/HUMMINGBIRD_AIO255/config.h (1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 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 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#0
File: :0-0
Timestamp: 2025-07-03T15:17:30.040Z
Learning: In Betaflight configurations, when a target name suggests dual IMUs (like JHEF7DUAL) but specific hardware variants only have one gyro available, the preferred solution is to use DEFAULT_GYRO_TO_USE macro to specify which gyro to use by default rather than pruning gyro defines or creating redundant configurations. This approach maintains compatibility when the same target is used by multiple hardware variants from the same manufacturer.
Learnt from: haslinghuis
PR: betaflight/config#822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.
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: 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.
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.
Learnt from: haslinghuis
PR: betaflight/config#829
File: configs/HELLBENDER_0001/config.h:53-56
Timestamp: 2025-07-08T22:26:29.867Z
Learning: In Betaflight configurations, SDCARD_CS_PIN and FLASH_CS_PIN can share the same GPIO pin because Betaflight uses either flash or sdcard storage, not both simultaneously. This is a mutually exclusive design where only one storage method is active at a time, so shared CS pin assignments are intentional and do not cause conflicts.
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.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/FLYWOOF411/config.h:33-33
Timestamp: 2025-05-28T15:48:18.449Z
Learning: The FLYWOOF411 board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It was incorrectly targeted for GYRO_COUNT and dual gyro support.
Learnt from: haslinghuis
PR: betaflight/config#814
File: configs/JHEF405PRO/config.h:109-109
Timestamp: 2025-06-08T22:02:28.961Z
Learning: The JHEF405PRO board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It should not receive GYRO_COUNT or other dual-gyro related definitions since only the first gyro is supported.
configs/HUMMINGBIRD_AIO255/config.h (13)
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: 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: 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.
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T15:17:30.040Z
Learning: In Betaflight configurations, when a target name suggests dual IMUs (like JHEF7DUAL) but specific hardware variants only have one gyro available, the preferred solution is to use DEFAULT_GYRO_TO_USE macro to specify which gyro to use by default rather than pruning gyro defines or creating redundant configurations. This approach maintains compatibility when the same target is used by multiple hardware variants from the same manufacturer.
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.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/FLYWOOF411/config.h:33-33
Timestamp: 2025-05-28T15:48:18.449Z
Learning: The FLYWOOF411 board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It was incorrectly targeted for GYRO_COUNT and dual gyro support.
Learnt from: haslinghuis
PR: betaflight/config#822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
Learnt from: haslinghuis
PR: betaflight/config#814
File: configs/JHEF405PRO/config.h:109-109
Timestamp: 2025-06-08T22:02:28.961Z
Learning: The JHEF405PRO board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It should not receive GYRO_COUNT or other dual-gyro related definitions since only the first gyro is supported.
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.
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
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/MERAKRCF722/config.h:32-32
Timestamp: 2025-05-28T15:45:15.608Z
Learning: The presence of GYRO_2_SPI_INSTANCE definition in a board config does not necessarily mean the board uses dual gyros. Some boards have GYRO_2_SPI_INSTANCE defined but it's not actually used, so they should not receive GYRO_COUNT or other dual-gyro related definitions. Only boards that actually utilize dual gyros should get these definitions.
🔇 Additional comments (7)
configs/HUMMINGBIRD_AIO255/config.h (7)

25-26: BOARD_NAME matches directory structure correctly.

The board name "HUMMINGBIRD_AIO255" correctly matches the directory path "configs/HUMMINGBIRD_AIO255", ensuring proper board identification in Betaflight.


28-31: Single gyro configuration is correctly implemented.

The ICM42688P gyro configuration is properly set up with both accelerometer and gyroscope support via SPI, with no dual gyro complications.


52-52: UART7 configuration addresses the PR objective.

UART7 only has RX pin defined with no TX pin or ESC telemetry default setting. This aligns with the PR objective to remove UART7 ESC telemetry default configuration.


69-72: Flash and MAX7456 CS pins are properly isolated.

Good separation of chip select pins: FLASH_CS_PIN (PC15) and MAX7456_SPI_CS_PIN (PA8) are on different pins, preventing conflicts between flash storage and OSD functionality.


86-96: SPI instance assignments are logically distributed.

SPI instances are well distributed: SPI2 for MAX7456 OSD, SPI3 for flash storage, and SPI4 for gyro sensor. This separation helps avoid bus conflicts and allows concurrent peripheral operations.


98-99: PINIO1 configuration values are correct
The settings match other Betaflight boards that use PINIO1 for VTX power switching (CONFIG 129 for active-low 10 V enable, BOX 40 for the “User 1” OSD box). No changes required.


74-79: Verify AT32F435G DMA‐stream conflicts in TIMER_PIN_MAPPING

Please double-check that assigning LED_STRIP_PIN to TIM1_CH0 (timer 0 → 1,0) and motors 1–4 to timers 1–4 in configs/HUMMINGBIRD_AIO255/config.h does not overlap with DMA streams used by SPI3 (blackbox) or the LED-strip driver on the AT32F435G. In particular:

• Confirm LED_STRIP_PIN → TIM1_CH0 uses a DMA channel/stream that isn’t shared by SPI3_RX/TX DMA.
• Verify motor outputs on TIM1–TIM4 don’t collide with the TIM1_CH0 DMA or any SPI3 DMA streams.
• Compare with other AT32F435G boards (e.g. configs/BETAFPVF435, configs/DARWINF435, configs/NEUTRONRCF435SE) to ensure their LED-strip and SPI3 mappings coexist.

✨ Finishing Touches
  • 📝 Generate Docstrings

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.
    • Explain this complex logic.
    • 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. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • 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 src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

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

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary or `` 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.

Documentation and Community

  • 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
Member

@haslinghuis haslinghuis left a comment

Choose a reason for hiding this comment

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

Need to resolve conflicts (rebase on master)

@LYNHQQ
Copy link
Contributor Author

LYNHQQ commented Jul 14, 2025

需要解决冲突(在 master 上变基)

Thank you for your reminder, I have merged the latest master branch

@LYNHQQ LYNHQQ requested a review from haslinghuis July 14, 2025 02:02
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.

2 participants