-
Notifications
You must be signed in to change notification settings - Fork 221
new manufacturer WARPLABS and new config file WPLV2 #843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
WalkthroughAdds a new board configuration header for the WPLV2 STM32H743 board defining board identity, enabled hardware features, pin mappings for peripherals (motors, servos, UARTs, SPI, I2C, ADCs, etc.), timer channel mappings, DMA options, and default device instances/settings for firmware integration. Changes
Sequence Diagram(s)(Skipped — changes are a single configuration header without multi-component runtime control-flow changes.) Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ADC2_DMA_OPT 12 | ||
| #define ADC3_DMA_OPT 13 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think ADC2 is required. PC0 can use either of the three ADCs and PC2_C uses ADC3 whereas PC2, which is by default directly connected to PC2_C over an analog switch can also use either three of the ADCs.
| #define ADC2_DMA_OPT 12 | |
| #define ADC3_DMA_OPT 13 | |
| #define ADC3_DMA_OPT 12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh and ADC3 is required for the internal voltage/temperature measurements, so that one needs to have DMA 🙂
Checklist (✓/✕, or y/n)
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.