Correct the I2C bus descriptions in the hardware reference

[mairas]

The hardware reference listed the TMP112A at 0x4b on the system I2C bus. The sensor is wired to the RP2040's own I2C bus (temp_sensor.kicad_sch is a subsheet of control_mcu.kicad_sch, connected to the local I2Cm bus), so the CM5 never sees it there. Anyone scanning I2C1 would find only the controller at 0x6d.

Review of that removal turned up a second error in the same paragraph. The sentence describing I2C0 was wrong on four counts, and losing the 0x4b row above it would have left a reader concluding the sensor lives on the bus it names. Traced through the netlist, the buses are distinct:

Bus	CM5 pins	Goes to	Pull-ups
I2C1	GPIO 2/3	40-pin header, RP2040 at 0x6d	—
I2C0	dedicated SDA0/SCL0	MIPI0	none on the carrier
I2C_DPHY1	ID_SD/ID_SC via 0 Ω R135/R136	MIPI1	2.2 kΩ R54/R55
HDMI0/HDMI1 DDC	dedicated HDMI pins	HDMI connectors	—

Both corrections are carried into all nine translations, each against its own glossary, with the glossaries extended where the new sentence needed a term they did not fix (resistor, onboard, dedicated, pull-up). translation_status.py reports every language current; mkdocs build --strict, check_anchors.py, check_glossary.py and check_typography.py pass. The one glossary miss the checker reports, French blackout, predates this branch and is filed as #44.

🤖 Generated with Claude Code

[mairas]

Code review — PR #42

Scope: docs/technical-reference/hardware.md, 2 changed lines, base ec5b754.
Intent: The TMP112A is not on I2C1. Remove the row so the table matches what a CM5-side scan finds. No replacement prose about the sensor's real bus — deliberate, on the grounds that a device the host cannot see does not belong in the user-facing reference.
Mode: interactive. Reviewers: correctness, testing, maintainability, project-standards (4 always-on; no conditionals — documentation-only diff, no code, no API surface, no error handling).

Verification of the change itself

Confirmed from the netlist in HALPI2-hardware/HALPI2.kicad_pcb, by footprint membership per net:

Net	Footprints
/I2C1.SDA/.SCL	J10 (CM5), J11 (GPIO header), U9 (RP2040)
/Controller/I2Cm.SDA/.SCL	U9 (RP2040), U53 (TMP112A), R35/R36 (10 kΩ)

The TMP112A hangs off the RP2040's private bus and is absent from I2C1. temp_sensor.kicad_sch is a subsheet of control_mcu.kicad_sch, its I2C sheet pin bussed to the local I2Cm label. The removal is correct.

Not verified against hardware: halos.local did not resolve, so no i2cdetect -y 1 capture. Evidence is netlist + firmware source only.

P2 — Moderate

#	File	Issue	Reviewer	Conf.	Route
1	docs/technical-reference/hardware.md:180	The sentence left standing below the table is wrong on four counts, and it now absorbs the confusion this PR removes	correctness, testing	0.90	gated — needs a decision

The controller I2C bus (I2C0, internal to carrier board) is used for HDMI DDC and MIPI display communication, with 2.2kΩ pull-ups.

• "controller I2C bus" — /I2C0 reaches J10 (CM5), J15 (display FFC) and U14 (ESD array). U9, the RP2040, is not on it. By this page's own naming (0x6d = "Carrier board controller"), I2C0 is not the controller's bus. The RP2040's bus is /Controller/I2Cm.
• "HDMI DDC" — DDC runs on /CM4 Highspeed/HDMI0.SDA|SCL and HDMI1.SDA|SCL, dedicated CM5 pins to J17/J18. Not I2C0.
• "2.2kΩ pull-ups" — R54/R55 (2.2 kΩ) sit on /CM4 Highspeed/I2C_DPHY1, the other display connector's bus (J16, U18). I2C0 carries no pull-ups on the carrier. The RP2040 bus uses R35/R36 at 10 kΩ.
• "internal to carrier board" — I2C0 leaves the board through FFC connector J15.

