-
Notifications
You must be signed in to change notification settings - Fork 185
Add ZEX_ATHENA_STD_PRO #870
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 Betaflight board configuration header for ZEX_ATHENA_STD_PRO (STM32H743) defining MCU/board metadata, enabled peripherals/sensors, comprehensive I/O pin mappings, timer/DMA mappings, SPI/I2C/UART instances, gyro/CLKIN settings, baro/OSD/flash, and meter/beeper defaults. Changes
Sequence Diagram(s)Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
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: 0
🧹 Nitpick comments (1)
configs/ZEX_ATHENA_PRO/config.h (1)
92-105
: Potential conflict: LED_STRIP and BEEPER both mapped to TIM1_CH1.
- Index 10: PA8 (TIM1 CH1) is assigned for LED_STRIP.
- Index 11: PE9 (also TIM1 CH1) is assigned for BEEPER.
- A single timer channel can’t be driven independently on two different pins; attempting to use both functions concurrently may cause resource contention.
Given the board wiring is fixed, two options:
- Keep as-is and accept that LED_STRIP activity will preclude timer-driven beeper tones (digital beeper still OK if it doesn’t rely on the timer).
- Prefer a non-timer beeper by removing the timer resource mapping line for the beeper (PE9 will still function as a simple beeper via GPIO), reducing conflict risk.
If you want to avoid timer resource contention by default, remove the beeper timer map entry:
- TIMER_PIN_MAP(11, PE9 , 1, -1) /* TIM1 CH1 (AF1) */ + /* Beeper kept as GPIO on PE9 via BEEPER_PIN; omit timer mapping to avoid conflict with LED_STRIP on TIM1_CH1 */ + /* TIMER_PIN_MAP(11, PE9 , 1, -1) */If there is an existing requirement for PWM beeper on PE9, we can instead move LED_STRIP to a different channel if a suitable wired pin exists; otherwise the mutual exclusion should be documented.
📜 Review details
Configuration used: .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/ZEX_ATHENA_PRO/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: 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#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#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.
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.
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:29-35
Timestamp: 2025-07-14T16:16:50.628Z
Learning: GYRO_1_SPI_CLOCK_DIVIDER is not used in any Betaflight target configuration files. SPI clock frequency settings are not commonly configured at the target level.
📚 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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/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/ZEX_ATHENA_PRO/config.h
🔇 Additional comments (9)
configs/ZEX_ATHENA_PRO/config.h (9)
24-28
: Board identity macros look correct and consistent.
- FC_TARGET_MCU is STM32H743 as per target name.
- BOARD_NAME matches the directory name (ZEX_ATHENA_PRO), per our checklist.
- MANUFACTURER_ID length and format are fine.
29-37
: Sensor driver enables align with the hardware description.ICM42688P is enabled for both ACC and GYRO, and DPS310 baro and MAX7456 OSD are enabled. This matches the PR description.
39-47
: Motor outputs mapped coherently; PD15 noted as no-DMA is properly documented.
- M1–M4 on TIM5 (PA0–PA3) and M5–M8 on TIM4 (PD12–PD15) are coherent.
- The comment for MOTOR8/TIM4_CH4 notes no DMA available, which matches the PR summary. Expect DShot to be unavailable on M8; PWM should still work.
If you want to double-check runtime behavior for M8 DShot fallback, you can confirm at boot via CLI “resource” dump and runtime logs. I can provide a script to parse log output if helpful.
Also applies to: 100-100
114-114
: Default serial RX on USART2 looks good.SERIAL_PORT_USART2 is a valid identifier, and PD5/PD6 are mapped for UART2 TX/RX above.
Optional: verify all port identifiers compile cleanly against src/main/io/serial.h on CI. If desired, I can script a lightweight check across the config headers to catch typos like SERIAL_PORT_UART3 vs SERIAL_PORT_USART3.
85-90
: GYRO CS and EXTI pins on PC13–PC15: ensure LSE isn’t required.PC14/PC15 are often used for LSE (32.768 kHz) on STM32H7. Using PC13–PC15 for CS/EXTI is fine if LSE is not used; just flagging to ensure RTC/LSE is not expected on this target.
If RTC/LSE is desired later, we should plan alternative CS/EXTI pins or disable LSE in the BSP for this target.
124-131
: Peripheral instance selections look consistent with pinout.
- MAX7456 on SPI3 with PB3/PB4/PB5 and CS PE2 is standard.
- Flash on SPI2 with PB13/14/15 and CS PB12 is standard.
- Gyros split across SPI1 and SPI4 with appropriate pins; GYRO_2_ALIGN = CW270_DEG is explicit.
Minor: Please double-check that the SPI1 pin trio (PA5/PA6/PD7) are all on the same SPI instance and share compatible AF settings simultaneously on H743. Mixed-port SPI1 is allowed, but AF conflicts can be subtle on H7.
53-63
: Confirm AF mapping for UART4 on PB8/PB9I wasn’t able to find any pinmap entries in the repo that demonstrate PB8/PB9 supporting USART4 on the STM32H743. Please manually verify in the STM32H743 alternate-function matrix (package-specific) that PB8/PB9 can be assigned to UART4. If they’re not valid, update to a supported TX/RX pair (e.g., PC10/PC11 or PE8/PE9).
• configs/ZEX_ATHENA_PRO/config.h: Lines 53–54 (UART4_TX_PIN = PB9, UART4_RX_PIN = PB8)
70-79
: Verify SPI1 MOSI pin PD7
PD7 as SPI1_SDO (MCU MOSI) is not one of the common SPI1 MOSI pins on the STM32H743 (typical pins are PA7, PB5 or PG10 in AF5). Please confirm against the STM32H7 datasheet (e.g., RM0433) that PD7 supports SPI1 MOSI on your exact device and PCB revision.
- If PD7→SPI1_MOSI (AF5) is valid on your MCU/package and the hardware really routes MOSI to PD7, no change is needed.
- Otherwise, update SPI1_SDO_PIN in configs/ZEX_ATHENA_PRO/config.h to a supported pin (e.g. PA7 or PB5) that matches your PCB trace.
106-113
: Verify H743 DMAMUX option mappingsPlease cross-check the DMA option macros in configs/ZEX_ATHENA_PRO/config.h (lines 106–113) against the STM32H743 DMAMUX request table (e.g. ST RM0433 §10.4.1 or the
LL_DMA_REQUEST_*
enums) to ensure they haven’t drifted:• ADC1_DMA_OPT = 9 // DMA2 Stream 0 → Request 9
• ADC3_DMA_OPT = 10 // DMA2 Stream 1 → Request 115
• TIMUP1_DMA_OPT = 0 // DMA1 Stream 0 → Request 15
• TIMUP3_DMA_OPT = 2 // DMA1 Stream 2 → Request 27
• TIMUP4_DMA_OPT = 1 // DMA1 Stream 1 → Request 32
• TIMUP5_DMA_OPT = 0 // DMA1 Stream 0 → Request 59
• TIMUP8_DMA_OPT = 0 // DMA1 Stream 0 → Request 51If any mapping is incorrect, update the macro to the proper option index.
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: 1
🧹 Nitpick comments (1)
configs/ZEX_ATHENA_STD_PRO/config.h (1)
110-117
: Review TIMUPx DMA options and remove unused entries (optional)TIMUP3_DMA_OPT is set, but TIM3 isn’t present in the TIMER_PIN_MAPPING. While harmless, keeping TIMUPx options aligned with actually used timers reduces confusion.
If TIM3 isn’t used anywhere on this target, consider removing TIMUP3_DMA_OPT.
📜 Review details
Configuration used: .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/ZEX_ATHENA_STD_PRO/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: 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#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.
📚 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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/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/ZEX_ATHENA_STD_PRO/config.h
🔇 Additional comments (9)
configs/ZEX_ATHENA_STD_PRO/config.h (9)
26-26
: BOARD_NAME matches directory name — good catchBOARD_NAME equals the directory name (ZEX_ATHENA_STD_PRO). This prevents target identification issues at build/runtime.
48-48
: MOTOR8 (PD15) correctly annotated as having no DMA — known limitationThe TIMER_PIN_MAP entry for PD15 explicitly notes “No DMA for PD15 available,” aligning with the PR description. This is important to set expectations for motor protocol support on MOTOR8 (e.g., DSHOT may be constrained).
If you expect 8-motor DSHOT, please confirm you’ve tested the 8th output for its intended protocol. Otherwise, consider documenting in the board readme that MOTOR8 may require PWM protocols.
Also applies to: 103-103
106-108
: Potential resource conflict: LED_STRIP (PA8) and BEEPER (PE9) both mapped to TIM1_CH1Both PA8 and PE9 are mapped to TIM1 CH1 in TIMER_PIN_MAPPING. If both peripherals require the timer (LED strip DMA waveform and PWM beeper), they will contend for the same timer channel. In some configurations, the beeper can operate as a simple GPIO (not PWM), but the mapping here suggests it may be using TIM1.
- Confirm whether the beeper runs as GPIO or PWM on this board.
- If PWM beeper is required while LED_STRIP is active, validate runtime coexistence on TIM1_CH1.
- If coexistence is not guaranteed, consider documenting the limitation (do not change pins; we understand the hardware is fixed).
This is a heads-up, not a blocker, given existing production constraints.
95-102
: Timer/DMA mapping for motors 1–7 looks consistent for H7
- MOTORS1–4 on TIM5 CH1–4 (PA0–PA3) with DMA noted.
- MOTORS5–7 on TIM4 CH1–3 (PD12–PD14) with DMA noted.
These are standard, consistent mappings for H7 and should support DSHOT well on M1–M7.
118-118
: Default SERIALRX UART is validSERIALRX_UART = SERIAL_PORT_USART2 matches defined pins (PD5/PD6) and uses a valid enum from serial.h. No issues.
129-131
: Nice: PINIO configured and labeledPINIO1 on PD10 with BOX 40/CONFIG 129 and user label “12V BEC” is clear and helpful for end-users.
29-38
: Overall feature set looks coherent for a dual-ICM42688P, DPS310, MAX7456, FLASH target
- Gyro/accel definitions with CLKIN, dual SPI instances, and DEFAULT_GYRO_TO_USE = BOTH are consistent with dual-IMU designs.
- Baro on I2C1 (DPS310), MAX7456 on SPI3, FLASH W25Q128 on SPI2 are all standard setups.
- Meter source defaults and scales are reasonable starting points.
Also applies to: 118-136
92-94
: Shared CLKIN (PA15) and TIM2_CH1 mapping is plausible; just confirm debug implicationsUsing PA15 for CLKIN via TIM2_CH1 is common for external gyro clocking. On H7, PA15 overlaps with JTAG JTDI in full SWJ mode. Usually SWD mode frees PA15, but ensure the boot/debug configuration does not lock out PA15 if you rely on CLKIN.
Please confirm:
- The target ships with SWD (not full JTAG), or documentation instructs disabling JTAG to free PA15.
- The CLKIN frequency setup (TIM2 configuration) matches the ICM42688P requirements on this design.
Also applies to: 108-109
71-82
: No changes needed: PD7 is a valid SPI1_MOSI pin on STM32H743
PD7 supports SPI1_MOSI via AF5 on the H743 (alongside PA7 and PB5). Ensure:
- GPIOD clock is enabled
- PD7 is set to alternate-function mode AF5
Co-authored-by: ot0tot <[email protected]>
Summary by CodeRabbit