2
\$\begingroup\$

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?

\$\endgroup\$
  • 1
    \$\begingroup\$ Your general principal seems ok but I don't agree with your arithmetic - I make a single scan be 28*64*2.5 = 4480us. This is about 200 times per second. \$\endgroup\$ – Kevin White Mar 6 '17 at 22:07
  • \$\begingroup\$ @KevinWhite - my bad, I divided 400k by 28 rather than by 28 * 64 as I should have. \$\endgroup\$ – dtech Mar 6 '17 at 22:11
  • \$\begingroup\$ Given that you mentioned that your slaves are MCUs and not limited to I2C, why not use SPI (or a somewhat reduced version thereof?) \$\endgroup\$ – uint128_t Mar 6 '17 at 22:38
  • \$\begingroup\$ @uint128_t - mostly because I have a bag of attiny85s which I was hoping to use, and they are kind of sparse on pins. \$\endgroup\$ – dtech Mar 6 '17 at 23:01
  • \$\begingroup\$ Have you considered 5 MHz Ultra Fast-mode, which is unidirectional? \$\endgroup\$ – StainlessSteelRat Mar 7 '17 at 0:01
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ My "sensors" are just attiny's reading from piezos and pots. Each slave should have user configurable address, so it is up to the user to provide each sensor with a unique address. I was thinking of doing more of a "tree like" topology, but the overhead of switching alone doesn't seem to be that detrimental, so if possible, I'd like to hook the 64 slaves directly, after all, 127 outta be possible, even 1024 with 10 bit addressing. Also, if I do the tree thing, I will have to add more bytes so I can then parse which data comes from where, needless overhead and complexity as it seems. \$\endgroup\$ – dtech Mar 6 '17 at 21:58
  • 1
    \$\begingroup\$ ah, ok, if you decide on the addresses, yes, that will work. Really play close attention to pulling up the lines – with that many devices, you probably have a lot of parasitic capacitance on the I²C lines, and thus, you'll need low-value ("strong") pull up resistors, and you must hope your devices can deliver that much energy. I have an idea. Wait for my edit. \$\endgroup\$ – Marcus Müller Mar 6 '17 at 22:00
  • \$\begingroup\$ I am not really an expert in the field, could you provide some information about the wiring and operational principle of the suggestion from your edit? \$\endgroup\$ – dtech Mar 6 '17 at 22:14
  • 1
    \$\begingroup\$ Also, a clarification - I may have up to 64 slaves, but it is not a given, arbitrary configurations are possible, and even though all slaves report 2 bytes, those bytes mean different things. Will that be compatible with an array of shift registers, because it kind of sounds like the configuration needs to be static and known in advane in order for this to work? Whereas with i2c slaves what I plan to do is probe the connected slaves and determine the order of operation accordingly. \$\endgroup\$ – dtech Mar 6 '17 at 22:22
  • \$\begingroup\$ @ddriver Since you've got intelligent sensors nodes, you could consider some form of data compression. For example, if the readings from the sensor have't changed since last time it was polled, is transmits 1 byte instead of 2. To keep errors from accumulating, it transmits full payload every 8th poll even if readings haven't changed. \$\endgroup\$ – Nick Alexeev Mar 6 '17 at 22:59
-1
\$\begingroup\$

As far as I understand i2c

it depends on how the slave is structured. a typical process involves sending the device id + write, and then the address; restart, and then device id, read two bytes. so for a total of 5 bytes. 9 bits per byte, that's about 50 bits per device.

the rest of the math is easy.

as rapidly as possible.

then you picked the wrong protocol. i2c is the opposite of "fast".

\$\endgroup\$
  • \$\begingroup\$ There is no "address" involved here aside from the slave address, or as you put it - the id, the slave doesn't need to be told what to do. \$\endgroup\$ – dtech Mar 6 '17 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.