Why it matters here rather than as a standalone nit: a reader who has just lost the 0x4b row reads the next sentence, sees "controller I2C bus", and lands on exactly the wrong conclusion this PR set out to prevent.

Pre-existing, same paragraph as the edit. Routing decision needed: fix in this PR, or file a follow-up issue.

P3 — Low (applied)

#	File	Issue	Reviewer	Conf.	Route
2	docs/technical-reference/hardware.md:175	"hosts a single device" reads as a bus constraint, not an inventory	maintainability, project-standards	0.75	applied

docs/user-guide/hardware.md:210 tells users the bus "can be shared with HAT devices" and the GPIO table on this same page marks GPIO 2/3 "Shared? Yes". A reader with a HAT installed scans the bus and sees the reference contradicted. Changed to "hosts one onboard device".

Advisory

The stated reason for omitting replacement prose — the sensor is not visible to the user — does not hold as written. docs/user-guide/software.md:294 documents T_pcb 35.2 °C in the halpi status sample output. The RP2040 polls the TMP112A at 0x4b on its own bus and serves the value to the host as command 0x24 through 0x6d, so the reading is user-facing even though the device is not. Whether that warrants a sentence anywhere in the reference is the author's call; recorded here as a premise check, not a request.

Coverage

• Suppressed: 0 findings below the 0.60 confidence gate.
• Untracked and excluded from scope: .claude/, book/.
• Testing gap (pre-existing, not automatable at reasonable cost): CI runs mkdocs build --strict only, which validates structure and links. Nothing in this repo can fail on a false hardware claim. The 0x4b row survived until someone noticed it by hand; the I2C0 sentence directly beneath it is still wrong. Device output pasted into the PR is the only practical control for hardware-reference edits.
• Cross-repo drift: the I2C address and command tables restate facts owned by HALPI2-firmware (i2c_secondary.rs command map, i2c_peripheral.rs TMP112_ADDR) with no link or generation step. Drift is invisible in both directions.

---

Verdict: ready with fixes. The removal is correct and verified against the netlist. Finding 2 is applied. Finding 1 needs a routing decision — fix here or file an issue — before merge.

[mairas]

Finding 1 fixed in 5717188. One correction to what I proposed above: I2C0 is not on GPIO 0/1.

Traced through the netlist, the four buses are distinct:

Bus	CM5 pins	Goes to	Pull-ups
I2C1	GPIO 2/3	40-pin header (J11), RP2040 at 0x6d	—
I2C0	dedicated SDA0/SCL0 (pins 82/80)	MIPI0 (DPHY0 sheet, ESD U14)	none on the carrier
I2C_DPHY1	ID_SD/ID_SC via 0Ω R135/R136	MIPI1 (DPHY1 sheet, ESD U18)	2.2 kΩ R54/R55
HDMI0/HDMI1 DDC	dedicated HDMI pins	HDMI FPC connectors (J17/J18)	—

RaspberryPi-CM45Lite-A pins 80/82 are named SCL0/SDA0 in the symbol and carry /I2C0, which is a different net from /CM4 GPIO/ID.SDA|SCL. The 2.2 kΩ resistors the old sentence attributed to I2C0 sit on the MIPI1 bus instead.

New text:

The MIPI and HDMI connectors use separate buses. I2C0 (CM5 SDA0/SCL0) serves MIPI0. MIPI1 uses the CM5 ID_SD/ID_SC pins through 0Ω links, with 2.2kΩ pull-ups. HDMI DDC runs on dedicated CM5 pins to the HDMI connectors.

One observation left unactioned, since it is outside this PR's scope: line 171 says "All remaining GPIO pins are available for HATs and user applications." GPIO 0/1 are the HAT ID EEPROM pins and R135/R136 tie them to MIPI1, so a HAT EEPROM and a MIPI1 display share that bus. Worth a sentence somewhere, or a deliberate decision that it is too niche to document.

[github-actions]

Translation status

da — 20 current
de — 20 current
es — 20 current
fi — 20 current
fr — 20 current
it — 20 current
nb — 20 current
nl — 20 current
sv — 20 current

Every translation of the pages in scope is current.