Skip to main content
Drive an I2C bus from the box: discover devices, read and write registers, and run write-then-read transactions with a repeated start.

Handle

Methods

Types

I2cEffectiveConfig

Method Reference

configure(frequency_hz: Option<u32>, pull_ups: Option<bool>) -> Result<I2cEffectiveConfig>

Apply bus settings and read back what actually took effect. A None argument keeps the net’s saved value; anything you pass is applied live and persisted on the box.
Parameters:

scan() -> Result<Vec<u16>>

Scan the default address range.
Returns: Vec<u16> of 7-bit addresses that acknowledged, in ascending order.

scan_range(start_addr: u16, end_addr: u16) -> Result<Vec<u16>>

Scan an explicit inclusive range.

read(address: u16, num_bytes: u32) -> Result<Vec<u8>>

Read num_bytes from the device at address.

write(address: u16, data: &[u8]) -> Result<()>

Write data to the device at address.

write_read(address: u16, data: &[u8], num_bytes: u32) -> Result<Vec<u8>>

Write, then read, in a single transaction using a repeated start rather than a stop and a fresh start. This is what a register read on most parts requires.

Examples

Discover what is on the bus, then read a sensor register

Supported Hardware

Notes

  • Addresses are 7-bit. Pass 0x48, not the 8-bit read/write-shifted forms.
  • A scan hit is not a promise. A scan reports which addresses acknowledged an address byte; a subsequent read() can still fail with No ACK from device at 0x48. This is common on a bus with the controller’s internal pull-ups disabled, where the line can float convincingly enough to look like an ACK. Treat scan() as discovery, not verification.
  • Bus transactions run on the box under the physical device’s lock, so a write-then-read cannot be interleaved by another request on the same device.
  • configure() persists. A frequency you set in one test is still set in the next.