Monochrome 128*64 OLED screen - SSD1306 driver questions

[scout119]

Thank you for the link. I am very interested in improving the performance, since it is a little bit slow right now.

[fabienroyer]

I have verified that SPI on the netduino sends the bits in MSB order, so that's not the issue.
I suspect that the alpha firmware (4.1.1.a5) that I'm using on the netduino is the root cause at this point.

Cheers,
-Fabien.

[scout119]

Yeah, I have come to the same conclusion. I have seen some other drivers on netduino that work through SPI with devices that expect MSB first.

[kscharf]

This display looks perfect for a project I'm working on. I'll probably try getting the I2C (TWI) interface working on it as I'm already using the SPI interface for other things, but I might be able to multi-drop it.

I think I can make this work with a lot less than 1k of ram by only updating a part of the screen at a time. Since I would be using this for a character display, this ought to work, I only need to keep one text line worth in memory at a time.
I'm currently using an atmega16, but have a mega32 in the wings if I run out of space. (Might end up with an atmega1284 though).

[NickGammon]

Just wanted you to know that I successfully got the OLED screen to work with hardware SPI. The bit-banging you currently use clocks bytes out a rate of one per 150 microseconds, but the hardware will do it in 3 microseconds. So that is 50 times faster! (This is on a Uno).

Changes needed were minimal.

In file SSD1306.cpp:

Add near the start:

Code: Select all

#include <SPI.h>

Near the end, delete:

Code: Select all

inline void SSD1306::spiwrite(uint8_t c) {
 shiftOut(sid, sclk, MSBFIRST, c);

}

And change ssd1306_command and ssd1306_data to read:

Code: Select all

void SSD1306::ssd1306_command(uint8_t c) { 
 digitalWrite(cs, HIGH);
 digitalWrite(dc, LOW);
 digitalWrite (cs, LOW);
 SPI.transfer (c);     // clock out one byte
 digitalWrite(cs, HIGH);
}

void SSD1306::ssd1306_data(uint8_t c) {
 digitalWrite(cs, HIGH);
 digitalWrite(dc, HIGH);
 digitalWrite (cs, LOW);
 SPI.transfer (c);    // clock out one byte
 digitalWrite(cs, HIGH);
}
 

In the example sketch, change the pins to be:

Code: Select all

#define OLED_DC 8
#define OLED_CS 10     // SPI slave-select
#define OLED_CLK 13    // hardware SPI clock
#define OLED_MOSI 11   // hardware SPI MOSI
#define OLED_RESET 7

And add:

Code: Select all

#include <SPI.h>

Then, in setup, after:

Code: Select all

Serial.begin(9600);

Add:

Code: Select all

SPI.begin ();

The wiring from the CD4050 chip to the Arduino is now this:

Code: Select all

Signal   Chip out --> Arduino pin

Reset      3    -->      7  (was 13)
CS         5    -->     10  (was 12)
D/C        9    -->      8  (was 11)
CLK       11    -->     13  (was 10)
DAT/MOSI  14    -->     11  (was 9)

I don't know why you would want "to use other pins". The hardware pins are there, why not use them? You can always run other SPI devices by simply sharing the 3 main SPI pins (CLK, MISO, MOSI) and dedicating a different SS pin for each different device.

[adafruit]

because
1) the screen is very small and few people need fast updates
2) sometimes the pins are used for PWM output
3) many beginners do not understand pin muxing and its not a good idea for them to try it without understanding it
4) SPI pins are different on UNO/Mega which adds to more confusion

[NickGammon]

Thank you for the link. I am very interested in improving the performance, since it is a little bit slow right now.

In the context of the above message, I thought you might be interested in code that sent the data 50 times as fast.

[adafruit]

Thank you for the link. I am very interested in improving the performance, since it is a little bit slow right now.

In the context of the above message, I thought you might be interested in code that sent the data 50 times as fast.

He is not using an Arduino, he is using an interpreted .NET platform

[evanlaske]

I am creating an .NET Micro object oriented library for multiple LCDs, and one of them is this SSD1306 based OLED display. I have the 4 wire SPI interface working with the hardware SPI on the netduino and was wondering if you solved the problem you were having with this.

Also, I heard someone had gotten it to work with I2C and I was wondering if anyone figured out any odd eccentricities to that. I was using the I2CBus class from the EEPROM development I found here: http://forums.netduino.com/index.php?/t ... bus-class/ and haven't gotten it to initialize correctly yet.

[mirage00]

Just wanted you to know that I successfully got the OLED screen to work with hardware SPI. The bit-banging you currently use clocks bytes out a rate of one per 150 microseconds, but the hardware will do it in 3 microseconds. So that is 50 times faster! (This is on a Uno).

Changes needed were minimal.

In file SSD1306.cpp:

