Your prototype has a sensor and a small controller that reads it reliably. Now you want to add a separate display board, or let a test computer inspect that sensor while the existing firmware keeps running. Both need the same measurements. Connecting both boards to the sensor's two I2C wires looks like the shortest route.
Before doing that, decide whether both boards actually need to control the sensor. Often, one board can collect the readings and pass them to the other. That leaves one place responsible for settings, measurement timing and errors. If both boards must make their own transactions, sharing the wires becomes an engineering requirement that needs explicit hardware and software support.
This distinction matters during integration, when two working demonstrations become one product. The diagrams below explain the bus mechanisms behind the decision. They are conceptual, not evidence that a particular two-board prototype has passed a shared-bus test.
Each gray line in the diagram stands for a two-wire bus connection, not one electrical wire. The topology says nothing about whether particular boards or drivers are compatible.
Share the measurement before sharing control
Imagine a display showing readings from an environmental sensor while a second controller records them. If each controller independently changes the sensor's measurement mode, the display and log can disagree even when every electrical transaction succeeds. A sensor may also have registers that clear when read. Whether either behavior applies depends on the actual device.
Start by listing what each board needs: a current reading, a timestamp, a setting change, or direct access for diagnostics. If the display only needs a value, the acquisition controller can send a message containing the value, its age and a validity flag over an agreed connection. The display should then show a stale or unavailable state when updates stop, rather than quietly presenting an old value as current.
This is a real integration question. In an NCD community question dated August 27, 2021, a developer wanted two applications, LabVIEW and Python, to reach the same ADC bus through separate adapters. The question illustrates the need to share data. The reply's blanket statement that I2C cannot have multiple controllers is not a general rule of the protocol, and it does not establish what those particular adapters support.
What happens when both controllers start together?
I2C does provide a multi-controller mechanism. Controllers synchronize the clock, then compare the data they intend to send with the level actually on the bus. These features must be supported by the implementation; having an I2C connector is not enough.
Releasing a line is different from forcing it high. One controller may finish its LOW interval while another still holds SCL low; the first waits. Once all participating controllers release the line, the pull-up raises it, and the first controller to finish its HIGH interval brings it low again.
Arbitration then proceeds on SDA while SCL is high. If a controller intends a 1 but reads a 0, it loses and releases its SDA output. Matching bits can continue for a while before a difference appears. These rules are described in NXP's I2C specification UM10204, revision 7.0, sections 3.1.7 and 3.1.8, Figures 7 and 8. A simple snapshot of SDA being high is not a sufficient bus-free check.
For a project owner, the consequence is practical: the second board cannot be treated as an ordinary extra sensor. Someone must verify how its controller and driver handle losing arbitration, waiting, retrying and reporting failure. Two individually successful sensor demos do not answer those questions.
Choose an ownership arrangement you can explain
There are three useful arrangements to discuss with the engineer integrating the prototype. The right one follows from why the second board needs access.
- One controller owns the sensor and forwards readings. Fits when a display, logger or application only needs the data. Still to settle: message format, freshness, who owns the settings, and behavior when the owner is unavailable.
- Access is handed between controllers. Fits when a service tool needs temporary direct access. Still to settle: a verified handover or suitable switching design, including startup, reset and release behavior.
- Both controllers use a multi-controller bus. Fits only when independent direct access is a real requirement. Still to settle: compatible hardware and drivers, arbitration handling, sensor state ownership and measured behavior under contention.
A handover cannot depend only on both programs usually avoiding one another; they can restart at different times. Nor does calling a part an "I2C multiplexer" establish that it safely arbitrates between upstream controllers. Select and review the actual circuit for the job.
Even with working bus arbitration, assign responsibility for sensor configuration. Who may reset the sensor? Who selects its range? Can one client's diagnostic read change what the other receives? These are application rules, and bus arbitration cannot invent them for the product.
Make the next prototype test answer the decision
Before connecting a second controller, record the two board revisions, firmware versions, sensor part number, pull-up supply and the proposed ownership arrangement. Ask the engineer to identify the hardware and driver documentation supporting that arrangement. If that support is unclear, use a single owner while investigating; do not turn an unverified shared connection into the default design.
The verification plan should exercise situations the finished prototype can actually meet: both boards starting together, one restarting during a read, competing configuration requests, and the sensor becoming unavailable. For each, define what the display or application should show, how long it may wait, and what the logs should preserve. These are proposed checks; we have not run a shared-bus test for this note.
If the project only needs both boards to see the same measurement, forwarding the reading may settle the problem with fewer moving parts. If it truly needs independent sensor access, make that explicit before the next board or enclosure revision.