Detect the DPS310 on both of its I2C addresses - #11906
sensei-hacker merged 6 commits into
Conversation
The DPS310 answers on 0x77 when its SDO pin is pulled high and on 0x76 when it is pulled low. Both wirings are shipped on real boards, so the fixed default of 0x76 left every board of the other kind without a barometer. Register both addresses and probe them in the driver, the same way the IST8310 compass is handled. A target that pins the address down with DPS310_I2C_ADDR keeps using only that address. Fixes iNavFlight#9958
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoDetect DPS310 barometers at both valid I2C addresses
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #11906 251 targets built. Find your board's
|
|
Looks good, CI is green on all targets. Two points:
We can merge after this is addressed. Thank you! |
b14ckyy
added
Bugfix
Feedback required
deviceDetect() retried the ID read five times with a 100 ms delay even when the address did not answer. With both 0x76 and 0x77 registered, a board without a DPS310 spent a full second there during boot. A failed read is now repeated once right away, because busReadBuf() also fails on a bus error that the I2C driver has just recovered from. Only after a second failed read is the address given up; an answer with a foreign chip ID still gets the 100 ms retries. Also drop the duplicate address comment in the driver and shorten the one in common_hardware.c to one line.
|
@b14ckyy both points are addressed in bfff803 and a139d9c:
|
|
I took a look at this with an AI-based tool I have. It may well be wrong on the point below — please treat it as a question to check rather than a verdict, and correct me if I've misread something.
|
The previous revision gave up on an address after two back-to-back failed ID reads, so a DPS310 that missed both was never retried, while maintenance-10.x tolerates four failed reads spread over 500 ms. The bus layer reports an empty address and a chip that does not answer the same way, so the two cannot be told apart per read. Probe 0x76 and 0x77 in the same five 100 ms retries instead, 0x76 first. Each address keeps the maintenance-10.x retry window, and a bus without a DPS310 costs 500 ms as before instead of 1000 ms for two sequential probes.
|
@sensei-hacker Your reading is right. The early exit was intended (it was the NACK stop b14ckyy asked for), but it cut the tolerance from four failed reads spread over 500 ms to two back-to-back reads. Changed in 6d2505d: Host harness (the real driver against a fake I2C bus, virtual time), time in
For 0x76 alone and for targets that pin one address, every case matches maintenance-10.x. The empty-bus case goes back from 200 ms to the 500 ms of maintenance-10.x. MATEKF722: +144 B flash against the previous revision, +220 B flash / +32 B RAM against maintenance-10.x. Full table in the PR description. |
3 participants
Problem
A DPS310 wired for I2C address 0x77 is not detected (#9958). The sensor answers on 0x77 with SDO high (the default on breakout boards) and on 0x76 with SDO pulled to GND, but
common_hardware.cregisters only 0x76 unless a target definesDPS310_I2C_ADDR. Users in #9958 report a board with the DPS310 on 0x77 that only worked after editing the target, and an external DPS310 that was never found. Only targets that pin the address themselves (BRAHMA_F405/F722) work on 0x77 today.Change
bus.h:DEVHW_DPS310becomesDEVHW_DPS310_0/DEVHW_DPS310_1, the same pattern asDEVHW_IST8310_0/1. The enum is internal (not sent over MSP or stored in config).common_hardware.c: withoutDPS310_I2C_ADDRboth 0x76 and 0x77 are registered. A target that defines the address keeps one descriptor (BRAHMA_F405/F722, ORBITH743); the SPI path stays a single slot.barometer_dps310.c:baroDPS310Detect()probes both registered slots within the same five ID reads 100 ms apart that maintenance-10.x uses for 0x76 alone, reading 0x76 before 0x77 in every round. Each address keeps the full maintenance-10.x retry window, and probing the second address adds no boot time. A slot whose chip ID matches but whose configure fails is de-initialised and dropped; the unused slot is de-initialised at the end.HUMMINGBIRD_FC305/target.c(own descriptor table) uses the_0slot;inav_enums.json/inav_enums_ref.mdcarry the renumbereddevHardwareType_eentries (regenerated, DPS310 delta only).0x76 is read first in every round, so boards that work today see no change in detection or timing.
Test
No hardware with a DPS310 on 0x77 here. The real
barometer_dps310.cwas linked into a host harness with a fake I2C bus (device models on 0x76/0x77 with injected failed transfers, NACK until a given time, or a wrong ID for the first reads; virtual time from the start ofbaroDPS310Detect()). Time spent inbaroDPS310Detect():For 0x76 and for a pinned single address, every row matches maintenance-10.x. The previous revision gave up on an address after two back-to-back failed reads; the bus layer reports an empty address and a chip that does not answer the same way (
busReadBuf()returns false, and the HAL and AT32 I2C drivers treat a NACK as a hardware failure and re-init the bus), so a per-read fast reject cannot keep the retry window for a present chip.Two DPS310s on one bus where the one on 0x76 misses a round while the one on 0x77 answers: the 0x77 sensor is taken.
A foreign chip on 0x77 whose register 0x0D reads 0x10 passes the ID check: in the worst case, a BMP388 whose SENSORTIME_1 register happens to read 0x10,
deviceConfigure()writes the soft-reset bits to register 0x0C (SENSORTIME_0 on the BMP388) before its status check rejects the chip. This only matters when that chip's own driver does not find it first: in autodetect the MS5611, MS5607 and BMP085 drivers probe 0x77 before the DPS310 driver, while the BMP280, BMP388 and SPL06 drivers probe only 0x76 unless the target sets their address.Known limit, unchanged by this PR: the SPL06-001 also reports ID 0x10 in register 0x0D. In autodetect the SPL06 driver runs before the DPS310 driver, so a sensor on 0x76 is claimed by the SPL06 driver as before; an SPL06 on 0x77 (not probed by the SPL06 driver) would now be picked up by the DPS310 driver.
Built with
-DWARNINGS_AS_ERRORS=ON, no warnings: SITL and MATEKF722 for this revision (6d2505d); MATEKF405, IFLIGHT_BLITZ_ATF435, MATEKH743, HUMMINGBIRD_FC305 (own descriptor table), DAKEFPVF405 (DPS310 on SPI) and BRAHMA_F405 (DPS310_I2C_ADDR 0x77) for the previous revision.Flash / RAM (arm-none-eabi-size)
MATEKF722, this revision (6d2505d) against maintenance-10.x 3931fcd and against the previous revision a139d9c:
Previous revision against maintenance-10.x (for reference): MATEKF722 +76 B / +32 B, MATEKF405 +284 B / +32 B, IFLIGHT_BLITZ_ATF435 +252 B / +32 B.
On targets with both addresses registered, the RAM is the second
busDevice_t(32 B) for the 0x77 slot and the extra descriptor is 12 B of flash.Docs
No user-facing documentation states the DPS310 default address.
DPS310_I2C_ADDRin a target still pins one address, as described indocs/development/targets/common-issues.md.