Add ODDITYRCF405 target

[ot0tot]

Checklist (✓/✕, or y/n)

• passed Betaflight team's schematics review
• passed hardware samples testing
• follows guidelines
• follows connector standards
• flight tested
• comments/issues resolved

Summary by CodeRabbit

• New Features
  • Added support for the ODDITYRCF405 board, enabling use of this device with full hardware configuration including motor and servo pin mappings, sensor interfaces, and system settings.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A new board configuration file is added for the ODDITYRCF405 flight controller based on STM32F405 MCU, specifying feature flags, peripheral pin mappings, timer assignments, system constants, and device defaults.

Changes

Cohort / File(s)	Summary
ODDITYRCF405 board configuration configs/ODDITYRCF405/config.h	New device configuration header defining MCU target (STM32F405), board identifiers, feature flags (accelerometer, gyro, barometer, flash, OSD, blackbox), peripheral pin mappings (motors, servos, UARTs, I2C, SPI, LED/beeper), TIMER_PIN_MAPPING macro for timer-to-pin routing, and system settings (HSE frequency, PID defaults, DSHOT modes, sensor sources)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10–15 minutes

• Verify accuracy of pin mappings for motors, servos, and peripherals
• Confirm feature flags align with actual board capabilities
• Check for potential conflicts or duplication with similar board configurations
• Validate TIMER_PIN_MAPPING macro syntax and timer assignments

Possibly related PRs

• Add SPEEDYBEEF405AIOV2 #974 — Adds another STM32F405 board configuration header with similar macro patterns and pin mapping structure

Suggested labels

Awaiting prototype samples, Schematics approved, Uses BF connector standard

Suggested reviewers

• haslinghuis
• nerdCopter
• sugaarK

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description includes only a partial checklist without the mandatory sections required by the template (Hardware Compliance Requirements, Housekeeping notes, and context about the submission).	Complete the description by adding context about the hardware, design compliance details, and addressing all mandatory template sections including Hardware Compliance Requirements and Housekeeping guidelines.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a new target configuration for the ODDITYRCF405 board.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 83ee891 and 42ba845.

📒 Files selected for processing (1)

• configs/ODDITYRCF405/config.h (1 hunks)

🧰 Additional context used

🧠 Learnings (13)

📓 Common learnings

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Learnt from: haslinghuis
Repo: betaflight/config 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: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.

Learnt from: haslinghuis
Repo: betaflight/config PR: 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: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-09-26T16:32:46.694Z
Learning: When reviewing hardware configuration files like Betaflight configs, always check for pin assignment conflicts by verifying that no physical pins (like PB10, PB11, etc.) are assigned to multiple peripheral functions simultaneously.

Learnt from: haslinghuis
Repo: betaflight/config PR: 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: ot0tot
Repo: betaflight/config PR: 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
Repo: betaflight/config PR: 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
Repo: betaflight/config 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: osirisinferi
Repo: betaflight/config PR: 972
File: configs/AXISFLYING_H743PRO/config.h:98-98
Timestamp: 2025-12-03T20:50:01.374Z
Learning: In Betaflight board configurations, if PINIOx_BOX or PINIOx_CONFIG defines are present in a config.h file, the corresponding PINIOx_PIN define must also be present to specify the actual pin assignment. Each PINIO instance requires a pin definition before it can be configured or assigned to a box.

📚 Learning: 2025-07-03T04:33:57.480Z

Learnt from: ot0tot
Repo: betaflight/config PR: 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/ODDITYRCF405/config.h

📚 Learning: 2025-07-14T16:16:56.822Z

Learnt from: haslinghuis
Repo: betaflight/config 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.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-08-22T17:08:23.283Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-07-03T04:33:57.480Z

Learnt from: ot0tot
Repo: betaflight/config PR: 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/ODDITYRCF405/config.h

📚 Learning: 2025-06-02T16:16:20.197Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 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/ODDITYRCF405/config.h

📚 Learning: 2025-12-03T20:45:27.890Z

