Just a question

[iz8mbw]

Hello. I'm interested to use an USB to I2C chip/board in order to have a "pure" I2C Master bus. I need it in order to replace a Raspberry Pi with a Linux machine running on x86 via Proxmox.

Currently I poll I2C sensors via the I2C Master bus generated by the Raspberry Pi, all ok.

So I'm looking for an USB to I2C chip/board that can handle a "pure" I2C Master bus so I can continue to read I2C sensors.

I see that the FTDI FT260 and the Silicon Labs CP2112 are the "right" chips that can do what I need.

Both chips are supported in the Linux Kernel but it seems the Silicon Labs CP2112 have some "limitation" since when the command "i2cdetect" is executed the reply contain the message: Warning: Can't use SMBus Quick Write, will skip some addresses.

So it seems the Silicon Labs CP2112 has some limitation for the addresses.

Well, does the FT260 has the same limitation? In other words, can I use FT260 like the I2C bus generated by the Raspberry Pi?

Thanks!

[MichaelZaidman]

Hi Fabio,

The i2cdetect uses the SMBus Quick command by default to scan devices on the I2C bus. The FT260 implements an I2C bus controller. The SMBus is derived from I2C, but there are several differences between the specifications of the two buses in the areas of timing, protocols, operation modes, and electrical characteristics.

One of the differences is that the I2C devices allow the slave not to ACK its slave address, but SMBus requires it to always ACK it as a mechanism to detect a detachable device’s presence on the bus. Since FT260 is the I2C bus controller, it does not acknowledge the SMBus Quick write command, which sends a single bit to the device at the place of the RD/WR bit.

In the past, the ft260 driver attempted to mimic the SMBus Quick Write functionality by writing a single byte as the SMBus Byte Write command does.

Usually, one byte in the SMBus Quick Write will be fine. However, it may cause problems with devices with a control register at offset 0, like i2c muxes, for example, when scanned with the i2cdetect utility.

The i2cdetect with the "-r" option uses the SMBus Read Byte command, which is a reasonable workaround. To prevent the I2C bus from looking at write-only devices (most notably clock chips at address 0x69), use the "-r" option with scanning range parameters.

I hope this will help. Michael

[MichaelZaidman]

Example of running i2cdetect via ft260 without and with -r flag.

$ sudo i2cdetect -y 13
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

$ sudo i2cdetect -y -r 13
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

[iz8mbw]

Hi Michael and thanks. This is what "i2cdetect" can see on my bus on a Raspberry Pi (using the I2C bus generated by the Raspberry Pi SoC):

root@rpi3:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77
root@rpi3:~#

If, I use the "-r" option on the same bus on a Raspberry Pi, the device "0x44" disappears:

root@rpi3:~# i2cdetect -r -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

So, if I use the ft260, can I see the device (sensor) at 0x40 address and interrogate it like I do now with the Raspberry Pi?

[MichaelZaidman]

As I mentioned, the i2cdetect may not detect the device at 0x44, but it does not mean you cannot access it with different tools like i2cget/i2cset. You should be able to access the device with either cp2112 or ft260.

[iz8mbw]

OK, so the "limitation" should be only at detect level and not also at reading level. Thanks!