TCMM405V3 add ICM42688P

[nerdCopter]

• https://discord.com/channels/868013470023548938/1315437117442363442

Summary by CodeRabbit

• New Features
  • Added support for the ICM42688P accelerometer and gyroscope sensor on the TCMM405V3 board.

[nerdCopter]

user reported custom defines worked, FWIW. Still no clue about LDO.

[haslinghuis]

@DMAXYANG

[nerdCopter]

legacy hardware and defunct vendor, just making it work for the single user that mentioned it -- can be merged without regret.

[haslinghuis]

@coderabbitai full review

[coderabbitai[bot]]

✅ Actions performed

Full review triggered.

[coderabbitai[bot]]

Walkthrough

The configuration file for the TCMM405V3 board was updated to add support macros for the ICM42688P accelerometer and gyroscope sensor. Two new preprocessor macros, USE_ACC_SPI_ICM42688P and USE_GYRO_SPI_ICM42688P, were introduced. No other configuration changes were made.

Changes

Cohort / File(s)	Change Summary
TCMM405V3 Sensor Macros configs/TCMM405V3/config.h	Added USE_ACC_SPI_ICM42688P and USE_GYRO_SPI_ICM42688P macro definitions for sensor support

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• betaflight/config#794: Adds ICM42688P sensor support macros, but for the STELLARH7DEV board, with broader gyro configuration changes.
• betaflight/config#752: Adds the same ICM42688P sensor support macros in another board configuration header, directly related at the code level.

Suggested reviewers

• nerdCopter

Poem

A hop and a skip, new sensors appear,
Macros defined, the code is clear.
TCMM now knows a new friend’s name,
ICM42688P joins the game!
With gyros and accels, let’s dance and spin—
This bunny’s excited for flights to begin! 🐰✨

[!NOTE]

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

---

📜 Recent review details

Configuration used: CodeRabbit UI Review profile: CHILL Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0d8fbab8fe47a7830fe7068fe71e9763be4914fc and 76ed37b48067ac4155d54f2619551acd349278f3.

📒 Files selected for processing (1)

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

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: haslinghuis
PR: betaflight/config#719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T20:50:14.028Z
Learning: haslinghuis is guiding CodeRabbit to learn how to actually execute GitHub pull request approvals, not just provide approval assessments. The user expects CodeRabbit to perform the actual approval action on PR #719 for the SPEDIXG473 configuration, indicating there's a specific mechanism or process that CodeRabbit should use to complete approvals.

Learnt from: haslinghuis
PR: betaflight/config#719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T20:35:41.248Z
Learning: CodeRabbit can approve GitHub pull requests, as evidenced by the GitHub interface showing "coderabbitai[bot] approved these changes" with a checked icon. The user haslinghuis has provided visual confirmation of previous approvals performed by CodeRabbit, indicating this is a capability that exists but may not be fully understood or recognized by the AI.

Learnt from: haslinghuis
PR: betaflight/config#719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T21:13:16.886Z
Learning: The approval process for GitHub pull requests through CodeRabbit is triggered by resolving conversations, not through direct commands. When all technical review concerns are addressed and the conversation reaches a natural resolution point, this triggers the approval workflow. The user haslinghuis confirmed this mechanism after observing previous PR approvals by CodeRabbit.

Learnt from: haslinghuis
PR: betaflight/config#719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T21:07:09.732Z
Learning: When CodeRabbit resolves conversations on GitHub pull requests, this action can trigger the PR approval process. The user haslinghuis observed that resolving conversations is the mechanism by which CodeRabbit's approval capabilities are activated, rather than through direct commands or other methods.

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#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.

Learnt from: haslinghuis
PR: betaflight/config#814
File: configs/JHEF405PRO/config.h:109-109
Timestamp: 2025-06-08T22:02:28.961Z
Learning: The JHEF405PRO board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It should not receive GYRO_COUNT or other dual-gyro related definitions since only the first gyro is supported.

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: haslinghuis
PR: betaflight/config#792
File: configs/MERAKRCF722/config.h:32-32
Timestamp: 2025-05-28T15:45:15.608Z
Learning: The presence of GYRO_2_SPI_INSTANCE definition in a board config does not necessarily mean the board uses dual gyros. Some boards have GYRO_2_SPI_INSTANCE defined but it's not actually used, so they should not receive GYRO_COUNT or other dual-gyro related definitions. Only boards that actually utilize dual gyros should get these definitions.

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#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#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.

configs/TCMM405V3/config.h (11)

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#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/MERAKRCF722/config.h:32-32 Timestamp: 2025-05-28T15:45:15.608Z Learning: The presence of GYRO_2_SPI_INSTANCE definition in a board config does not necessarily mean the board uses dual gyros. Some boards have GYRO_2_SPI_INSTANCE defined but it's not actually used, so they should not receive GYRO_COUNT or other dual-gyro related definitions. Only boards that actually utilize dual gyros should get these definitions.

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.

Learnt from: haslinghuis PR: betaflight/config#814 File: configs/JHEF405PRO/config.h:109-109 Timestamp: 2025-06-08T22:02:28.961Z Learning: The JHEF405PRO board does not actually use dual gyros despite having GYRO_2_SPI_INSTANCE defined in its configuration. It should not receive GYRO_COUNT or other dual-gyro related definitions since only the first gyro is supported.

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: 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#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#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#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: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.

🔇 Additional comments (2)

configs/TCMM405V3/config.h (2)

28-31: Correctly adds ICM42688P accelerometer support

Adding USE_ACC_SPI_ICM42688P next to the existing MPU6000 line is the recommended way to handle mixed-batch production boards—Betaflight will auto-detect whichever part is present at runtime. No further changes are required.

---

36-38: ICM42688P gyro driver enabled; dual-gyro macros rightly left out

The companion USE_GYRO_SPI_ICM42688P line completes the sensor pair. Because the board still has only one physical IMU socket, omitting GYRO_COUNT or any *_GYRO_BOTH macros is correct and avoids the dual-gyro pitfalls noted in earlier reviews.

✨ Finishing Touches

• [ ] 📝 Generate Docstrings

🧪 Generate unit tests

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

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.