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.
scan() -> Result<Vec<u16>>
Scan the default address range.
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 withNo 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. Treatscan()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.

