Skip to content

Conversation

@sugaarK
Copy link
Member

@sugaarK sugaarK commented Nov 21, 2025

adding target for jhemcus f405 wing target. with the speedybee wing fcs not currently in production this will be useful with the upcoming release. its pin for pin with the speedybee wing fc.

I have hardware on hand.

Summary by CodeRabbit

  • New Features
    • Added JHEF405WING flight controller board support (STM32F405 MCU)
    • Includes ICM42688P gyro/accelerometer, DPS310 barometer, SD card, and OSD capabilities
    • Configured for wing and servo platforms with comprehensive UART, SPI, I2C, and ADC mappings

✏️ Tip: You can customize this high-level summary in your review settings.

adding target for jhemcus f405 wing target. with the speedybee wing fcs not currently in production  this will be useful with the upcoming release. its pin for pin with the speedybee wing fc.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 21, 2025

Walkthrough

Adds a new board configuration header file for the JHEF405WING, a Betaflight flight controller based on STM32F405 MCU. Defines target specifications, feature enablement for sensors (ICM42688P gyro/accel, DPS310 barometer, MAX7456 OSD), SD card support, and comprehensive pin mappings for peripherals including motors, servos, UARTs, I2C, SPI, ADC, and system defaults.

Changes

Cohort / File(s) Change Summary
JHEF405WING Board Configuration
configs/JHEF405WING/config.h
New configuration header defining STM32F405-based flight controller with MCU target, board name, manufacturer ID, feature flags for sensors and peripherals, and complete pin/instance mappings for motors, servos, UARTs, I2C, SPI, ADC, and system parameters.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

  • Verify pin assignments for motors, servos, and UARTs are valid and non-conflicting
  • Validate SPI instance mappings (SPI1, SPI2, SPI3) for gyro, SD card, and OSD peripherals
  • Confirm I2C configuration and barometer instance alignment
  • Check TIMER_PIN_MAPPING macro completeness and correctness for all timer-capable pins
  • Cross-reference sensor configurations (ICM42688P alignment, DPS310 I2C instance) with expected hardware layout

Possibly related PRs

  • Add AXISFLYING ARGUS ECO F4 #780: Adds another STM32F405 board config with similar sensor/peripheral macro definitions (ICM42688P, DPS310, MAX7456) and SPI/ADC instance mappings.

Suggested reviewers

  • haslinghuis
  • ot0tot
  • nerdCopter

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description lacks the mandatory checklist and detailed compliance information required by the repository template for new flight controller submissions. Complete the mandatory checklist sections (schematics review, hardware testing, guideline compliance, etc.) and confirm adherence to Betaflight design guidelines and submission requirements.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Jhemcu f405 wing target' clearly describes the main change—adding a new flight controller configuration for the Jhemcu F405 Wing board.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b7efb0d and a5b4d88.

📒 Files selected for processing (1)
  • configs/JHEF405WING/config.h (1 hunks)
