This OLED display
http://www.adafruit.com/products/326
There have been several threads in the past about this Adafruit OLED monochrome display, driven by the SSD1306 driver. The conclusion was that I2C worked, but was slow, and SPI worked (with any random pin assignment) because it was bit-banged software SPI so was also slow. Lastly, Adafruit rejected a patch by Patrick Gannon to use hardware SPI on the grounds that no-one needs fast screen updates
http://forum.pjrc.com/threads/24562-Teensy3-and-SSD1306-SPI-help!?highlight=ssd1306
http://forum.pjrc.com/threads/24642...2-OLED-and-Pin-Designations?highlight=ssd1306
http://forums.adafruit.com/viewtopic.php?f=25&t=46997&p=238726#p238726
I had also complained in the past about the dumb (their words, in their comment) implementation of supposedly fast primitives like drawFastVLine and drawFastHLine in Adafruit_GFX library, which use the general Bresenham algorithm despite the fact that the slope is always 0 (or 90).
So, onto the good news. Adafruit have continued development on this library and the latest GitHub version has some good improvements
- there is now a true hardware constructor, you just pass the pins for CS and two other pins (Reset and DC) used to control the display. Whatever the Teensy uses for DOUT and SCK are used, without being passed to the constructor
- the SSD1306 library redefines drawFastVLine and drawFastHLine to actually be fast (draw bits directly in the framebuffer, in a loop, rather than using a generalized line drawing algorithm and calling drawPixel at every step. This also speeds up filled rectangles).
Its not all roses, the library still makes you include Wire.h even if you have the SPI version of the board (because the library includes I2C, software SPI, and hardware SPI) and it still checks which of those three options you are using on every function call. Still, it is an improvement.
I tested the new version of the library on Teensy 2.0 with hardware SPI and +5V (worked fine) and again with Teensy 3.0 with hardware SPI and +3V3 (with default SPI pins, also worked fine, and was noticeably faster). I didn't try it with the Teensy 3.x alternate SPI pins.
It would be worthwhile including the new version of the library, from GitHub, in Teensyduino 1.20 and noting on the Teensyduino libraries page that this version works on Teensy 3.x.
https://github.com/adafruit/Adafruit_SSD1306
http://www.adafruit.com/products/326
There have been several threads in the past about this Adafruit OLED monochrome display, driven by the SSD1306 driver. The conclusion was that I2C worked, but was slow, and SPI worked (with any random pin assignment) because it was bit-banged software SPI so was also slow. Lastly, Adafruit rejected a patch by Patrick Gannon to use hardware SPI on the grounds that no-one needs fast screen updates
http://forum.pjrc.com/threads/24562-Teensy3-and-SSD1306-SPI-help!?highlight=ssd1306
http://forum.pjrc.com/threads/24642...2-OLED-and-Pin-Designations?highlight=ssd1306
http://forums.adafruit.com/viewtopic.php?f=25&t=46997&p=238726#p238726
I had also complained in the past about the dumb (their words, in their comment) implementation of supposedly fast primitives like drawFastVLine and drawFastHLine in Adafruit_GFX library, which use the general Bresenham algorithm despite the fact that the slope is always 0 (or 90).
So, onto the good news. Adafruit have continued development on this library and the latest GitHub version has some good improvements
- there is now a true hardware constructor, you just pass the pins for CS and two other pins (Reset and DC) used to control the display. Whatever the Teensy uses for DOUT and SCK are used, without being passed to the constructor
- the SSD1306 library redefines drawFastVLine and drawFastHLine to actually be fast (draw bits directly in the framebuffer, in a loop, rather than using a generalized line drawing algorithm and calling drawPixel at every step. This also speeds up filled rectangles).
Its not all roses, the library still makes you include Wire.h even if you have the SPI version of the board (because the library includes I2C, software SPI, and hardware SPI) and it still checks which of those three options you are using on every function call. Still, it is an improvement.
I tested the new version of the library on Teensy 2.0 with hardware SPI and +5V (worked fine) and again with Teensy 3.0 with hardware SPI and +3V3 (with default SPI pins, also worked fine, and was noticeably faster). I didn't try it with the Teensy 3.x alternate SPI pins.
It would be worthwhile including the new version of the library, from GitHub, in Teensyduino 1.20 and noting on the Teensyduino libraries page that this version works on Teensy 3.x.
https://github.com/adafruit/Adafruit_SSD1306
Last edited: