NAME

SYNOPSIS

DESCRIPTION

The options are as follows:

-a address

7-bit address on the I2C device to operate on (hex).

-b

binary mode - when performing a read operation, the data read from the device is output in binary format on stdout; when doing a write, the binary data to be written to the device is read from stdin.

-c count

number of bytes to transfer (dec).

-d r|w

transfer direction: r - read, w - write.

-f device

I2C bus to use (default is /dev/iic0).

-m tr|ss|rs|no

addressing mode, i.e., I2C bus operations performed after the offset for the transfer has been written to the device and before the actual read/write operation.

tr

complete-transfer

ss

stop then start

rs

repeated start

no

none

Some I2C bus hardware does not provide control over the individual start, repeat-start, and stop operations. Such hardware can only perform a complete transfer of the offset and the data as a single operation. The tr mode creates control structures describing the transfer and submits them to the driver as a single complete transaction. This mode works on all types of I2C hardware.

-n skip_addr

skip address - address(es) to be skipped during bus scan. There are two ways to specify addresses to ignore: by range 'a..b' or using selected addresses 'a:b:c'. This option is available only when "-s" is used.

-o offset

offset within the device for data transfer (hex). The default is zero. Use “-w 0” to disable writing of the offset to the slave.

-r

reset the controller.

-s

scan the bus for devices.

-v

be verbose.

-w 0|8|16

device addressing width (in bits). This is used to determine how to pass offset specified with -o to the slave. Zero means that the offset is ignored and not passed to the slave at all.

WARNINGS

It is very easy to render the whole system unusable when such configuration data is deleted or altered, so use the “-d w” (write) command only if you know exactly what you are doing.

Also avoid ungraceful interrupting of an ongoing transaction on the I2C bus, as it can lead to potentially dangerous effects. Consider the following scenario: when the host CPU is reset (for whatever reason) in the middle of a started I2C transaction, the I2C slave device could be left in write mode waiting for data or offset to arrive. When the CPU reinitializes itself and talks to this I2C slave device again, the commands and other control info it sends are treated by the slave device as data or offset it was waiting for, and there's great potential for corruption if such a write is performed.

EXAMPLES

• Scan the default bus (/dev/iic0) for devices:

  i2c -s

• Scan the default bus (/dev/iic0) for devices and skip addresses 0x56 and 0x45.

  i2c -s -n 0x56:0x45

• Scan the default bus (/dev/iic0) for devices and skip address range 0x34 to 0x56.

  i2c -s -n 0x34..0x56

• Read 8 bytes of data from device at address 0x56 (e.g., an EEPROM):

  i2c -a 0x56 -d r -c 8

• Write 16 bytes of data from file data.bin to device 0x56 at offset 0x10:

  i2c -a 0x56 -d w -c 16 -o 0x10 -b < data.bin

• Copy 4 bytes between two EEPROMs (0x56 on /dev/iic1 to 0x57 on /dev/iic0):

  i2c -a 0x56 -f /dev/iic1 -d r -c 0x4 -b | i2c -a 0x57 -f /dev/iic0 -d w -c 4 -b

• Reset the controller:

  i2c -f /dev/iic1 -r

SEE ALSO

HISTORY

AUTHORS