🧰 Additional context used
🧠 Learnings (15)
📓 Common learnings
Learnt from: haslinghuis
Repo: betaflight/config PR: 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.
Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.
Learnt from: ot0tot
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.
Learnt from: haslinghuis
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 656
File: configs/IFLIGHT_F745_AIO/config.h:31-35
Timestamp: 2025-07-28T16:44:59.686Z
Learning: In Betaflight board configurations, when a board design uses the same physical gyro socket but different sensor variants across production batches (e.g., MPU6000 in older batches, ICM42688P in newer batches), the correct approach is to enable both sensor drivers (USE_GYRO_SPI_MPU6000 and USE_GYRO_SPI_ICM42688P) in the same configuration. This allows runtime auto-detection of which sensor is actually present without requiring separate board configurations for each hardware variant.
Learnt from: haslinghuis
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-07-14T16:16:56.822Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-07-03T15:17:30.040Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 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.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-06-23T18:43:31.746Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-08-22T17:08:23.283Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-09-26T16:32:46.694Z
Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-09-26T16:32:46.694Z
Learning: When reviewing hardware configuration files like Betaflight configs, always check for pin assignment conflicts by verifying that no physical pins (like PB10, PB11, etc.) are assigned to multiple peripheral functions simultaneously.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-08-10T14:08:56.662Z
Learnt from: blckmn
Repo: betaflight/config PR: 851
File: configs/HELLBENDER_0001/config.h:45-46
Timestamp: 2025-08-10T14:08:56.662Z
Learning: In Betaflight, USE_LED_STRIP is a cloud build option that enables/disables the LED strip feature at build time. Individual target config files (configs/*/config.h) only need to define LED_STRIP_PIN as a default pin assignment - they should not define USE_LED_STRIP themselves. The feature enablement is handled externally through the cloud build system, not through preprocessor directives in the config files.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-06-23T18:44:59.162Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 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.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 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/JHEF405WING/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.

Applied to files:

  • configs/JHEF405WING/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
Repo: betaflight/config PR: 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/JHEF405WING/config.h
🔇 Additional comments (7)
configs/JHEF405WING/config.h (7)

24-27: LGTM! Board identification is correct.

The BOARD_NAME correctly matches the directory name (JHEF405WING), and the target MCU and manufacturer ID are properly defined.


29-45: LGTM! Feature enablement is appropriate.

The feature flags correctly enable the ICM42688P gyro/accelerometer, DPS310 barometer, MAX7456 OSD, and SD card support. The use of ifndef guards for USE_WING and USE_SERVOS properly allows build-time control while ensuring these critical features for wing configurations are enabled by default.


47-47: LGTM! Dshot configuration is appropriate.

Setting DEFAULT_DSHOT_BITBANG to DSHOT_BITBANG_OFF is suitable for this 2-motor wing configuration, as hardware timer support is sufficient.


93-103: Timer pin mapping looks correct; verify DMA stream assignments.

The timer pin mappings appear valid for STM32F405:

  • Motors (PB6/PB7) map to TIM4_CH1/CH2
  • Servos map to TIM3, TIM8, TIM12, and TIM2
  • LED strip (PA8) maps to TIM1_CH1

All servo outputs correctly use DMA option -1 (no DMA needed for standard PWM). Motors and LED strip use DMA option 0. While they're on different physical timers (TIM4 for motors, TIM1 for LED strip), verify that the DMA streams don't conflict, particularly if blackbox logging via SPI is also active.

Based on learnings


105-124: System defaults are well-configured; verify hardware-specific calibration values.

The system configuration is appropriate:

  • Valid SERIAL_PORT_USART1 identifier for SERIALRX
  • SPI instance assignments correctly match their CS pins
  • I2C peripherals (magnetometer and barometer) properly configured on I2CDEV_1
  • Blackbox correctly defaults to SD card
  • PID loop denominator of 2 is typical for STM32F405

However, hardware-specific values should be verified with the actual board:

  • DEFAULT_CURRENT_METER_SCALE of 195 should match the current sensor hardware
  • GYRO_1_ALIGN CW270_DEG should match the physical gyro orientation on the PCB

Can you confirm these values were tested with the actual hardware you have on hand?


49-91: Pin assignments verified—no issues found.

The UART pin assignments in the config match standard STM32F405 mappings confirmed across similar boards in the codebase. UART4 and UART5 pin assignments were confirmed via the script output (both matching expected pins). All 43 pin assignments are unique with no hardware conflicts.

Note: PA13 (LED1) and PA14 (LED0) are SWD debug interface pins. This reflects the actual board hardware design, which cannot be changed after production, per established Betaflight board configuration constraints.


1-124: Pin-for-pin compatibility with SpeedyBee Wing FC is verified.

Comparison of JHEF405WING and SPEEDYBEEF405WING configurations confirms that all physical pin assignments are identical for motors, servos, UARTs, SPI, ADC, I2C, and other peripherals. The configurations match line-for-line for all hardware pinouts. The only differences are the board name, manufacturer ID, and sensor support options (SPEEDYBEE supports additional gyro and barometer variants), which are firmware/driver features rather than pin layout differences.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

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.

1 participant