I2C IO Speed

[marcpolo]

0 down vote favorite

I have been performing timing measurements on an Android application that communicates to a device by means of an I2C interface. I have discovered that single I2C read and writes are taking around 450ms to execute. I have verified that the I2C interface is running at 400KHz, so I would expect I2C operations on a single byte to take around 170us. It therefore appears that there is an overhead of over 250us to use the I2C drivers within the android kernel? Is this typical of I2C operations using the linux kernel I2C devices? I realise that Android uses a specific flavour of linux, however I'd like to know what to expect on a typical linux system and if there is anything I can do to improve on IO speed. I am confident that I am running on a powerful enough hardware platform. Thanks in advance.

[linnj]

Hi,

That # sounds wrong to me also as that's a long time. I just did a quick check on my 706 board with the i2c eeprom on that board and it's showing reasonable numbers. I see 10KB/sec number when reading 1KB from the I2C eeprom with a quick test (nothing exhaustive, just a sanity check). Have you taken a look at the i2c transactions that are happening to better understand the details?

Thanks.

[marcpolo]

Oops. Typo, what I meant to say is that a single byte read or write takes 0.45ms, not 450ms. This is still quite significant. I have analysed the signal to verify that it takes 170us, so the rest appears to be software overhead.

Is 0.45ms a realistic time?

[linnj · Accepted solution]

I'm no expert here but that overhead on Linux doesn't sound that bad to me as you're talking microseconds now. I don't have any more details than that for now and don't have any other Linux data to compare with.

[milosoftware]

I2C read/write is usually more than 1 byte. You'll be usually sending a chip address (7 bits), R/W bit (1 bit) a register or memory address and data.

Usually, to read a byte from a device, 3 bytes must be transferred

[marcpolo]

Yes, that's right, when I mentioned reading or writing a single byte, I was thinking at software level, I was aware that three bytes would be transmitted and expected this around 170us. What I was getting at in my question was the additional overhead in accessing the I2C device driver that there appears to be.

I think to improve on this I will have to create my own driver.

Thanks all for your input.

[linnj]

I'd be interested if you have numbers from other Linux systems that are much better. 

One thought is that there is an interrupt that happens for the transfer and Linux is not known for being very predicatable as that's why many want to use the RT patch.  I don't know if there's any load on the system when you are measuring this, but a load will cause more unpredictable latencies based on what I've read.

If you believe there are specific bottlenecks in the driver we're very interested in patches to correct that also which may be more expedient that writing a completely new driver.  We have some performance initiatives going and I'll check to see what they found on the I2C.

Thanks.

[milosoftware]

Most systems will place the I2C bytes in a transfer buffer, signal some hardware, and then wait for an interrupt request to indicate that the transfer is complete.

There's quite some overhead in that. If you have a lot to transfer, pack it into a single request. Most chips will for example keep on sending data and autoincrement indexes, so you can quickly read consecutive registers from their memory by just requesting more bytes.

When talking to an I2C device, it's usually most efficient to write your own driver. It isn't hard, try picking a driver that's on your board for experimenting. Audio codecs, power management and IO expanders usually have very simple I2C interfaces that just map all their registers into addresses, so they're good starting points.

[doreenyen]

  Was i2cdetect not part of the distribution ? 

Description:    Ubuntu 12.10

root@pb1i102:src# which i2cdetect
root@pb1i102:src# which I2cdetect
root@pb1i102:src# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

[doreenyen]

Okay, I got source and make, make install  for i2cdetect (is there any better i2c test software ?)

http://www.lm-sensors.org/wiki/I2CTools

On our zc706 which I'd previously tested cat to and from EEPROM, my question is when running in a loop,

i2cdetect -l

Why we did not see SCL nor SDA on the inputs to the level shifters supplying the i2c mux pca9548 as shown by

http://www.arbot.cz/post/2012/11/14/PS-I2C-in-Xillinux.aspx

Really the i2c is the last major IO to verify on our custom boards so advice would be greatly appreciated.

[doreenyen]

Happily saw SCL and SDA signals on input to DS2482-800 on i2c-1,

we'll have to troubleshoot i2c0@e0004000 goes offboard on our custom board based on zc706.

[doreenyen]

Hurray, both i2c-1 and i2c-0 work fine.