AVR Freaks

You can adjust the Peter Fleury I2C library to run faster than 400KHz (I2C speed).   I believe that there is a "bit-banging" option that is written in assembly language.  By rewriting this code, you should be able to get 1 or 2 MegaHertz in I2C speed. 

I2C speed is limited only by the speed that the released signal can rise from gnd to Vcc.  This speed is primarily determined by the number of devices on the I2C line and the value of the pull-up resistors on SDA and SCL.   These pull-ups are usually 3-5K ohms.    Reduce these to 680 -- 1K ohms and change the I2C code.  Doing bit-banged I2C on the SDA and SCL lines is basically changing the line from a input (a released line) to an output that is pre-set to logic zero (an asserted line).

A fair slug of cpu time? If the twi is running at 1MHz, which means it will interrupt, say, every 9 or 10 microseconds. This means the cpu will be working hard servicing those interrupts and doing just that will consume a fair amount of the processor's cycles. If you interrupt every 10uS with a 20MHz clock, you have 200 cpu cycles between interrupts. The isr has to stack the processor state, service the twi then restore the processor state. You've burnt at least 100 cycles already at a guess. It might actually be worse. More modern processors have fifos that buffer the data for the twi, so that it interrupts less.

Display devices like SSD1306 or SSD1327 are very noticeable.   Especially with animations that might be 1024 bytes or 8192 byte transactions.

Most devices are fine on 100kHz.    e.g. 4 byte transactions

Fleury code is polled.   So yes,  your app will block until completion.

Interrupt code means that your app can continue normally.

Regarding bus speed.   You can achieve 400kHz with a 16MHz mega328P.

But do some sums.   400kHz bus means 22.5us per byte.    Or 360 CPU cycles @ 16MHz.    Fine for typical 80-cycle ISR()

The standard 100kHz bus means 90us per byte.    An 80-cycle ISR() will struggle @ 1MHz.

The I2C bus will wait for a slow CPU.   So as Mr Winterbottom has said,    not a limiting factor for sensors.

Look very carefully at your application.    A quick burst with polling may be preferable to interrupt-driven code.

Decisions are much easier when you put some numbers into them.   e.g. size of traffic,  CPU speed, proposed AVR.

David.

You have a Start + 2 Write + Stop.   i.e. 3 bytes @ 400kHz = 67.5us + a few us for housekeeping.

67.5 us @ 16MHz is 1080 CPU cycles.

You will never achieve a real 800kHz.   But if you did,  it would be 540 cycles.    Your 850 cycles seems as good as you can expect.

The PCA9685 seems to be intended for ambient lighting.   The human eye is not going to want ambient colours to change in 70us.     Movies are 30FPS i.e. 33333 us between Frames.

As a general rule,   you set background colours every few minutes and not microseconds.

What are you trying to do?

David.

I don't see the practical application.

You appear to have 32 LEDs performing a sequence.

In real life you would set each LED to a specific brightness and job is done.

Occasionally you might update the brightness of individual LEDs.

If you do want to write a new PWM pattern it is a total of 36 I2C bytes to update all 32 LEDs e.g. 810 us @ 400kHz bus.

Ok,  that is much longer than an SPI Slave would need.   But it is more than any human would notice.

Say that you want to give a 32-channel music display.    It is average light intensity not individual sound waves that your eye responds to.

David.