Detect the DPS310 on both of its I2C addresses

[Raffi1202]

Problem

A DPS310 barometer wired for I2C address 0x77 is not detected. The reporter of #9958 points at the Infineon datasheet, which lists 0x77 as the default address, while common_hardware.c hard-codes 0x76; a second user had a board with the DPS310 on 0x77 and only got a barometer after editing the address in the target, a third got no barometer at all after connecting an external DPS310. Only targets that pin DPS310_I2C_ADDR themselves (BRAHMA_F405/F722) work on 0x77 today.

Cause

src/main/target/common_hardware.c:183-186 on maintenance-10.x: when a target does not define DPS310_I2C_ADDR the default is set to 0x76 and a single descriptor is registered. src/main/drivers/barometer/barometer_dps310.c:346 opens only that DEVHW_DPS310 slot, so a sensor with SDO pulled high (0x77) is never probed.

Change

bus.h: DEVHW_DPS310 becomes DEVHW_DPS310_0 and DEVHW_DPS310_1. common_hardware.c: with no DPS310_I2C_ADDR both 0x76 and 0x77 are registered; a target that defines the address keeps one descriptor (BRAHMA_F405/F722, ORBITH743), and the SPI path stays a single slot. barometer_dps310.c: baroDPS310Detect() loops over both slots, skips a slot for which busDeviceInit() returns NULL and de-inits a slot whose ID check or configure fails. HUMMINGBIRD_FC305/target.c (own descriptor table) is renamed to the _0 slot, and docs/development/msp/inav_enums.json / inav_enums_ref.md are regenerated for the new enum values.

Test

Not run on hardware. Cause verified by reading common_hardware.c:183-186 and barometer_dps310.c:346 on maintenance-10.x; the NULL return for an unregistered slot is bus.c:174. No CI build of this branch exists: the fork has no Actions run for 7719c72 and the upstream checks have not run. A grep of the branch finds no remaining DEVHW_DPS310 or busdev_dps310 reference.

Flash / RAM

Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.

Docs

docs/development/msp/inav_enums.json and docs/development/msp/inav_enums_ref.md regenerated with gen_docs.sh because devHardwareType_e changed. No other documentation states the DPS310 default address; the DPS310_I2C_ADDR override described in docs/development/targets/common-issues.md still applies.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Detect DPS310 barometers at both valid I2C addresses

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Registers both valid DPS310 I2C addresses when targets do not pin one.
• Iterates registered DPS310 slots, configuring the first detected sensor.
• Preserves explicit target addresses and existing SPI behavior.

Diagram

graph TD
    A["Target config"] --> B{"Address pinned?"}
    B -->|Yes| C["Single descriptor"] --> E["DPS310 probe loop"] --> F{"Chip detected?"} -->|Yes| G["Configure barometer"]
    B -->|No| D["Dual descriptors"] --> E
    F -->|No| H["Try next slot"] --> E

Loading

High-Level Assessment

The current approach is appropriate because it reuses the established multi-slot bus-descriptor pattern already used by IST8310 and preserves target-specific address overrides. Directly scanning raw I2C addresses in the driver would bypass the bus registry, while changing the single default address would merely reverse which boards fail.

Files changed (4) +25 / -15

Bug fix (2) +16 / -10

barometer_dps310.cProbe both registered DPS310 hardware slots +14/-9

Probe both registered DPS310 hardware slots

• Replaces single-slot initialization with an ordered loop over both DPS310 device identifiers. Failed candidates are deinitialized, while the first successfully detected and configured device is retained.

src/main/drivers/barometer/barometer_dps310.c

bus.hDefine two DPS310 hardware identifiers +2/-1

Define two DPS310 hardware identifiers

• Splits the DPS310 bus hardware identifier into consecutive '_0' and '_1' slots, allowing the driver to iterate over two registered addresses.

src/main/drivers/bus.h

Other (2) +9 / -5

target.cMigrate custom DPS310 descriptor to slot zero +1/-1

Migrate custom DPS310 descriptor to slot zero

• Renames the target-owned DPS310 descriptor and hardware identifier to the new '_0' convention while retaining its configured address.

src/main/target/HUMMINGBIRD_FC305/target.c

common_hardware.cRegister both default DPS310 I2C addresses +8/-4

Register both default DPS310 I2C addresses

• Registers descriptors for 0x76 and 0x77 when no target-specific address is defined. Explicit address overrides still create one descriptor, and SPI registration remains a single slot.

src/main/target/common_hardware.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Hardware values are documented wrong ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

devHardwareType_e adds a second DPS310 enumerator, but the checked-in enum JSON and reference
still contain the removed single entry and the old numbering. Whenever these artifacts are consumed,
they report a nonexistent DPS310 name and values one lower than the source for every subsequent
hardware type.

Code

src/main/drivers/bus.h[R101-102]

+    DEVHW_DPS310_0,
+    DEVHW_DPS310_1,

Evidence

The source enum now assigns consecutive values to two DPS310 entries before B2SMPB, while both
generated artifacts retain the removed name and old numbering. Repository guidance explicitly
requires regeneration when a source enum changes and notes that CI will not detect stale output.

src/main/drivers/bus.h[93-106]
docs/development/msp/inav_enums.json[829-840]
docs/development/msp/inav_enums_ref.md[1456-1465]
docs/development/Development.md[164-173]
docs/development/msp/README.md[11-18]

Agent prompt

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

## Issue description
The new DPS310 enum entry shifts all subsequent hardware values, but the checked-in generated enum artifacts still expose the old name and numbering.
## Fix Focus Areas
- src/main/drivers/bus.h[101-102]
- docs/development/msp/inav_enums.json[829-840]
- docs/development/msp/inav_enums_ref.md[1456-1465]
## Recommended Fix
Run `docs/development/msp/gen_docs.sh` from its directory and commit all regenerated enum documentation outputs so they contain both DPS310 entries and the corrected subsequent values.

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

---

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

RAM / Flash usage vs. base commit 76ee415 — commit 59da43c

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	+23296 B (+3.33%)	-10364 B (-6.94%)
MATEKF722 ⚠️	+10408 B (+2.21%)	-11224 B (-8.95%)
MATEKF765 ⚠️	+16464 B (+2.23%)	-9220 B (-5.58%)
MATEKH743 ⚠️	+23060 B (+2.98%)	-8380 B (-4.96%)

See RAM/flash optimization guide for techniques to reduce usage.

[github-actions]

Test firmware build ready — commit 59da43c

Download firmware for PR #11906

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