Fix HUMMINGBIRD FC305 baro

[LYNHQQ]

Our customers reported that the SPL06 sometimes isn’t detected, so we’ve switched to automatic detection.

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[qodo-code-review]

Review Summary by Qodo

Enable automatic barometer detection for HUMMINGBIRD FC305

🐞 Bug fix

Walkthroughs

Description

• Switch barometer from fixed SPL06 to automatic detection
• Add DPS310 barometer support with shared I2C bus
• Consolidate barometer I2C bus configuration
• Fix unreliable SPL06 sensor detection issues

Diagram

flowchart LR
  A["Fixed SPL06 Config"] -->|"Switch to autodetect"| B["BARO_AUTODETECT"]
  C["SPL06 Only"] -->|"Add DPS310 support"| D["SPL06 + DPS310"]
  E["Separate I2C Configs"] -->|"Consolidate"| F["Shared BARO_I2C_BUS"]

Loading

File Changes

1. src/main/target/HUMMINGBIRD_FC305/config.c 🐞 Bug fix +1/-1

Switch to automatic barometer detection

• Changed barometer hardware configuration from BARO_SPL06 to BARO_AUTODETECT
• Enables automatic barometer detection instead of fixed hardware selection

src/main/target/HUMMINGBIRD_FC305/config.c

---

2. src/main/target/HUMMINGBIRD_FC305/target.c ✨ Enhancement +2/-1

Add DPS310 support and consolidate I2C bus

• Updated SPL06 I2C bus reference from SPL06_I2C_BUS to BARO_I2C_BUS
• Added DPS310 barometer device registration on shared BARO_I2C_BUS
• Enables support for multiple barometer types on same I2C bus

src/main/target/HUMMINGBIRD_FC305/target.c

---

3. src/main/target/HUMMINGBIRD_FC305/target.h ⚙️ Configuration changes +2/-1

Add DPS310 and consolidate barometer I2C config

• Added BARO_I2C_BUS definition pointing to BUS_I2C1
• Added USE_BARO_DPS310 feature flag
• Removed individual SPL06_I2C_BUS definition in favor of shared bus

src/main/target/HUMMINGBIRD_FC305/target.h

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. busdev_dps310 uses hardcoded addr 📘 Rule violation ⚙ Maintainability

Description

The new DPS310 registration hardcodes 0x76 instead of using a centralized *_I2C_ADDR macro,
making address/behavior easy to drift across modules/targets. This can break or confuse barometer
autodetection if the DPS310 address differs from the SPL06 address on a given board variant.

Code

src/main/target/HUMMINGBIRD_FC305/target.c[R30-31]

+BUSDEV_REGISTER_I2C(busdev_spl06,      DEVHW_SPL06,        BARO_I2C_BUS,       SPL06_I2C_ADDR,     NONE,           DEVFLAGS_NONE,      0);
+BUSDEV_REGISTER_I2C(busdev_dps310,     DEVHW_DPS310,       BARO_I2C_BUS,       0x76,               NONE,           DEVFLAGS_NONE,      0);

Evidence

PR Compliance ID 3 requires shared behavior/mappings to be centralized to prevent drift. The PR adds
a DPS310 device registration using a raw address literal (0x76) while SPL06 uses a named macro
(SPL06_I2C_ADDR), and other targets define DPS310_I2C_ADDR as a configurable macro,
demonstrating the expected centralized pattern.

src/main/target/HUMMINGBIRD_FC305/target.c[30-31]
src/main/target/HUMMINGBIRD_FC305/target.h[56-61]
src/main/target/BRAHMA_F405/target.h[48-52]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`busdev_dps310` is registered with a hardcoded I2C address (`0x76`) while other baro devices use named macros. This duplicates a shared mapping and increases the chance of drift/misconfiguration across modules/targets.

## Issue Context
This target now enables `USE_BARO_DPS310` and uses `BARO_AUTODETECT`. The address should be a target-level constant (like `SPL06_I2C_ADDR`) so hardware variants can adjust it without hunting for literals.

## Fix Focus Areas
- src/main/target/HUMMINGBIRD_FC305/target.h[56-61]
- src/main/target/HUMMINGBIRD_FC305/target.c[30-31]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. DPS310 masked by SPL06 🐞 Bug ≡ Correctness

Description

With BARO_AUTODETECT, barometer detection tries SPL06 before DPS310, and both drivers accept chip-id
0x10 from register 0x0D, so a DPS310 can be detected as SPL06 and the DPS310 driver will never run.
This can defeat the intended “automatic detection” fix and may run the wrong driver on DPS310
hardware.

Code

src/main/target/HUMMINGBIRD_FC305/target.c[R30-31]

+BUSDEV_REGISTER_I2C(busdev_spl06,      DEVHW_SPL06,        BARO_I2C_BUS,       SPL06_I2C_ADDR,     NONE,           DEVFLAGS_NONE,      0);
+BUSDEV_REGISTER_I2C(busdev_dps310,     DEVHW_DPS310,       BARO_I2C_BUS,       0x76,               NONE,           DEVFLAGS_NONE,      0);

Evidence

This target now defaults to BARO_AUTODETECT and registers both SPL06 and DPS310 on the same
bus/address. In autodetect mode, the detection order checks SPL06 before DPS310; SPL06 detection
accepts chip-id 0x10, and DPS310 detection also treats chip-id 0x10 as valid, so DPS310 hardware can
satisfy the SPL06 probe and short-circuit before DPS310 detection is attempted.

src/main/target/HUMMINGBIRD_FC305/config.c[28-33]
src/main/target/HUMMINGBIRD_FC305/target.c[27-32]
src/main/sensors/barometer.c[73-185]
src/main/drivers/barometer/barometer_spl06.h[20-43]
src/main/drivers/barometer/barometer_spl06.c[161-174]
src/main/drivers/barometer/barometer_dps310.c[56-66]
src/main/drivers/barometer/barometer_dps310.c[328-374]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
HUMMINGBIRD_FC305 now enables `BARO_AUTODETECT` and registers both SPL06 and DPS310. However, `BARO_AUTODETECT` probes SPL06 before DPS310, and both SPL06 and DPS310 drivers treat chip-id `0x10` (read from reg `0x0D`) as a valid match. This means DPS310 hardware can be misdetected as SPL06, preventing DPS310 driver initialization.

### Issue Context
- Autodetect order is implemented in `baroDetect()`.
- SPL06 and DPS310 detection both read register `0x0D` and accept `0x10`.

### Fix Focus Areas
- src/main/sensors/barometer.c[73-185]
- src/main/drivers/barometer/barometer_spl06.c[161-174]
- src/main/drivers/barometer/barometer_dps310.c[328-374]

### Suggested fix approach
Implement deterministic disambiguation when both `USE_BARO_SPL06` and `USE_BARO_DPS310` are enabled:
1. In `BARO_AUTODETECT` mode, try `baroDPS310Detect()` before `spl06Detect()` **or**
2. Add a secondary probe in SPL06 detection to reject DPS310 (or vice-versa) based on an additional register/value that differs between the parts, and only then accept the device.

Ensure that whichever approach is used does not leave the sensor in a partially-configured state if the first probe fails and the second probe is attempted.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[github-actions]

Test firmware build ready — commit 62acef3

Download firmware for PR #11469

1 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.