What kind of latency is involved into the polling of a large number of i2c slaves? I have an array of 64 i2c sensors slaves which need to send 2 bytes each to the master as rapidly as possible.
As far as I understand i2c, there is one bit for the start condition, 8 bits for the address and mode, then another bit for acknowledge, then the 16 bits of data, another acknowledge and the stop condition. Totaling at 28 bits per slave for the data and protocol overhead.
So, at 400 kbit, I should be able to hit about 223 reads from the entire array of slaves per second, or about 4.48 msecs for each sweep. Is that correct, or I am missing something?
Best Answer
You're missing the part where slaves can do what is called clock stretching by holding the clock line for as long as they need to get ready.
So, without looking into the datasheet of each of your sensors, this will be impossible to answer.
However, many I²C devices simply don't do clock stretching, so your calculation might work out, if you add a bit of pause just to be sure everyone on the bus noticed the stop condition.
64 I²C slaves smells a lot like address collision (many I²C device types come with a fixed address, or maybe a set of 8 selectable addresses) – it might, very well, be possible that a different, possibly hierarchical bus architectures with microcontrollers polling "their" sensors and then communicating the "aggregate" data to the main MCU is much cleaner to handle. Especially considering that I²C is an externally pulled-up bus, and ensuring this works well with a 64-device bus is not really inherently trivial.
Edit: turns out each of your sensor is a microcontroller anyway.
Then, why not simply make a giant array of shift registers? SPI units are typically designed for exactly that purpose, and have shift registers internally. That way, you can make a daisy-chain of SPI devices, and save yourself the addressing overhead.