Add HGLRCF435_AIO board #884
Conversation
WalkthroughAdds a new board configuration header for HGLRCF435_AIO that maps MCU/board IDs, enables sensors/peripherals (ICM42688P accel/gyro, DPS310 baro, W25Q128 flash, MAX7456 OSD), assigns GPIO/UART/I2C/SPI/ADC pins, timer mappings, defaults, alignment/yaw, and UART inverter. Changes
Sequence Diagram(s)sequenceDiagram
participant FC as Flight Controller (AT32F435G)
participant IMU as ICM42688P (SPI1)
participant BARO as DPS310 (I2C2)
participant Flash as W25Q128FV (SPI3)
participant OSD as MAX7456 (SPI2)
participant ESCs as Motors / DSHOT
Note over FC: configs/HGLRCF435_AIO/config.h maps pins & timers
FC->>IMU: init SPI1 (SCK/SDI/SDO), CS=`PA4`, INT=`PC14`
alt Use GYRO CLKIN
FC->>IMU: provide GYRO clock via `PB2`
end
FC->>BARO: init I2C2 (BARO/MAG on `PA0/PA1`)
FC->>Flash: init SPI3, CS=`PA15`
FC->>OSD: init SPI2, CS=`PB12`
FC->>ESCs: drive motors via timers mapped to `PB6/PB7/PB8/PB9` or DSHOT bitbang
FC->>FC: ADC1 reads VBAT=`PB0` & Current=`PB1`
Note right of FC: TIMER_PIN_MAPPING routes timers to LED_STRIP, motors, GYRO_CLKIN
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks (2 passed, 1 warning)❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
configs/HGLRCF435_AIO/config.h (3)
39-42: Heads-up: LEDs on SWD pins (PA13/PA14) can disrupt debuggingUsing PA13/PA14 (SWDIO/SWCLK) for LED0/LED1 may break live SWD sessions once firmware reconfigures these as GPIOs. If this matches the physical board, keep it, but please add a short comment noting the SWD interaction so future maintainers aren’t surprised.
Apply this small annotation:
-#define LED0_PIN PA13 -#define LED1_PIN PA14 +#define LED0_PIN PA13 // Note: SWDIO; will disable live SWD once FW runs +#define LED1_PIN PA14 // Note: SWCLK; will disable live SWD once FW runs
92-98: Consider AUTO for DSHOT bitbang defaultHard-forcing DSHOT_BITBANG_ON can raise CPU load and reduce flexibility across ESC protocols. AUTO lets Betaflight choose the optimal mode per timer/DMA capabilities at runtime.
Apply:
-#define DEFAULT_DSHOT_BITBANG DSHOT_BITBANG_ON +#define DEFAULT_DSHOT_BITBANG DSHOT_BITBANG_AUTO
39-91: General pin sanity check helper (optional)If helpful, add this as a CI helper to flag reused pins across board configs. It avoids subtle wiring conflicts when iterating on layouts.
I can open a small PR with a script that scans all configs/*/config.h for duplicate *_PIN assignments and reports them in CI. Want me to proceed?
📜 Review details
Configuration used: Path: .coderabbit.yaml
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.
📒 Files selected for processing (1)
configs/HGLRCF435_AIO/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
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.
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#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.
📚 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/HGLRCF435_AIO/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 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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
PR: betaflight/config#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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-26T14:26:11.819Z
Learnt from: haslinghuis
PR: betaflight/config#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.819Z
Learning: For AT32F435 in Betaflight, UART4 supports multiple pin options including PH2 (UART4_RX) and PH3 (UART4_TX) with GPIO_MUX_8, as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c. The AT32 platform has broader pin support than initially apparent from basic searches.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-26T14:26:11.819Z
Learnt from: haslinghuis
PR: betaflight/config#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.819Z
Learning: For AT32F435 in Betaflight, UART4 can use PH2 (UART4_RX) and PH3 (UART4_TX) as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c lines 183-212. This is a valid pin mapping for the AT32F435 platform.
Applied to files:
configs/HGLRCF435_AIO/config.h
🔇 Additional comments (12)
configs/HGLRCF435_AIO/config.h (12)
26-28: BOARD_NAME/dir match and manufacturer ID look correctDirectory name and BOARD_NAME match exactly; MANUFACTURER_ID follows the 4-char convention. No action needed.
29-38: Peripheral enable set looks saneACC/GYRO ICM42688P over SPI, DPS310 over I2C, W25Q128 flash, and MAX7456 OSD are consistent choices. Nothing to change.
50-57: UART mappings look correct; UART4 on PH2/PH3 is supported on AT32F435UART1/2/3 pins are standard. The UART4 mapping to PH2/PH3 is valid on AT32F435 per Betaflight’s AT32 serial mapping. No change needed.
78-83: MAX7456 on SPI2 and flash on SPI3: good splitSeparating OSD and flash across SPI2/SPI3 is sensible to reduce bus contention. Looks good.
99-101: Default 45° board yaw: confirm physical orientationA default 45° yaw is unusual but valid if the IMU is physically rotated. Please confirm this matches production hardware silk/installation, otherwise consider omitting this to avoid surprising users flashing the target onto other frames.
102-105: Inverter pin and SERIALRX UART look correctPC13 as inverter control and SERIALRX on USART2 match common SBUS setups. Identifier SERIAL_PORT_USART2 is valid per Betaflight’s serialPortIdentifier_e.
43-47: MOTOR/LED/DMA Configuration Sanity Check
Duplicate PIN Definitions
The provided duplicate-pin detection script exits zero regardless of whether duplicates exist, so it always prints “DUPLICATES FOUND.” Manually inspecting the defines inconfigs/HGLRCF435_AIO/config.hshows no overlaps:
• MOTOR1_PIN = PB6
• MOTOR2_PIN = PB7
• MOTOR3_PIN = PB8
• MOTOR4_PIN = PB9
• LED_STRIP_PIN = PA8
• GYRO_CLKIN_PIN = PB2To properly flag duplicates, you can use this corrected script:
#!/usr/bin/env bash set -euo pipefail # collect all *_PIN values mapfile -t pins < <( rg -nP '^\s*#\s*define\s+\w+_PIN\s+\w+' configs/HGLRCF435_AIO/config.h \ | awk '{print $3}' ) # find duplicates dup=$(printf '%s\n' "${pins[@]}" | sort | uniq -d) if [ -n "$dup" ]; then echo "Duplicate pins detected: $dup" exit 1 else echo "No duplicate pins." fiTimer-Pin Mapping
TIMER_PIN_MAP(0, MOTOR1_PIN, 4, 1) TIMER_PIN_MAP(1, MOTOR2_PIN, 4, 2) TIMER_PIN_MAP(2, MOTOR3_PIN, 4, 3) TIMER_PIN_MAP(3, MOTOR4_PIN, 4, 4) TIMER_PIN_MAP(4, LED_STRIP_PIN, 1, 1) TIMER_PIN_MAP(5, GYRO_CLKIN_PIN,2, 4)This splits the four motors onto TIM4 CH1–4, the WS2812 LED strip on TIM1 CH1, and the gyro clock input on TIM2 CH4—consistent with the AT32F435 GPIO-timer mappings in the reference tables.
DMA Stream Conflicts
You still need to confirm that the DMA channels/streams used by:
- TIM4 (for DSHOT)
- TIM1 (for LED strip)
do not overlap with those allocated to SPI3 or ADC on your AT32F435 target. In the platform code (e.g. undersrc/platform/AT32F4/), grep forSPI3andADCDMA registrations and ensure each peripheral has a distinct stream/channel.No further pin or timer mapping changes are required provided there are no DMA collisions.
87-91: ADC1 DMA Configuration Requires Manual VerificationThe automated environment couldn’t confirm that
ADC1_DMA_OPT 11is both valid for the AT32F435’s ADC1 driver and free of conflicts with other DMA users (DSHOT, SPI3 for blackbox, etc.). Likewise, please ensure that PB0/PB1 are correctly mapped to ADC1 channels on AT32F435.• Manually inspect
src/platform/AT32/adc_at32f43x.c(or similar) in the Betaflight core to verify that DMA option 11 corresponds to the intended DMA controller/stream/channel for ADC1.
• Cross-reference all other active DMA_OPT values (e.g., for DSHOT, SPI DMA) to confirm no overlap in stream or channel assignments.
• Confirm PB0 and PB1 are defined as analog inputs for ADC1 (e.g.,ADC_CHANNEL_8/ADC_CHANNEL_9or equivalent) in the AT32 pin-to-channel mapping.Once confirmed, update or document any necessary changes to avoid runtime DMA conflicts.
62-71: Verify DMA channel assignments for SPI3 vs. timer-driven outputs on AT32F435I wasn’t able to pull in the AT32 core files to auto-validate the DMA mappings, so please manually confirm that SPI3’s RX/TX DMA channels or streams don’t collide with the DMA used by your motor outputs (DSHOT) or the LED strip. On the AT32F435 platform these mappings live in the core’s
platform/AT32directory—typically in files likespi_at32f43x.cand whichever module implements timer DMA for PWM or LED bitbang.Suggested manual checks:
- In
platform/AT32/spi_at32f43x.c(or similarly named), locate the definitions for SPI3’s DMA channel/stream (e.g.,DMA_CHANNEL_SPI3_RX/DMA_CHANNEL_SPI3_TX).- In the timer/PWM implementation for AT32F435 (often in
timer_at32f43x.corpwm_at32f43x.c), find the DMA channels/streams used for TIM1/TIM4 (or whichever timers drive DSHOT/LED).- Verify that those timer DMA assignments do not share the same channel or stream numbers as SPI3’s DMA.
- If you spot a conflict, consider remapping the LED strip or choosing an alternate timer/DMA configuration to avoid clashes.
59-61: I2C2 PA0/PA1 mapping is valid (AF = GPIO_MUX_4) — no change requiredVerified in the Betaflight AT32 platform code: I2CDEV_2 lists PA0 (SCL) and PA1 (SDA) with GPIO_MUX_4.
- configs/HGLRCF435_AIO/config.h — I2C2_SCL_PIN = PA0, I2C2_SDA_PIN = PA1 (lines ~59–61).
- bfcore/src/platform/AT32/bus_i2c_atbsp_init.c — I2CDEV_2 entry contains I2CPINDEF(PA0, GPIO_MUX_4) for SCL and I2CPINDEF(PA1, GPIO_MUX_4) for SDA.
No further action required; you can resolve this review.
72-77: Please verify AT32F435 EXTI and timer mappings for gyro pinsI wasn’t able to locate explicit PC14 or PB2 entries in the AT32 platform code, so please confirm that:
- GYRO_1_EXTI_PIN (PC14) is correctly handled by the EXTI setup in the AT32 code (e.g. in your EXTI implementation under src/platform/AT32/…, ensure EXTI line 14 is mapped to port C).
- GYRO_CLKIN_PIN (PB2) is present in the timer-pin mapping for TIM2 CH4 (e.g. via TIMER_PIN_MAP or pinMapTimer in src/platform/AT32/timer_at32f43x.c) and that USE_GYRO_CLKIN enables that channel on AT32F435.
No code changes here—just a sanity check that the generic EXTI and timer-pin tables include PC14 and PB2 → TIM2_CH4.
24-24: AT32F435G MCU macro and PH2/PH3 UART4 support verifiedThe Betaflight AT32 serial driver (src/platform/AT32/serial_uart_at32f43x.c) includes PH2 and PH3 as valid RX/TX pins for UART4 when the AT32F435 family is selected, which covers the AT32F435G variant. The FC_TARGET_MCU macro in your config (
#define FC_TARGET_MCU AT32F435G) therefore aligns with the core platform code’s family handling and enables Port H access without further changes.• No changes required to
configs/HGLRCF435_AIO/config.h
• The existingAT32F435GMCU target macro is correct and fully supported by the Betaflight core
• UART4 pin mappings (PH2, PH3) have been confirmed in the serial driver under the AT32F435 branch [run_scripts output]
|
Ready to review~ |
|
Thanks. @haslinghuis |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
configs/HGLRCF435_AIO/config.h (2)
26-26: Quick policy check: BOARD_NAME vs directory name.This is a recurring source of build issues. Confirmed this PR adheres to the rule (BOARD_NAME equals directory name). Thanks for following the convention.
50-58: Serial port identifier sanity check.SERIALRX_UART uses SERIAL_PORT_USART2 (primary identifier) — this avoids alias pitfalls like SERIAL_PORT_UART3 and is in line with Betaflight’s enum usage guidance.
🧹 Nitpick comments (2)
configs/HGLRCF435_AIO/config.h (2)
39-42: LEDs on PA13/PA14 may impact SWD; confirm this matches shipped hardware.PA13/PA14 are SWDIO/SWCLK on most MCUs. Using them for LEDs can interfere with in-circuit debugging unless jumpers or bootstrap timing mitigate it. If this reflects production hardware, it’s acceptable per Betaflight policy; just confirm no developer expectations around SWD during bring-up.
92-98: Defaults look reasonable; consider revisiting DSHOT bitbang default.DSHOT_BITBANG_ON is safe but can cost cycles. If hardware timers + DMA fully cover motor outputs on this target, DSHOT_BITBANG_OFF may save CPU. Optional only.
📜 Review details
Configuration used: Path: .coderabbit.yaml
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.
📒 Files selected for processing (1)
configs/HGLRCF435_AIO/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
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.
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: ot0tot
PR: betaflight/config#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
PR: betaflight/config#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: 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#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
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.
📚 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/HGLRCF435_AIO/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 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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
PR: betaflight/config#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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-26T14:26:11.819Z
Learnt from: haslinghuis
PR: betaflight/config#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.819Z
Learning: For AT32F435 in Betaflight, UART4 supports multiple pin options including PH2 (UART4_RX) and PH3 (UART4_TX) with GPIO_MUX_8, as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c. The AT32 platform has broader pin support than initially apparent from basic searches.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-26T14:26:11.819Z
Learnt from: haslinghuis
PR: betaflight/config#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.819Z
Learning: For AT32F435 in Betaflight, UART4 can use PH2 (UART4_RX) and PH3 (UART4_TX) as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c lines 183-212. This is a valid pin mapping for the AT32F435 platform.
Applied to files:
configs/HGLRCF435_AIO/config.h
🔇 Additional comments (14)
configs/HGLRCF435_AIO/config.h (14)
26-27: BOARD_NAME matches directory; manufacturer ID looks correct.BOARD_NAME equals HGLRCF435_AIO and matches the directory name; MANUFACTURER_ID HGLR aligns with HGLRC. No action needed.
29-38: Sensor/peripheral enables are coherent.ICM42688P on SPI1, DPS310 on I2C, W25Q128, and MAX7456 are a common combo; dual ACC/GYRO driver enables support runtime detection if needed. Looks consistent.
43-48: Motor pin choices look fine; verify actual timer resources behind PB6–PB9.PB6–PB9 commonly map to the same motor timer block family; you chose mixed timer-index values in TIMER_PIN_MAPPING (see below). Please ensure these selections map to distinct channels on the same timer group as intended (or to compatible groups for DSHOT).
Use the timer map check below (see the TIMER_PIN_MAPPING comment) to validate.
62-71: SPI buses and CS pins look standard; check that all three buses coexist without DMA conflicts.SPI1 (gyro), SPI2 (MAX7456), SPI3 (flash) with PA4/PB12/PA15 CS is a conventional split and helps bandwidth. Just verify DMA channels used by these instances don’t clash with the motor timer DMA and ADC DMA in this target.
Use the DMA/timer resource audit below (see TIMER_PIN_MAPPING) and confirm SPI DMA assignments in src/platform/AT32/spi_at32f43x.c.
78-83: MAX7456 and FLASH bus split is good for contention; no issues.Separate SPI instances for OSD and flash reduce bus contention, particularly during OSD heavy load + blackbox writes. Looks solid.
84-86: I2C instance ties for BARO and MAG are consistent.Both set to I2CDEV_2 which matches the SCL/SDA above. No action needed.
99-101: Default yaw = 45°: confirm the hardware IMU orientation really requires this.Non-90° default yaw is uncommon but valid if the sensor is physically rotated. Please confirm production hardware matches this alignment; otherwise consider leaving yaw at 0 and documenting the rotation for users.
102-105: Inverter control for UART2 + SERIALRX on USART2 is consistent.Good pairing for SBUS/IBUS scenarios; identifier SERIAL_PORT_USART2 is correct per Betaflight enums.
87-91: Confirm ADC1 DMA request mapping and channel usage
I wasn’t able to locate DMA-request definitions for ADC1 in the AT32 platform code. Please verify thatADC1_DMA_OPT = 11is a valid DMA request line for ADC1 on your target MCU and that the chosen analog channels (PB0for VBAT,PB1for current sense) map to ADC1 channels without overlapping other DMA-mapped peripherals (e.g., SPI, timers).• File:
configs/HGLRCF435_AIO/config.h, lines 87–91
• Confirm in the vendor reference manual that DMA option 11 corresponds to ADC1’s DMA request
• EnsurePB0/PB1map to the correct ADC1 analog channels and aren’t shared with conflicting peripherals
106-112: Manual Verification Required: AT32 Timer & DMA MappingI was unable to locate the AT32 timer (
timer_at32f43x.c) or SPI (spi_at32f43x.c) implementation files in the codebase. Before merging, please manually verify:
- That each
TIMER_PIN_MAPPINGentry inconfigs/HGLRCF435_AIO/config.h(PA8, PB6, PB7, PB8, PB9, PB2) corresponds to a validDEF_TIM(...)in the AT32 timer driver.- That DMA streams for:
- LED_STRIP (TIMx)
- Motors 1–4 (TIMx)
- Blackbox SPI (likely SPI3)
- ADC1
do not overlap, to avoid conflicts on the AT32F43x DMA controller.
72-77: Verify PB2 Timer Alternate Function for Gyro CLKINI wasn’t able to locate a timer-pin mapping for PB2 in our AT32 timer drivers, so please manually confirm that PB2 supports the required timer channel for the gyro CLKIN signal:
- Consult the AT32F435 datasheet (or your MCU’s reference manual) to identify which timer and channel PB2 can be aliased to.
- Verify in your HAL or timer-configuration files (e.g. in the
timer_at32…source) that PB2 is listed with the correct alternate-function mapping for that timer channel.- If PB2 isn’t supported, choose a different GPIO that has a valid timer-alt AF for CLKIN and update
GYRO_CLKIN_PINaccordingly.File: configs/HGLRCF435_AIO/config.h
Lines: 72–77#define GYRO_1_CS_PIN PA4 #define GYRO_1_EXTI_PIN PC14 #define GYRO_1_SPI_INSTANCE SPI1 #define USE_GYRO_CLKIN #define GYRO_CLKIN_PIN PB2
24-24: Verify AT32 MCU token spellingI wasn’t able to locate the AT32 platform headers in this branch (they live in a submodule that isn’t checked out in the sandbox). Please double-check that the token in your board config exactly matches what the AT32 build expects:
- configs/HGLRCF435_AIO/config.h:24
#define FC_TARGET_MCU AT32F435G- In the AT32 platform code (submodule), search for the MCU macro—ensure you see
#define FC_TARGET_MCU AT32F435G(and not e.g.AT32F435Gx).A mismatch here will cause the AT32 build to fail.
50-58: Approve UART pin configuration for HGLRCF435_AIOAll defined UART pins align with the official AT32F435 mappings in Betaflight’s platform code (serial_uart_at32f43x.c, lines 183–212).
- UART1: PA9 (TX) / PA10 (RX)
- UART2: PA2 (TX) / PA3 (RX)
- UART3: PB10 (TX) / PB11 (RX)
- UART4: PH3 (TX) / PH2 (RX)
Good inclusion of an external inverter on UART2 for SBUS.
59-61: Verify AT32 I2C2 PA0/PA1 pin assignmentThis configuration enables I2C2 on PA0 (SCL) and PA1 (SDA). The configs repository doesn’t include the AT32 I2C driver mappings, so please manually confirm that PA0/PA1 are valid alternate-function pins for I2C2 on the AT32F435 MCU.
• Review the AT32 I2C pin table in the main Betaflight source (e.g.
platform/AT32/i2c_at32f43x.c) to ensure entries exist for PA0 → I2C2_SCL and PA1 → I2C2_SDA with the correct GPIO_MUX setting.
• Alternatively, consult the AT32F435 datasheet’s I2C2 pin multiplexing section to verify PA0/PA1 support.File: configs/HGLRCF435_AIO/config.h Lines 59–61
|
Is there anything else I need to do? |
HGLRC-T
force-pushed
the
HGLRCF435_AIO
branch
from
49276ba to
2c2f1eb
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
configs/HGLRCF435_AIO/config.h (1)
29-34: Sensor set OK; consider dual-variant gyro support only if applicable.If production batches used different gyro variants on same pad, enable both drivers for auto-detect; otherwise keep as-is.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
-
configs/HGLRCF435_AIO/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
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.
Learnt from: haslinghuis
PR: betaflight/config#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
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#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: ot0tot
PR: betaflight/config#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
PR: betaflight/config#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-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/HGLRCF435_AIO/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 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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
PR: betaflight/config#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/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
PR: betaflight/config#888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-09-01T19:58:52.049Z
Learnt from: haslinghuis
PR: betaflight/config#881
File: configs/GEPRC_TAKER_H743MINI/config.h:86-99
Timestamp: 2025-09-01T19:58:52.049Z
Learning: For STM32H743 PB0 in Betaflight, there are three timer options: TIM1_CH2N, TIM3_CH3, and TIM8_CH2N. Only TIM3_CH3 (timer index 2) is suitable for GYRO_CLKIN as the other two are complementary (N) channels. This is confirmed in timer_stm32h7xx.c.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-09-01T19:58:52.049Z
Learnt from: haslinghuis
PR: betaflight/config#881
File: configs/GEPRC_TAKER_H743MINI/config.h:86-99
Timestamp: 2025-09-01T19:58:52.049Z
Learning: For STM32H743 in Betaflight, PB0 has multiple timer options but only timer index 2 provides a non-complementary output suitable for GYRO_CLKIN functionality. The other timer options for PB0 are N channels (complementary outputs) which are not appropriate for CLKIN usage.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-06-08T22:02:28.961Z
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.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-05-28T15:45:15.608Z
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.
Applied to files:
configs/HGLRCF435_AIO/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
PR: betaflight/config#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/HGLRCF435_AIO/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/HGLRCF435_AIO/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/HGLRCF435_AIO/config.h
🔇 Additional comments (12)
configs/HGLRCF435_AIO/config.h (12)
26-27: BOARD_NAME matches directory — good.Correct per our review rule.
39-42: LEDs on PA13/PA14 (SWD pins) — verify debug usability.If the hardware really wires LEDs to SWDIO/SWCLK, keep as-is (matches production), but confirm SWD attach remains possible during bring-up.
Note: Our prior learning says configs must match physical boards even if debug-hostile.
102-104: Serial RX on USART2 with inverter pin — looks correct.Consistent with typical SBUS wiring (USART2 + external inverter control).
35-37: Confirm flash variant (W25Q128FV vs W25Q128JV)configs/HGLRCF435_AIO/config.h (lines 35–37) currently defines USE_FLASH_W25Q128FV — verify the actual flash part on the BOM/board or by reading the JEDEC ID; if the board ships the JV variant, change to USE_FLASH_W25Q128JV to avoid JEDEC-ID mismatches.
56-57: Incorrect — UART4 PH3/PH2 are valid on AT32F435; no change required.
AT32 UART4 supports PH2/PH3 (see platform mapping serial_uart_at32f43x.c) and multiple F435 configs in this repo use PH3/PH2 (configs/HGLRCF435_AIO, ORBITF435, IFLIGHT_BORG_F435S).Likely an incorrect or invalid review comment.
24-24: FC_TARGET_MCU token is correct — use AT32F435GRepo search shows boards use AT32F435G for G-series (and AT32F435M for M-series); no bare AT32F435 tokens found — leave AT32F435G in configs/HGLRCF435_AIO/config.h.
99-101: Confirm DEFAULT_ALIGN_BOARD_YAW — 45° looks incorrectIf the PCB/gyro is not intentionally rotated 45° in the frame, change DEFAULT_ALIGN_BOARD_YAW to 0; otherwise attach an assembly/PCB photo or schematic showing the 45° rotation. Location: configs/HGLRCF435_AIO/config.h (around line 100: #define DEFAULT_ALIGN_BOARD_YAW 45).
105-111: ```shell
#!/bin/bash
set -euo pipefailecho "PWD: $(pwd)"
echo
echo "Top-level listing:"
ls -laecho
echo "Check for configs path and the specific file:"
if [ -d "configs" ]; then
echo "configs directory exists — listing:"
ls -la configs | sed -n '1,200p'
else
echo "configs directory not found"
fiecho
echo "Try printing the reviewed file if present:"
if [ -f "configs/HGLRCF435_AIO/config.h" ]; then
echo "Found configs/HGLRCF435_AIO/config.h — printing head:"
sed -n '1,240p' configs/HGLRCF435_AIO/config.h
else
echo "configs/HGLRCF435_AIO/config.h not found"
fiecho
echo "Search repo for timer/mapping/LED/motor pins and dma mentions:"
rg -n --hidden -S 'TIMER_PIN_MAP|TIMER_PIN_MAPPING|LED_STRIP_PIN|LED_STRIP|MOTOR[1-8]_PIN|GYRO_1_CLKIN_PIN' || true
rg -n --hidden -S -nP '\bdma\b|\bDMA\b|DMA1|DMA2|DMA_Stream|dma pin' || trueecho
echo "List any config.h files under configs (first 120 lines each):"
for f in$(rg -n --hidden --files configs | rg 'config.h$ ' || true); do
echo "==== $f ===="
sed -n '1,120p' "$f" || true
done--- `81-83`: **SPI3 on PB3/PB4/PB5 w/ CS=PA15 — mapping valid but check JTAG/SWO.** AT32F435 IOMUX supports SPI3 on PB3/PB4/PB5 with NSS=PA15; PB3/PB4 are JTDO/JNTRST (debug pins, AF at reset) — disable/remap SWJ (or use the PC10/11/12 SPI3 alternative / gpio_pin_remap) in board bring‑up so the flash SPI will work. ([manualslib.com](https://www.manualslib.com/manual/2940050/Artery-At32f435-Series.html?utm_source=openai)) --- `87-91`: **Confirm ADC1 DMA option (ADC1_DMA_OPT = 11) is correct for AT32F435 and doesn't conflict.** configs/HGLRCF435_AIO/config.h:88 sets ADC1_DMA_OPT to 11; many other F435 boards in the repo also use 11, but I could not find the DMA-option→stream mapping in the sources to confirm 11 maps to a valid ADC1 DMA request for the AT32F435 or that it doesn't collide with timers/SPI — verify against the target's DMA/DMAMUX mapping (or run `dma show` on the board). --- `59-61`: **I2C2 on PA0/PA1 — double-check alternate mapping.** Unusual mapping for “I2C2”; confirm the at32 I2C pinmap supports PA0/PA1 for I2CDEV_2. If not, pick a supported pair and ensure no clashes with UART2/ADC. Script: --- `72-77`: **GYRO CLKIN on PB2 — verify AT32F435G routing & PC14 EXTI** configs/HGLRCF435_AIO/config.h sets GYRO_1_CLKIN_PIN = PB2 and maps it with TIMER_PIN_MAP(..., 2, -1) (config.h lines ~72–77 and TIMER_PIN_MAPPING ~105–111). I could not find AT32 timer/CLKIN routing code in the repo to confirm PB2→CLKIN on the AT32F435G — verify PB2 supports the CLKIN alternate-function/timer route on the AT32F435G and that PC14 is actually wired to the ICM42688P INT on the board schematic. If unsupported, move the CLKIN pin to a supported pin or update TIMER_PIN_MAPPING. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
|
@haslinghuis This should not have been merged as it has not passed schematic review. |
|
@ot0tot sorry thought it was ready as there was no update in a week. Should we revert or fix ? |
Was waiting for manufacturer reply. Lets revert for now, as changes are required. |
This reverts commit 6ce96c9.
Summary by CodeRabbit