Question

I have been performing timing measurements on an application that communicates to a device by means of an I2C interface. I have discovered that single I2C read and writes are taking around 450us 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. Could there be an overhead of over 250us to use the I2C drivers within android? Does anyone know of ways to improve this speed.

Thanks in advance.

Marc.

Answer 1

I guess your expected delay comes from the time/bit or something like that. But when you send data to the I2C from a system with an OS (Android or Linux or others), you have to go through all the layers to get to the actual I2C. And most likely, this driver is in the Kernel. Since it’s a hardware ressource, there is also some form of gating to prevent several piece of code to use the I2C at the same time. Also, sometimes for some devices, the system might not send the data immediately but it could be postponed a bit. It might not be your case though.

Also, for some hardware devices, when you send data it does not go through a regular data write but it is sent through other means that might be more efficient for big chunks but less for small chunks costing you some latency to start with. An audio stream on the I2C is a good example of that. In the system, it’s often a data buffer and a DMA channel setup to transfer the data to I2C at the proper rate to get the audio you want. It’s very efficient for the audio streaming purpose but not great to send just a few bytes.

So, I’m not surprised of your measurement.

In my mind, if you want to improve it, you will have to go through the pain of writing your own driver. Then, you become platform dependent. If it’s a custom system, it’s fine but if it’s a consumer application that must run on any tablet, it’s a not viable.