new manufacturer WARPLABS and new config file WPLV2 #843
Conversation
WalkthroughA new configuration header file for the WPLV2 board with STM32H743 MCU has been added. This file defines macros for board identification, enabled hardware features, pin assignments, peripheral instances, timer mappings, DMA options, and default settings, providing a hardware abstraction layer for firmware integration with the board's peripherals. Changes
Sequence Diagram(s)sequenceDiagram
participant Firmware
participant BoardConfig (config.h)
participant Hardware
Firmware->>BoardConfig: Read board macros and pin assignments
BoardConfig->>Firmware: Provide feature enables, pin mappings, peripheral instances
Firmware->>Hardware: Initialize peripherals (gyro, flash, baro, UARTs, etc.) using config
Hardware-->>Firmware: Peripherals ready for operation
Estimated code review effort1 (~2 minutes) Possibly related PRs
Suggested labels
Suggested reviewers
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
configs/WPLV2/config.h (1)
90-93: UnnecessaryGYRO_2_SPI_INSTANCEentry may mis-signal dual-gyro supportThe board only exposes one ICM42688P. Defining
GYRO_2_SPI_INSTANCEimplies two sensors and can enable dead code paths (e.g.GYRO_COUNT = 2) unless additional macros override it (seeDEFAULT_GYRO_TO_USE,GYRO_COUNT).
Either remove this define or add the customary:#define GYRO_COUNT 1to avoid accidental dual-gyro configuration.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/WPLV2/config.h(1 hunks)
🧠 Learnings (2)
📓 Common learnings
Learnt from: ot0tot
PR: betaflight/config#681
File: configs/NYX405V1/config.h:26-28
Timestamp: 2025-07-14T15:47:16.394Z
Learning: In Betaflight configuration files, MANUFACTURER_ID values must be exactly 4 ASCII characters long, not 3 characters. All manufacturer IDs in the codebase consistently use 4-character identifiers like AIRB, FOSS, SPBE, MTKS, NERC, etc.
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Learnt from: haslinghuis
PR: betaflight/config#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: 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).
Learnt from: haslinghuis
PR: betaflight/config#798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0)
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c
Learnt from: 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#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#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
configs/WPLV2/config.h (13)
Learnt from: haslinghuis
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
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: 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#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: #792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
PR: #792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Learnt from: haslinghuis
PR: #792
File: configs/FLYWOOF411/config.h:33-33
Timestamp: 2025-05-28T15:48:18.449Z
Learning: The FLYWOOF411 board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It was incorrectly targeted for GYRO_COUNT and dual gyro support.
Learnt from: haslinghuis
PR: #822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.
Learnt from: haslinghuis
PR: #798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0)
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c
Learnt from: ot0tot
PR: #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).
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.
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ot0tot
PR: betaflight/config#681
File: configs/NYX405V1/config.h:26-28
Timestamp: 2025-07-14T15:47:16.394Z
Learning: In Betaflight configuration files, MANUFACTURER_ID values must be exactly 4 ASCII characters long, not 3 characters. All manufacturer IDs in the codebase consistently use 4-character identifiers like AIRB, FOSS, SPBE, MTKS, NERC, etc.
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Learnt from: haslinghuis
PR: betaflight/config#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: 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).
Learnt from: haslinghuis
PR: betaflight/config#798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0)
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c
Learnt from: 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#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#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
PR: betaflight/config#792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
configs/WPLV2/config.h (13)
Learnt from: haslinghuis
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
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: 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#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: #792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
PR: #792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Learnt from: haslinghuis
PR: #792
File: configs/FLYWOOF411/config.h:33-33
Timestamp: 2025-05-28T15:48:18.449Z
Learning: The FLYWOOF411 board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It was incorrectly targeted for GYRO_COUNT and dual gyro support.
Learnt from: haslinghuis
PR: #822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.
Learnt from: haslinghuis
PR: #798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0)
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c
Learnt from: ot0tot
PR: #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).
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.
🔇 Additional comments (1)
configs/WPLV2/config.h (1)
5-7: ✅ BOARD_NAME / MANUFACTURER_ID look correct
BOARD_NAMEmatches the directory (WPLV2) andMANUFACTURER_IDis four ASCII chars as required.
No action needed.
| #define VTX_ENABLE_PIN PE3 | ||
| #define PINIO1_PIN VTX_ENABLE_PIN | ||
| #define PINIO1_BOX 40 | ||
| #define PINIO1_CONFIG 129 | ||
| #define PINIO2_PIN PE4 | ||
| #define PINIO2_BOX 40 | ||
| #define PINIO2_CONFIG 1 | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Duplicate BOX id for two distinct PINIOs
PINIO1_BOX and PINIO2_BOX are both set to 40.
Betaflight uses these IDs as array indices; duplicating them causes the second PINIO to be ignored at runtime.
Consider assigning the next free user-box (41) to PINIO2_BOX.
-#define PINIO2_BOX 40
+#define PINIO2_BOX 41🤖 Prompt for AI Agents
In configs/WPLV2/config.h around lines 75 to 82, the BOX ID for PINIO2_BOX is
duplicated as 40, the same as PINIO1_BOX, which causes runtime conflicts. Change
the value of PINIO2_BOX from 40 to 41 to assign a unique BOX ID and avoid the
array index collision.
| #define TIMER_PIN_MAPPING \ | ||
| TIMER_PIN_MAP( 0, MOTOR1_PIN, 1, 0 ) /* TIM1 CH1 */ \ | ||
| TIMER_PIN_MAP( 1, MOTOR2_PIN, 1, 1 ) /* TIM1 CH2 */ \ | ||
| TIMER_PIN_MAP( 2, MOTOR3_PIN, 1, 2 ) /* TIM1 CH3 */ \ | ||
| TIMER_PIN_MAP( 3, MOTOR4_PIN, 1, 3 ) /* TIM1 CH4 */ \ | ||
| TIMER_PIN_MAP( 4, MOTOR5_PIN, 2, 4 ) /* TIM8 CH1 */ \ | ||
| TIMER_PIN_MAP( 5, MOTOR6_PIN, 2, 5 ) /* TIM8 CH2 */ \ | ||
| TIMER_PIN_MAP( 6, MOTOR7_PIN, 2, 6 ) /* TIM8 CH3 */ \ | ||
| TIMER_PIN_MAP( 7, MOTOR8_PIN, 2, 7 ) /* TIM8 CH4 */ \ | ||
| TIMER_PIN_MAP( 8, LED_STRIP_PIN, 1, 8 ) /* TIM2 CH1 */ \ | ||
| TIMER_PIN_MAP( 9, BEEPER_PIN, 1, -1 ) /* TIM4 CH1 */ \ | ||
| TIMER_PIN_MAP( 10, SERVO1_PIN, 1, -1 ) /* TIM15 CH1 */ \ | ||
| TIMER_PIN_MAP( 11, SERVO2_PIN, 1, -1 ) /* TIM15 CH2 */ | ||
| TIMER_PIN_MAP( 12, GYRO_1_CLKIN_PIN, 2, -1 ) /* TIM5 CH1 */ |
There was a problem hiding this comment.
Missing back-slash breaks the TIMER_PIN_MAPPING macro
Line 107 lacks a trailing \, so the macro terminates before the TIM5 entry.
TIMER_PIN_MAP( 12 … ) (line 108) then appears as free-standing code and will trigger a preprocessing/compilation error.
- TIMER_PIN_MAP( 11, SERVO2_PIN, 1, -1 ) /* TIM15 CH2 */
- TIMER_PIN_MAP( 12, GYRO_1_CLKIN_PIN, 2, -1 ) /* TIM5 CH1 */
+ TIMER_PIN_MAP( 11, SERVO2_PIN, 1, -1 ) /* TIM15 CH2 */ \
+ TIMER_PIN_MAP( 12, GYRO_1_CLKIN_PIN, 2, -1 ) /* TIM5 CH1 */📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #define TIMER_PIN_MAPPING \ | |
| TIMER_PIN_MAP( 0, MOTOR1_PIN, 1, 0 ) /* TIM1 CH1 */ \ | |
| TIMER_PIN_MAP( 1, MOTOR2_PIN, 1, 1 ) /* TIM1 CH2 */ \ | |
| TIMER_PIN_MAP( 2, MOTOR3_PIN, 1, 2 ) /* TIM1 CH3 */ \ | |
| TIMER_PIN_MAP( 3, MOTOR4_PIN, 1, 3 ) /* TIM1 CH4 */ \ | |
| TIMER_PIN_MAP( 4, MOTOR5_PIN, 2, 4 ) /* TIM8 CH1 */ \ | |
| TIMER_PIN_MAP( 5, MOTOR6_PIN, 2, 5 ) /* TIM8 CH2 */ \ | |
| TIMER_PIN_MAP( 6, MOTOR7_PIN, 2, 6 ) /* TIM8 CH3 */ \ | |
| TIMER_PIN_MAP( 7, MOTOR8_PIN, 2, 7 ) /* TIM8 CH4 */ \ | |
| TIMER_PIN_MAP( 8, LED_STRIP_PIN, 1, 8 ) /* TIM2 CH1 */ \ | |
| TIMER_PIN_MAP( 9, BEEPER_PIN, 1, -1 ) /* TIM4 CH1 */ \ | |
| TIMER_PIN_MAP( 10, SERVO1_PIN, 1, -1 ) /* TIM15 CH1 */ \ | |
| TIMER_PIN_MAP( 11, SERVO2_PIN, 1, -1 ) /* TIM15 CH2 */ | |
| TIMER_PIN_MAP( 12, GYRO_1_CLKIN_PIN, 2, -1 ) /* TIM5 CH1 */ | |
| #define TIMER_PIN_MAPPING \ | |
| TIMER_PIN_MAP( 0, MOTOR1_PIN, 1, 0 ) /* TIM1 CH1 */ \ | |
| TIMER_PIN_MAP( 1, MOTOR2_PIN, 1, 1 ) /* TIM1 CH2 */ \ | |
| TIMER_PIN_MAP( 2, MOTOR3_PIN, 1, 2 ) /* TIM1 CH3 */ \ | |
| TIMER_PIN_MAP( 3, MOTOR4_PIN, 1, 3 ) /* TIM1 CH4 */ \ | |
| TIMER_PIN_MAP( 4, MOTOR5_PIN, 2, 4 ) /* TIM8 CH1 */ \ | |
| TIMER_PIN_MAP( 5, MOTOR6_PIN, 2, 5 ) /* TIM8 CH2 */ \ | |
| TIMER_PIN_MAP( 6, MOTOR7_PIN, 2, 6 ) /* TIM8 CH3 */ \ | |
| TIMER_PIN_MAP( 7, MOTOR8_PIN, 2, 7 ) /* TIM8 CH4 */ \ | |
| TIMER_PIN_MAP( 8, LED_STRIP_PIN, 1, 8 ) /* TIM2 CH1 */ \ | |
| TIMER_PIN_MAP( 9, BEEPER_PIN, 1, -1 ) /* TIM4 CH1 */ \ | |
| TIMER_PIN_MAP( 10, SERVO1_PIN, 1, -1 ) /* TIM15 CH1 */ \ | |
| TIMER_PIN_MAP( 11, SERVO2_PIN, 1, -1 ) /* TIM15 CH2 */ \ | |
| TIMER_PIN_MAP( 12, GYRO_1_CLKIN_PIN, 2, -1 ) /* TIM5 CH1 */ |
🤖 Prompt for AI Agents
In configs/WPLV2/config.h around lines 95 to 108, the TIMER_PIN_MAPPING macro is
broken because line 107 is missing a trailing backslash. Add a backslash at the
end of line 107 to properly continue the macro definition onto line 108 and
prevent preprocessing or compilation errors.
| #ifndef USE_OSD_HD | ||
| #define USE_OSD_HD | ||
| #endif | ||
|
|
||
| #define USE_LED_STRIP | ||
|
|
There was a problem hiding this comment.
LED_STRIP and OSD are user build options.
| #ifndef USE_OSD_HD | |
| #define USE_OSD_HD | |
| #endif | |
| #define USE_LED_STRIP | |
| #define USE_BARO |
|
|
||
| #define DEFAULT_FEATURES (FEATURE_OSD | FEATURE_LED_STRIP) | ||
|
|
||
| #define MSP_DISPLAYPORT_UART SERIAL_PORT_USART2 |
There was a problem hiding this comment.
| #define MSP_DISPLAYPORT_UART SERIAL_PORT_USART2 | |
| #ifdef USE_OSD_HD | |
| #define MSP_DISPLAYPORT_UART SERIAL_PORT_USART2 | |
| #endif |
Checklist (✓/✕, or y/n)
Summary by CodeRabbit