Learnt from: osirisinferi
Repo: betaflight/config PR: 972
File: configs/AXISFLYING_H743PRO/config.h:0-0
Timestamp: 2025-12-03T20:45:27.890Z
Learning: In Betaflight board configurations, always verify that TIMER_PIN_MAP entries do not use the same pin macro name multiple times. Each physical pin should appear only once in the TIMER_PIN_MAP definitions. For example, GYRO_1_CLKIN_PIN and GYRO_2_CLKIN_PIN should each appear exactly once, not have GYRO_1_CLKIN_PIN appear twice. This is a blocking issue that must be resolved before approval.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-08-28T20:45:36.652Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-08-28T20:45:36.652Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-08-20T02:54:58.596Z

Learnt from: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-07-14T15:41:14.364Z

Learnt from: ot0tot
Repo: betaflight/config 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).

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-05-31T17:01:39.423Z

Learnt from: haslinghuis
Repo: betaflight/config 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

Applied to files:

• configs/ODDITYRCF405/config.h

📚 Learning: 2025-12-03T20:50:01.374Z

Learnt from: osirisinferi
Repo: betaflight/config PR: 972
File: configs/AXISFLYING_H743PRO/config.h:98-98
Timestamp: 2025-12-03T20:50:01.374Z
Learning: In Betaflight board configurations, if PINIOx_BOX or PINIOx_CONFIG defines are present in a config.h file, the corresponding PINIOx_PIN define must also be present to specify the actual pin assignment. Each PINIO instance requires a pin definition before it can be configured or assigned to a box.

Applied to files:

• configs/ODDITYRCF405/config.h

🔇 Additional comments (7)

configs/ODDITYRCF405/config.h (7)

1-28: Header, MCU, and board identifiers look consistent

• GPL header and FC_TARGET_MCU STM32F405 are standard for an F4 target.
• BOARD_NAME ODDITYRCF405 exactly matches the folder name configs/ODDITYRCF405, and MANUFACTURER_ID ODTY is a valid 4‑char ID.

No changes needed here.

Based on learnings, this satisfies the BOARD_NAME vs directory requirement.

---

29-38: Sensor and peripheral feature flags are coherent

• ACC/GYRO via SPI ICM42688P, FLASH via M25P16, MAX7456 OSD, and DPS310 barometer are all valid combinations for an F405 target.
• USE_MAX7456 is set; OSD build‑mode flags (analog vs HD) remain correctly handled at build time by Cloud Build rather than here.

Nothing to change; just ensure the hardware actually uses these exact parts.

Please double‑check against the BOM that the gyro, flash, OSD, and baro part numbers match what’s on the production PCB.

---

39-48: Motor/servo pins and TIMER_PIN_MAPPING are internally consistent

• MOTOR pins (PC8, PC9, PA8, PA9) and SERVO pins (PB3, PA15, PB10, PB11) are all unique and not reused elsewhere.
• The TIMER_PIN_MAPPING entries reference the corresponding *_PIN macros exactly once each; no physical pin is mapped twice, which is a hard requirement.
• Timer option values (1/2, …) and function flags align with patterns used on other STM32F405 targets (e.g. PC8/PC9/ PB1 using option 2 mirrors RADIOLINKF405), which have known‑good DMA layouts. (github.com)
• Servos use timer option 1 with -1 (no DMA), which is appropriate for low‑rate servo/PWM use and keeps DMA resources for motors/LED.

I don’t see any pin or obvious DMA conflicts here.

I still recommend on real hardware:

• Build a firmware with USE_TIMER_MAP_PRINT and run timer map and dma in CLI to confirm the generated map for this board matches what you’ve encoded here.
• Verify that DSHOT on all four motors plus LED strip works without DMA errors.

Based on learnings, this satisfies the “no duplicate TIMER_PIN_MAP pin macros” and F405 timer/DMA‑sanity expectations.

Also applies to: 88-97

---

49-62: UART and I2C pin assignments match STM32F405 capabilities

