I recently received a 2.7 inch 128x64 OLED from new haven, it uses the SSD1325 controller and is supported by the u8glib library.
This is a 3.3v display, so most of my arduinos wouldn't work with it without the help of a level shifter. I have a DUE on hand that has been woefully neglected for some moths, so i thought it would be a great opportunity to use it.
Long story short, getting the display up and running was quite painless, the u8glib defines SPI pins that are hardware on most arduino boards, however the DUE has them on a separate dedicated header. This turned out not to be an issue (or so i thought) as i just used the default pins and it worked, ran a few demo sketches and thought everything was fine, until.....
I tried to write code to see how fast the OLED would update, basically i did an analog read and print routine, thats when i noticed how painfully slow the update was, to the point that digits got garbled and looked terrible.
How could this be? the DUE is a fast and powerful beast, why does it seem to choke on a lowly 128x64 OLED?
I am pretty sure it has something to do with not using the hardware SPI, the library is obviously implementing a software spi and i am sure that slows it down a bunch, but is that the only issue?
Does anyone know a way to implement the hardware pins with the u8glib library?
does anyone know if the SPI hardware pins can be declared in the IDE ?( i found no reference to what pin numbers they might be)
is there a better library out there? or possibly one that could be substituted?
has anyone ever tried using one of these displays (or a similar type) in parallel mode (6800 or 8080 interface)?
I would love to use this display as it is well suited for my application, but at its current performance level its pretty useless.