Add support for new custom Acci FC board - ACCIF435ELITE #849
Conversation
WalkthroughA new configuration header file for the ACCIF435ELITE flight controller board has been introduced. This file defines hardware-specific settings, including MCU target, board identification, sensor and peripheral enablement, pin assignments, and default configuration macros for sensors, flash memory, UARTs, timers, and user I/O. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Firmware
participant Board (ACCIF435ELITE)
User->>Firmware: Builds for ACCIF435ELITE
Firmware->>Board (ACCIF435ELITE): Applies config.h macros
Board (ACCIF435ELITE)->>Firmware: Provides pin mappings, sensor configs, defaults
Firmware->>User: Runs with board-specific configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 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 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: 0
🧹 Nitpick comments (1)
configs/ACCIF435ELITE/config.h (1)
40-43: Consider consolidating flash memory support.You're enabling support for three different flash memory chips (M25P16, W25Q128FV, W25N01G). While this provides flexibility for different hardware variants, consider if all three are actually needed for this specific board or if this is intended for hardware auto-detection.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/ACCIF435ELITE/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
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#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.
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: 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. Many existing boards successfully use USE_BARO_BMP280 and USE_BARO_DPS310 without defining USE_I2C, indicating that the I2C dependency is handled automatically by the build system or these sensors support alternative communication methods.
Learnt from: haslinghuis
PR: betaflight/config#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: 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-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.
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 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#757
File: configs/HAKRCH743/config.h:134-134
Timestamp: 2025-08-05T16:56:44.200Z
Learning: In Betaflight board configurations, when DEFAULT_GYRO_TO_USE is set to GYRO_CONFIG_USE_GYRO_BOTH, the firmware automatically establishes GYRO_COUNT during initialization for backwards compatibility. Therefore, explicit GYRO_COUNT definitions are not needed in board config files when using DEFAULT_GYRO_TO_USE.
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:29-35
Timestamp: 2025-07-14T16:16:50.628Z
Learning: CW0_DEG is not a universal default gyro alignment setting in Betaflight configurations. Different boards use different gyro alignments (CW0_DEG, CW90_DEG, CW180_DEG, CW270_DEG, CW0_DEG_FLIP, etc.) based on their physical sensor mounting orientation.
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: 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.
📚 Learning: for betaflight board configurations of boards already in production, pin assignments in config.h fil...
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/ACCIF435ELITE/config.h
📚 Learning: always verify that the board_name define in each config.h matches the directory name it resides in (...
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/ACCIF435ELITE/config.h
📚 Learning: always verify that the `board_name` define in config.h files exactly matches the directory name wher...
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/ACCIF435ELITE/config.h
📚 Learning: in betaflight configuration files, feature enablement macros like use_mag are build options that can...
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/ACCIF435ELITE/config.h
📚 Learning: in betaflight configurations, when a target name suggests dual imus (like jhef7dual) but specific ha...
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/ACCIF435ELITE/config.h
📚 Learning: in betaflight board configurations, when a board design uses the same physical gyro socket but diffe...
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.
Applied to files:
configs/ACCIF435ELITE/config.h
📚 Learning: the default_gyro_enabled macro with both gyros enabled (gyro_mask(0) | gyro_mask(1)) should only be ...
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.
Applied to files:
configs/ACCIF435ELITE/config.h
📚 Learning: for betaflight board configuration reviews, always verify that serial port defines (like esc_sensor_...
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/ACCIF435ELITE/config.h
📚 Learning: in betaflight board configurations, when default_gyro_to_use is set to gyro_config_use_gyro_both, th...
Learnt from: haslinghuis
PR: betaflight/config#757
File: configs/HAKRCH743/config.h:134-134
Timestamp: 2025-08-05T16:56:44.200Z
Learning: In Betaflight board configurations, when DEFAULT_GYRO_TO_USE is set to GYRO_CONFIG_USE_GYRO_BOTH, the firmware automatically establishes GYRO_COUNT during initialization for backwards compatibility. Therefore, explicit GYRO_COUNT definitions are not needed in board config files when using DEFAULT_GYRO_TO_USE.
Applied to files:
configs/ACCIF435ELITE/config.h
📚 Learning: the default_gyro_enabled macro with both gyros enabled (gyro_mask(0) | gyro_mask(1)) should only be ...
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.
Applied to files:
configs/ACCIF435ELITE/config.h
📚 Learning: in stm32f405-based flight controller configurations, timer pin mappings must be carefully analyzed f...
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/ACCIF435ELITE/config.h
📚 Learning: for betaflight board configuration reviews, always verify that serial port defines use valid identif...
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/ACCIF435ELITE/config.h
🔇 Additional comments (7)
configs/ACCIF435ELITE/config.h (7)
24-28: LGTM! Board identification is correct.The target MCU is correctly specified as AT32F435G, and the BOARD_NAME matches the directory name as required. The MANUFACTURER_ID "CUST" is appropriate for a custom board.
117-119: I2C configuration is appropriate.The I2C setup correctly assigns both barometer and magnetometer to I2C1 with pullups enabled. This is a standard configuration for flight controllers.
130-134: Default configuration values are appropriate.The default settings are well-chosen for this board configuration:
- Blackbox to flash memory matches the flash support enabled
- ADC-based current and voltage metering aligns with the ADC pin definitions
- Voltage meter scale of 113 should be verified against the actual voltage divider on the board
- DShot burst mode with DMA is a performance optimization
125-127: PINIO1 configuration is consistent with existing boards — no changes needed.The values PINIO1_BOX 40 and PINIO1_CONFIG 129 match multiple other board configs (e.g., ZEUSF722_AIO, XILOF4, TMOTORF7V2), so they are appropriate for ACCIF435ELITE.
29-38: No explicit I2C setup needed; default DPS310 I2C address is correctThe ACCIF435ELITE config already aligns with most Betaflight boards using DPS310:
- USE_I2C isn’t needed—barometer drivers auto-enable I2C under the hood.
- DEFAULT_BARO_I2C_ADDRESS 119 (0x77) matches MERCURYG4, GRAVITYF7, DRONIUSF7, BRAHMA_F405, etc.
Unless your hardware variant pulls SA0 low (0x76), you can leave this as is.
78-96: Confirm UART pin mappings with ACCIF435ELITE hardware schematicI’ve checked configs/ACCIF435ELITE/config.h (lines 78–96) and found no duplicate pin assignments in the file. Before merging, please verify these mappings match the ACCIF435ELITE board’s schematic/PCB layout to ensure each UART TX/RX pin is wired correctly.
- configs/ACCIF435ELITE/config.h (78–96):
• UART1: TX=PB6, RX=PB7
• UART2: TX=PA2, RX=PA3
• UART3: TX=PB10, RX=PB11
• UART4: TX=PA0, RX=PA1
• UART5: TX=PC12, RX=PD2
• UART6: TX=PC6, RX=PC7
100-106: Timer pin mapping verified—no conflicts detectedAll pins are assigned exclusively with no overlapping uses:
- PA9/PA8 → MOTOR1/MOTOR2 (TIM1)
- PC9/PC8 → MOTOR3/MOTOR4 (TIM8)
- PB3 → LED_STRIP (general-purpose timer, DMA stream 0)
- PC5 → GYRO_1_CLKIN (no DMA)
- SPI1 (GYRO_1) and SPI2 (FLASH/Blackbox) use separate DMA resources
No DMA stream or timer peripheral conflicts were found.
This is done because as is a custom board I have been building at home I tend to try different flash chips. |
|
Are you manufacturing this, or is this just a one-off personal project? |
I am not manufacturing the project, is a personal project. |
|
Does it need a Betaflight target then? Why not just build the firmware yourself? I can't find a schematic for this, but the target does not meet the current requirements for acceptance as it does not adhere to the manufacturer design guidelines. |
The project is open source here: As anyone can order the PCB having the target always simplify the project support. Could you please point me what is not meeting the requirements? |
|
This actually looks better than most manufacturer's designs :) The first issue with the schematic is using PC14 and PC15 for LEDs. It would also be nice to have a jumper on the baro SDO to allow changing the I2C address. I will review the target config and provide suggestions. |
Thank you so much for your time.
|
Could you add a note to the PCB design about the LEDs? As this is a custom DIY target I think it should be ok, but users should be aware. Just add an open jumper between SDO and ground. Leaving it open will set the I2C address as you currently have it, and closing it will change to the default baro I2C address. This is good to have when only one I2C bus is exposed, in the event of a conflict with an externally connected I2C device. |
jesuslg123
force-pushed
the
ACCIF435_ELITE
branch
from
de4ba54 to
4fb8d75
Compare
|
there is also |
|
Previous ACCI boards already use CUST - is FOSS not used for open source - including making schematics available ? |
Yeah, I am planning opening another PR to change to FOSS the ACCIF405 and ACCIF435, I think it makes more sense as everything is open source. |
5 participants
Summary
This pull request adds support for a new custom Betaflight target: ACCIF435ELITE. This target is designed for a custom flight controller developed by ACCI FPV and is based on the AT32F435 series.
This target is very similar to ACCIF435 but the main reasson I went for a new target is the adition of Gyro CLKIN and no analog OSD chip is available. If this could be added to the old target without damage, instead of adding a new one I would be happy to go that way.
Key Details
Custom board features
Notes
This is a custom target and is not associated with any manufacturer.
Tested on physical hardware with full flight functionality and peripheral support verified.
UART2 and UART3 are prone to be DFU hijack, but UART2 is used for ESC communication and UART3 is not promoted for RX, UART4 has easy connector for that.
Summary by CodeRabbit
Summary by CodeRabbit