I2C protocol speeds

Question

I'm trying to make a persistence of vision display (Example: https://www.youtube.com/watch?v=QAGnpKz7zvY) that will display images and videos. I have purchased an LED strip that has 72 LEDs that communicate over I2C. The goal is to implement a polar coordinate grid and light the LEDs up to the appropriate colors as it passes over the image. Upon my research for the project I've seen others saying I2C is a slow protocol. My question is I2C appropriate for this application of high frequency color changes to 72 LEDs?

Answer 1

It seems that you have got a useful answer, but to the wrong question.

This isn't really an answer to what you should have asked, but it's too long for a comment and it does help you (and future readers) by explaining what you should be researching.

You asked about the I2C interface:

is I2C appropriate for this application of high frequency color changes to 72 LEDs?

However the Amazon product page for your LED strip, which you later mentioned in a comment, shows that this LED strip is a very common type which does not use I2C!

As kindly pointed out by "mmmm" in their comment, this is a WS2812B-based LED strip (see below image from that Amazon page, where I have highlighted the relevant text):

These (and similar addressable LEDs) use the "NeoPixel" protocol, which is different to I2C and has different timing requirements.

This is an example of an XY-problem. You asked about what you thought was the problem (I2C bus speed) but didn't reveal enough information, until later on, about the real device. Then we saw that I2C wasn't involved at all :-(

You can research terms like WS2812 protocol, or NeoPixel protocol, or WS2812 library (to see examples of other people's code). (Note that the WS2812B datasheet shows slightly timing to the WS2812 timing.)

Answer 2

OK, first of all there are at least three standard I2C speeds:

• Classic 100kHz (10µs bit time)
• Fast 400kHz (2.5µs bit time)
• High speed 3.4MHz (only the data phase is high speed, for simplicity 300ns bit time)

these works as normal bidirectional I2C buses (the high speed has a negotiation trick for compatibility and the transceiver is different but the capabilities are more or less the same)

There is altro another kind of I2C called Ultra Fast Mode which is I2C only in name since it's simplex (it can only send master to slave, there's not even an acknowledge slot). Ultra fast mode is actually designed for LED control and is pumped at 5 MHz (200ns bit time).

High speed and ultra fast mode are really niche protocols, there's only an handful of ICs supporting them. The bulk of I2C peripheral these days is fast mode.

Now, regardless on the protocol used (which is relevant for cabling, as commented), you can estimate your refresh rate. Of course it depends on the kind of protocol used, so the part number will be useful*!

Let's assume the absolutely best case, when the strip only requires one address bit and one byte for each LED (technically the extreme case would be one bit for led, but do not oversimplify).

Each byte on I2C takes 9 bit times: 8 data and one acknowledge slot. There's also a one-and-half-bit overhead for the start-stop-restart condition but let's ignore these.

So, one address plus 72 data bits would be 657 bit times, assuming you can pump the I2C controller fast enough (with DMA, for example). At fast speed (the most common these days) this would take slightly less than 16.5ms; it's hardly fast enough for a polar display; assuming a minimum of 24Hz of refresh rate (24 RPM) you would have… 2.5 polar strips for scan.

It will get better with greater bit packing and faster transmit modes, just redo the computations.