Pushing the SSD1306

[JonW]

I have been writing some fast, compact text libraries for the SSD1306 using page writes and I2C and was disappointed with the speed, so I decided to pimp it a little. Testing with a PIC27J53 development board running at 48MHz, utilising hardware SPI at 12.5 Mbits/s, achieved exceptional performance metrics for such a cheap display. Even with a prototype setup using flying leads, the display handled entire page operations remarkably well: a complete screen (page-driven clear) executes in under 1.8ms, while a complete arbitrary page write, including flash transfer to RAM, completes in under 2.6ms. This translates to 380 gdram updates/s - , limited to approx 350 FPS by the device's default frame rate ( this can go faster but increases current), but still significantly higher than commonly reported 30-130 FPS figures online for SPI transfers at similar speeds.  The goal was to update the gdram as fast as possible to save processor time for USB operations.
The implementation's efficiency stems from optimised page-wise operations, where control bytes only need to be set once per page, significantly reducing overhead. The additional step of reading Flash pages into a 128-byte RAM array before SPI transmission adds processing overhead but provides flexibility for future implementations, such as direct USB-to-display transfers or external memory integration.
These results suggest that the SSD1306's capabilities may be even greater when implemented on a proper PCB with optimised traces, as the current performance was achieved with a relatively basic prototype setup.

Some data

[trastikata]

The biggest advantage of Hardware SPI is that you can load the SPI output register and instead of waiting for that serial transfer to finish, you prepare the next byte to send, thus by "stealing" the SPI TX clocks.