Re: RGB LCD Shield (ID714)
The Wire library on Teensy 3.0 runs the I2C at 100 kHz. That exactly matches Arduino, which uses 100 kHz.
If you edit Wire.cpp, you can uncomment lines to configure for 400 kHz or 1 MHz. Likewise, the AVR can use I2C at higher speeds, merely by editing the code. The Wire library code on AVR is not very efficient, and of course the AVR is a slower processor, so it might get much faster if you go higher than 400 kHz.
At faster I2C rates, the rise time from the pullup resistors and the capacitance on the lines becomes an issue. On AVR, using only the internal pullups, it just barely works at 100 kHz. Just view the waveforms on a scope to see the issue. 4.7K resistors work very nicely. Often advice on the pullups is given in terms of the "worst case" I2C bus capacitance, which I believe is 400 pF. When only 2 devices are connected on a breadboard, the capacitance is probably in the 30 pF range. (you could easily measure it with touchRead, since the I2C pins support touch sensing on Teensy 3.0)
In Teensy 3.0, there are 3 main clocks: CPU, BUS, and Flash. When Teensy 3.0 is overclocked to 96 MHz (which very nicely, even though it's technically overclocking), the Bus clock is still only 48 MHz, and the Flash clock is 24 MHz. Nearly all peripherals run from the Bus clock, so the I2C peripheral is actually running from the exact same 48 MHz Bus clock when the CPU is at either 96 or 48 MHz.
It's also worth mentioning that the CPU is rarely twice as fast at 96 MHz, due to the small cache size in the flash controller. Only tight loops truly run at twice the speed of 48 MHz. Of course, just like AVR, the overall net performance of any application usually depends on a lot of complex software factors. I2C is a very nice protocol, but its speed is moderate. Using it as a replacement for GPIO (as this library does) is quite slow, regardless of the CPU issuing the requests.