Add near the start:

Code: Select all

#include <SPI.h>

Near the end, delete:

Code: Select all

inline void SSD1306::spiwrite(uint8_t c) {
 shiftOut(sid, sclk, MSBFIRST, c);

}

And change ssd1306_command and ssd1306_data to read:

Code: Select all

void SSD1306::ssd1306_command(uint8_t c) { 
 digitalWrite(cs, HIGH);
 digitalWrite(dc, LOW);
 digitalWrite (cs, LOW);
 SPI.transfer (c);     // clock out one byte
 digitalWrite(cs, HIGH);
}

void SSD1306::ssd1306_data(uint8_t c) {
 digitalWrite(cs, HIGH);
 digitalWrite(dc, HIGH);
 digitalWrite (cs, LOW);
 SPI.transfer (c);    // clock out one byte
 digitalWrite(cs, HIGH);
}
 

In the example sketch, change the pins to be:

Code: Select all

#define OLED_DC 8
#define OLED_CS 10     // SPI slave-select
#define OLED_CLK 13    // hardware SPI clock
#define OLED_MOSI 11   // hardware SPI MOSI
#define OLED_RESET 7

And add:

Code: Select all

#include <SPI.h>

Then, in setup, after:

Code: Select all

Serial.begin(9600);

Add:

Code: Select all

SPI.begin ();

The wiring from the CD4050 chip to the Arduino is now this:

Code: Select all

Signal   Chip out --> Arduino pin

Reset      3    -->      7  (was 13)
CS         5    -->     10  (was 12)
D/C        9    -->      8  (was 11)
CLK       11    -->     13  (was 10)
DAT/MOSI  14    -->     11  (was 9)

I don't know why you would want "to use other pins". The hardware pins are there, why not use them? You can always run other SPI devices by simply sharing the 3 main SPI pins (CLK, MISO, MOSI) and dedicating a different SS pin for each different device.

Thanks Nick, This modification worked perfectly and really speeds the display up! Now I need to get this thing to not use a buffer! 1k on a 328 chip is way to much to spare for my project. Any ideas?

[tallgirl]

Greets,

I had a problem with the LiquidCrystal library running entirely too slow. One of the posters who'd made a comment up above, Nick, pointed me back to this thread and the changes he made.

Not to be completely blunt, but the attitude that the change wasn't needed is wrong. I wasted about 30 hours debugging everything else, because I mistakenly assumed the SPI code was more efficient than it was.

The actual change to use the hardware SPI pins is very simple -- test to see if the clock and data pins are the same as the hardware ones, and if so, use SPI. The speedup was huge. Big enough that it makes the difference between having a product that my customers will buy, and one that I wouldn't be able to sell.

I'd hope that you will recognize that "It's good enough" can make the difference between products been saleable, and not so saleable.

[adafruit]

Greets,

I had a problem with the LiquidCrystal library running entirely too slow. One of the posters who'd made a comment up above, Nick, pointed me back to this thread and the changes he made.

Not to be completely blunt, but the attitude that the change wasn't needed is wrong. I wasted about 30 hours debugging everything else, because I mistakenly assumed the SPI code was more efficient than it was.

The actual change to use the hardware SPI pins is very simple -- test to see if the clock and data pins are the same as the hardware ones, and if so, use SPI. The speedup was huge. Big enough that it makes the difference between having a product that my customers will buy, and one that I wouldn't be able to sell.

I'd hope that you will recognize that "It's good enough" can make the difference between products been saleable, and not so saleable.

hi there tallgirl, you're posting on a thread for the monochrome OLED but you're referring to LiquidCrystal library which is for LCDs not OLEDs. Which product are you referring to?

[amateurasu]

Just got one of these yesterday, got it up and running smoothly. One question though, in the comments in the example program, it says that the .clear() function clears both the screen and the buffer. But as far as I can tell, it only clears the buffer, and you must then run .display() to write the empty buffer to the screen and thus clear the screen. Just wondering if I'm doing something wrong, or if the comment is worded wrong.

I was also going to ask about the apparent slowness of the display, but I see in this thread that switching to hardware SPI should help a great deal, so I'll try that. Thanks, NickGammon!

On an unrelated note, the screen and output buffer chip fit quite nicely on one of those cute little 17 row breadboards. At first I thought I would have to step up to a half breadboard, since I need 8 rows for the buffer chip and 10 for the display. But if you put the buffer in with pin 1 on the top row, and put the OLED in on the left side of the board, all the way down, so the screen pretty much sits right over the lower half of the board, then the only pins that overlap are the GND pin on the OLED board, and pin 8 of the buffer chip, which happily enough is also GND. Makes for a nice little compact platform, with almost no wasted space.

[adafruit]

nice work, post up a photo!

[amateurasu]

Click the images for the full size versions.