Add JHEF435PRO #902
Open
Add JHEF435PRO #902
+103
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WalkthroughAdds a new Betaflight board configuration header for JHEF435PRO (MCU AT32F435G) defining board identity, enabled sensors/peripherals (ICM42688P via SPI, gyro CLKIN, DPS310 baro, W25Q128FV flash, MAX7456 OSD), detailed pin/timer/UART/I2C/SPI mappings, ADC/DMA, defaults, alignments, and board flags. Changes
Sequence Diagram(s)(omitted — change is a static board configuration header without runtime control-flow modifications) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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}
ot0tot
reviewed
Sep 14, 2025
ot0tot
reviewed
Sep 14, 2025
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
configs/JHEF435PRO/config.h (1)
49-49: CLKIN vs LED_STRIP timer conflict resolvedLED_STRIP on TMR4 (PB6) and CLKIN on TMR1 (PA8) avoid the earlier same‑timer conflict. Good change.
Also applies to: 77-84
🧹 Nitpick comments (2)
configs/JHEF435PRO/config.h (2)
79-84: Add brief comments to TIMER_PIN_MAPPING for readabilityDocument which indices map to LED strip, motors, and CLKIN.
Apply:
-#define TIMER_PIN_MAPPING TIMER_PIN_MAP(0, PB6, 1, 0) \ +#define TIMER_PIN_MAPPING /* 0: LED_STRIP (TMR4_CH1 PB6) */ \ + TIMER_PIN_MAP(0, PB6, 1, 0) \ TIMER_PIN_MAP(1, PA0, 1, 0) \ TIMER_PIN_MAP(2, PA1, 1, 1) \ TIMER_PIN_MAP(3, PA2, 1, 2) \ TIMER_PIN_MAP(4, PA3, 1, 3) \ - TIMER_PIN_MAP(8, PA8, 1, -1) + /* 8: GYRO_1_CLKIN (TMR1_CH1 PA8) */ \ + TIMER_PIN_MAP(8, PA8, 1, -1)
102-105: Document PINIO1 config bits and BOX mappingPINIO1_CONFIG = 129 (0x81) = PINIO_CONFIG_OUT_INVERTED (0x80) | PINIO_CONFIG_MODE_OUT_PP (0x01) — active‑low push‑pull; PINIO1_BOX = 40 is the permanent BOX ID for USER1 (appears as USER1 in Configurator). (betaflight.com)
-#define PINIO1_CONFIG 129 +#define PINIO1_CONFIG 129 /* 129 (0x81) = PINIO_CONFIG_OUT_INVERTED(0x80) | PINIO_CONFIG_MODE_OUT_PP(0x01) — active-low push-pull */Optional: add an inline comment to PINIO1_BOX to note 40 = USER1.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/JHEF435PRO/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (15)
📓 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: 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#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: 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#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#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#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#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.863Z
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.
Learnt from: haslinghuis
PR: betaflight/config#719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T20:06:07.492Z
Learning: BMP280 and DPS310 barometer drivers in Betaflight do not require USE_I2C to be explicitly defined in board configurations. Out of 264 boards using these drivers, 259 (98%) work without USE_I2C defined, indicating that the I2C dependency is handled automatically by the build system.
📚 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/JHEF435PRO/config.h
📚 Learning: 2025-07-14T16:16:56.822Z
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: For Betaflight configurations, blackbox logging via SPI3 and LED_STRIP functionality can be mutually exclusive due to DMA stream conflicts on STM32F4 targets. This hardware limitation should be identified during timer configuration reviews.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
📚 Learning: 2025-07-03T15:17:30.040Z
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.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
🔇 Additional comments (7)
configs/JHEF435PRO/config.h (7)
26-27: BOARD_NAME/manufacturer match — OK
BOARD_NAMEmatches the directory name andMANUFACTURER_IDlooks consistent.
36-41: Baro/flash selections look correctDPS310 and W25Q128FV are enabled as expected. No explicit USE_I2C macro is required for DPS310.
59-60: I2C2 on PH2/PH3 — OKPH2/PH3 mapping for I2C2 aligns with AT32F435 support.
61-69: SPI layout is sane; note SWO overlapSPI3 on PB3/PB4/PB5 shares PB3 with SWO. Fine for production, but debugging via SWO won’t be available.
Please confirm you don’t rely on SWO on this target during bring‑up.
Also applies to: 73-74
89-95: Defaults look reasonable for this targetFlash blackbox and DSHOT bitbang by default make sense for AT32F435.
86-88: Confirm ADC1 DMA option — platform mapping missing in this checkoutADC1_DMA_OPT is defined as 8 in JHEF435PRO (and many other configs), but this checkout does not contain the platform ADC/DMA mapping (no src/platform/AT32), so I cannot confirm that value 8 maps to a supported DMA stream/channel for the AT32F435 — verify that ADC1_DMA_OPT==8 selects a valid DMA stream/channel in the platform ADC/DMA mapping (e.g., platform/AT32/dma.c or adc.c).
51-57: Cannot verify UART5 PB9/PB8 mapping — AT32 driver missingserial_uart_at32f43x.c is not present in this repository; configs (e.g. configs/JHEF435PRO/config.h lines ~53–57) set UART5_TX=PB9 and UART5_RX=PB8. Confirm PB9/PB8 are supported for UART5 in the AT32 platform driver (upstream serial_uart_at32f43x.c) or add the driver mapping here so it can be verified.
ot0tot
reviewed
Sep 17, 2025
ot0tot
reviewed
Sep 17, 2025
ot0tot
reviewed
Sep 17, 2025
Co-authored-by: ot0tot <[email protected]>
Co-authored-by: ot0tot <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
configs/JHEF435PRO/config.h (1)
76-83: CLKIN moved off TIM4; timer conflict resolved.GYRO_1_CLKIN on PA8 (TIM1) and LED_STRIP on PB6 (TIM4) removes the same‑timer frequency conflict noted earlier. TIMER_PIN_MAPPING aligns with the prior suggestion.
🧹 Nitpick comments (1)
configs/JHEF435PRO/config.h (1)
49-56: Define UART2_RX_PIN for consistency (disable both directions).UART2_TX_PIN is NONE but UART2_RX_PIN isn’t defined. Define RX as NONE too to avoid partially‑defined UART2 and potential auto‑port registration quirks.
Apply this diff:
#define UART1_TX_PIN PA9 // TMR1_CH2 / SPI2_SCK / USART1_TX / I2C1_SCL -#define UART2_TX_PIN NONE +#define UART2_TX_PIN NONE +#define UART2_RX_PIN NONE #define UART3_TX_PIN PB10 // TMR2_CH3 / I2C2_SCL / SPI2_SCK / USART3_TX
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/JHEF435PRO/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (17)
📓 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: haslinghuis
PR: betaflight/config#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.863Z
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.
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#883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.863Z
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.
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: 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#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.
📚 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/JHEF435PRO/config.h
📚 Learning: 2025-07-14T16:16:56.822Z
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: For Betaflight configurations, blackbox logging via SPI3 and LED_STRIP functionality can be mutually exclusive due to DMA stream conflicts on STM32F4 targets. This hardware limitation should be identified during timer configuration reviews.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
📚 Learning: 2025-07-03T15:17:30.040Z
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.
Applied to files:
configs/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/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/JHEF435PRO/config.h
🔇 Additional comments (4)
configs/JHEF435PRO/config.h (4)
24-28: Board identity looks correct.BOARD_NAME matches the directory (JHEF435PRO) and MCU is set to AT32F435G. LGTM.
58-59: I2C2 on PH2/PH3: valid mapping on AT32F435.Using PH2/PH3 for I2C2 is supported on AT32F435 and avoids contention with your chosen UARTs. LGTM.
85-87: Confirm ADC DMA option.ADC1_DMA_OPT is 8; please confirm this matches the intended DMA stream on AT32F435 and doesn’t collide with SPI2/SPI3 DMA used by MAX7456/FLASH at runtime.
94-97: Orientation sanity check.GYRO_1_ALIGN CW180_DEG plus DEFAULT_ALIGN_BOARD_YAW -45 implies effective board/IMU orientation. Please confirm this matches silkscreen arrow and field tests.
ot0tot
approved these changes
Sep 17, 2025
blckmn
approved these changes
Sep 18, 2025
haslinghuis
added
Awaiting prototype samples
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
Summary by CodeRabbit