• UARTs:
  • UART1: PB6/PB7 (AF7)
  • UART2: PA2/PA3
  • UART4: PA0/PA1
  • UART5: PC12/PD2
  • UART6: PC6/PC7
    These all correspond to valid AF mappings on STM32F405 and are in line with patterns already used in other Betaflight F405 targets. (reddit.com)
• I2C1 on PB8/PB9 is also a standard, supported mapping.

No structural issues spotted.

Please quickly confirm against serial_uart_stm32f4xx.c in the main Betaflight repo that each UARTx_TX/RX pin combination is supported there, as per prior guidance.

---

63-78: SPI buses and CS/EXTI pins are wired in a conventional, conflict‑free way

• SPI1 (gyro) on PA5/PA6/PA7 with CS PC4 and EXTI PC5 is a very common F405 layout.
• SPI2 (MAX7456 OSD) on PB13/14/15 with CS PB12 is standard for analog OSD.
• SPI3 (flash) on PC10/PC11/PB5 with CS PB4 mirrors other F405 designs that run SPI flash on SPI3. (github.com)
• None of these SPI pins are reused for motors, servos, LED strip, or UARTs.

Looks good; no pin or obvious DMA contention exposed at the config level.

When you get hardware on the bench, please confirm:

• Gyro, OSD, and flash all initialize correctly over their assigned SPI buses.
• There are no DMA warnings when using blackbox flash logging and DSHOT simultaneously.

---

79-87: LED/Beeper, ADC, and PINIO definitions are consistent and complete

• LED0 on PC0 and BEEPER on PC13 are typical F4 choices and not reused elsewhere.
• ADC pins: VBAT PC3, CURR PC2, RSSI PC1 match the usual ADC1 channels on F405; ADC1_DMA_OPT 0 is a common “default” ADC1 DMA selection. (deepwiki.com)
• LED_STRIP on PB1 is consistent with other F405 boards; timer mapping entry present.
• PINIO:
  • PINIO1_PIN / PINIO1_BOX / PINIO1_CONFIG / BOX_USER1_NAME are all present and coherent.
  • PINIO2_PIN and PINIO2_BOX / PINIO2_CONFIG are also present.

This satisfies the requirement that any PINIOx_BOX/CONFIG has a corresponding PINIOx_PIN.

Please verify on hardware:

• ADC voltage/current readings (and RSSI if used) are sane with your actual resistor dividers/shunts.
• PINIO1 (“9V BEC OFF”) and PINIO2 behave as intended with the chosen CONFIG values.
  Based on learnings, the PINIO definitions are structurally correct.

Also applies to: 99-106

---

107-120: Peripheral instances and defaults are sensible; gyro align needs real‑world confirmation

• MAG_I2C_INSTANCE and BARO_I2C_INSTANCE both set to I2CDEV_1, matching I2C1 pins PB8/PB9 and the pattern used on similar boards. (deepwiki.com)
• SPI instances:
  • GYRO_1_SPI_INSTANCE SPI1
  • MAX7456_SPI_INSTANCE SPI2
  • FLASH_SPI_INSTANCE SPI3
    all match the earlier SPI pin definitions.
• System/defaults:
  • SYSTEM_HSE_MHZ 8 is the standard 8 MHz HSE used on most F405 boards.
  • DSHOT defaults (DMAR_OFF/BITBANG_OFF), ADC‑based current/voltage meters, and flash blackbox are conventional and appropriate.

The only thing to flag is the commented‑out GYRO_1_ALIGN:

//#define GYRO_1_ALIGN         CW270_DEG

If the ICM42688P is mounted with any rotation relative to the MCU, you’ll need to set this correctly before production. Leaving it commented is fine for now but must match flight‑tested orientation later.

Once you have hardware:

• Confirm the actual crystal frequency (8 MHz) and adjust SYSTEM_HSE_MHZ if needed.
• Determine the correct gyro orientation and either enable or adjust GYRO_1_ALIGN based on hover/flight tests in Betaflight.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}