oled 100fps
Being born in the 70s and growing up in the 80s, I cannot imagine designing any kind of electronics without integrated stop-watch support. Of course this makes no sense, because one rarely needs a stop-watch, but nevertheless this task always comes with some engineering questions that depend on the hardware and software.
From an application point of view, a manual stop-watch doesn't need to have a higher resolution than 100ms, because hitting start-stop manually in sync with what you see, for sure has a jitter in that order of magnitude.
Anyway most implementation offer 10ms resolution, which often is not reached by the display. So you will not be able to see the 10ms digit counting its individual step due to either the software update rate being too slow or the display pixel switching not fast enough.
OLEDs could be capable of that task. One very popular family of OLED drivers is the SSD130x series, which can be driven in SPI-, I2C-, and parallel-mode. Parallel mode is seldomly used, because the wiring complexity is highest, but the performance cannot match SPI at all. So parallel mode is only relevant, if you use a micro-controller that neither has an SPI or I2C, but has enough GPIOs availble fot that task.
I2C only requires VCC, GND, SDA, and SCL. So with 4 wires you are ready to go, and the ports and wiring can even be shared among multiple I2C slaves. SPI in contrast requires VCC, GND, MOSI, CLK, MISO (if you want to read data from a slave), and additionally, one CS line per slave. Furhtermore, it is quite common that you may need additional control ports. This is the case for the SSD1306 and SSD1309, which offers one port for the C/D line, which signals command/data transfer mode in 4-wire SPI mode. On the other hand there is no support for reading via SPI on SSD130x - so MISO is not required.
I2C does the addressing and command/data signaling all encoded in the data, similar to the 3-wire SPI. This causes a little overhead to I2C data, which usually is neglictable. But SPI is also run on a higher frequency than I2C. For I2C there are 2.5us cycle time specified, while for SPI this is 100ns.
So for a typical 128x64 monochrom display, there is 8kiB of raw data that needs to be transferred via the bus. On I2C with a 2.5us clock cycle and ignoring the protocol overhead for now, you have 4000 clock cycles in a 10ms frame. I.e. the available bandwidth is far below what is needed for updating the whole screen in 10ms. Additionally, there is a certain protocol overhead associated, and updating can only take place on a page-by-page basis (8 pixel with a certain alignment) for the SSD130x devices. So with I2C there is no way of updating the whole screen within 10ms.
For SPI at 10MHz, there are 100k clock cycles in a 10ms time interval. So this is no problem. Even if you go down to 1MHz SPI clock frequency, 10k clock cycles remain in a 10ms time-interval. So go for SPI?
Well, with some compromises, I2C can also do it in 10ms. But that requires only updating part of the screen - this is how the 8-pixel pages of the SSD130x devices come into play. The pages are organized as 8 pixel in vertial order aligned side-by-side horizontally (see picture).
If this is taken into account, by using a font with 8 pixel height and the stop-watch display being aligned on a page sequence, the required update bandwidth to 25% of the whole screen. I.e. the update will require only updating the part of the screen which displays the updated stop-watch reading.
Like this, the I2C connection can even provide 100 frames per second update rate for the stop-watch. This is implemented for the stop-watch display of the Atrium firmware.
Enjoy it!