These changes may have a negative impact in cases where the timeout is real. Have you tried "refreshing" the deadline between the write and read section of I2C.tx and seeing if that solves the issue as well? (right above rxStart declaration)

deadline += timeout_us

Good idea! Please take another look. I also expanded the commit message.

Hol up. I believe the deadline can never trigger now. You are declaring the deadline in-loop, so it is refreshed every time a byte is written over I2C. I suggest going back to the deadline declaration at the start of the function and refreshing it after the write section (right above rxStart declaration). This is because I suspect your program is timing out during the read section due to how the conditions are ordered. If this is not the case let me know

What is the deadline for, other than buggy i2c hardware or faulty data lines?

The calling code says

	// timeout in microseconds.
	const timeout = 40 * 1000 // 40ms is a reasonable time for a real-time system.
	return i2c.tx(uint8(addr), w, r, timeout)

but TinyGo is no way near "a real-time system" unless there's only one goroutine running.

With your proposed change (deadline extension just before starting read), there's still a risk of unfortunate goroutine scheduling triggering a timeout.

Simplified case, for the transmission loop:

deadline := now() + 40ms
for _, b := range txBuf { // for each byte to transmit
   i2cTransmit(b)
   for i2cTxBufferFull() {
      if now() > deadline { return ... }
      gosched() // Takes, say, 100ms of time.
   }
}

As far as I can tell, the second byte will immediately timeout if i2cTxBufferFull returns true just once. My proposed change does

for _, b := range txBuf {
   i2cTransmit(b)
   deadline := now() + 40ms
   for i2cTxBufferFull() {
      if now() > deadline { return ... }
      gosched()
   }
}

which ensure that no matter how long a gosched takes, the timeout will only happen if at least 40ms passed with a full buffer.

OK, I've just realized I had a miconception about the looping logic when I asked you to perform both changes. Can we try your original change and doing some basic math to calculate ideal timeout?

Lets look at a scenario: We have our RP2040 running a slow 10kHz I2C baud. The time it takes for transaction to complete is at least (len(w)+len(r))*bitSendTime where bitSendTime is 1./10000 seconds = 0.1ms = 100us. We can thus set the timeout to be (len(w)+len(r))*100, and we can calculate it correctly. With your original change then we can then discard the time spent between byte transmits (which I had not realized the I2C algorithm could block between every single byte.

I'd also add in a security factor, like *2 or something of the sort

Done. I didn't add a security factor, because that's already builtin to the pessimistic bus frequency (10kHz).

I've pushed an update that replaces the bitrate computation with a simple "long" timeout. I also replaced another tight deadline in I2C.disable. I was still seeing timeouts, presumably because of an interrupt handler that can run for a while because of real-time constraints.

Longer deadlines are not great, but my rationale is that the deadlines are only there for faulty hardware or programming errors. And they're not that long (40ms). EDIT: finally, the deadlines can be tightened in a future DMA implementation.