Assistance on getting an SH1122 256 x 64 7 pin OLED working

Hi all, I am trying to get one of these 2.08 inch OLED display LCD screen 256×64 oled with grayscale adjustment SPI | eBay 2.08in OLED's to work with an AT328 Nano board. At the moment I am stuck where I cannot get anything to display, despite a very basic code that does work for other OLEDs

#include <SPI.h>

#include <Arduino.h>
#include <U8g2lib.h>
#include <Wire.h>

#define PIN_MOSI 18
#define PIN_CLK 19
#define PIN_DC 17
#define PIN_CS 16
#define PIN_RST 13

//U8G2_SH1122_256X64_2_HW_I2C u8g2(U8G2_R3, PIN_CS, PIN_DC, PIN_RST);  // All Boards without Reset of the Display R3 refers to 270 deg text rotation

//U8G2_SH1106_128X64_NONAME_F_4W_HW_SPI u8g2(U8G2_R0,/* cs=*/ 16, /* dc=*/ 17, /* reset=*/ 13);

U8G2_SH1122_256X64_1_4W_SW_SPI u8g2(U8G2_R3, 19, 18, 16, 17, 13);

void setup(void) {
  u8g2.begin();
  u8g2.clearBuffer();
  u8g2.setFont(u8g2_font_ncenB08_tr);
  u8g2.drawStr(20, 50, "hello");  // 0 left, 0 top bottom appx 100
  u8g2.sendBuffer();
  delay(1000);
}

void loop() {
}

As you can see I have tried a few variations of the library, and have to opt for 1 or 2 in place of the F in order to make the sketch small enough to fit onto a Nano. However whichever I try it is not working for me.

I do see that SH1122 devices seem to be relatively thin on the ground, I searched for example sketches to try and give myself a lead but only one (non working) example showed up on Google

Can anyone see if there is something obvious I have missed?

Thanks in advance

Les

1 Like

Have you tried one of the example sketches that are installed with U8G2 library?

I think perhaps your code is correct if you were using a full size buffer (with "F" in the constructor). But as you already know, atmega328 does not have enough RAM memory for that. The code for updating the display with a smaller buffer looks a little different, if I remember.

Hi, thanks for the reply

Yes, setting the frame buffer from F to 2 does work in reducing the size on other sketches I use on Nanos, but I'm not certain if that affects this particular OLED differently

As for the examples, yes I tried a simple one - it's just a blank screen. I got the screen to 'work' using a non u8g2 sketch that I uploaded by mistake, it was an i2C 4 pin sketch that (in theory at least) should not have worked at all. It showed corrupted garbage on the OLED but at least that showed me the OLED wasn't dead.

Frustratingly I can't remember which sketch it was that did that, it would be good to at least have that as a reference point. I will go through and try some to see if I can replicate it

Les

At this point I don't have any reason to think that this OLED would work any differently to smaller ones when it comes to using smaller buffers.

If I remember correctly, when using a smaller buffer, your code needs to have a while-loop that allows the display to be updated one area at a time. Have a look through the U8g2 example sketches to find an example of that.

Here's how it needs to look with a smaller buffer:

    u8g2.firstPage();
    do
    {
      //Draw screen here
    } while(u8g2.nextPage());

I've tried to update your sketch correspondingly

#include <SPI.h>

#include <Arduino.h>
#include <U8g2lib.h>
#include <Wire.h>

#define PIN_MOSI 18
#define PIN_CLK 19
#define PIN_DC 17
#define PIN_CS 16
#define PIN_RST 13

//U8G2_SH1122_256X64_2_HW_I2C u8g2(U8G2_R3, PIN_CS, PIN_DC, PIN_RST);  // All Boards without Reset of the Display R3 refers to 270 deg text rotation

//U8G2_SH1106_128X64_NONAME_F_4W_HW_SPI u8g2(U8G2_R0,/* cs=*/ 16, /* dc=*/ 17, /* reset=*/ 13);

U8G2_SH1122_256X64_1_4W_SW_SPI u8g2(U8G2_R3, PIN_CLK, PIN_MOSI, PIN_CS, PIN_DC, PIN_RST);

void setup(void) {
  u8g2.begin();
  u8g2.firstPage();
  do {
    u8g2.clearBuffer();
    u8g2.setFont(u8g2_font_ncenB08_tr);
    u8g2.drawStr(20, 50, "hello");  // 0 left, 0 top bottom appx 100
  } while(u8g2.nextPage());
  delay(1000);
}

void loop() {
}

Naturally this slows down the speed at which the screen is updated, so to mitigate against that, I would recommend you consider switching to use hardware SPI.

Thanks for this, but unfortunately it still isn't working, and I mean not at all - no flicker on the display, or scrambled pixels, just a blank screen

So let me go back to basics, at least how I understand this OLED

Pin connections

Nano OLED
GND GND
5V VCC
A5 (19) SCL
A4 (18) SDA
13 RST
A3 (17) DC
A2 (16) CS

I am assuming that all 7 pins have to be connected, however I also assume that the input voltage of 5v is correct

I am using pins A5 and A4 as they are the normal pins used for SDA and SCL in I2C devices, and the rest of the pins were selected for convenience of connection as they are on the same side of the Nano, meaning I can connect using one 12 way Dupont connector. If I am using SPI vs I2C does that mean that pins A4 and A5 cannot be used?

I've included the SPI and U8G2 libraries, plus the standard Wire and Arduino ones. I have also called out the definitions of the pins in the sketch which I believe overrides the library defaults,

Beyond that I have only instructed a simple command to write the word 'hello'

That it is totally blank baffles me, but I must be missing some really obvious point.

With respect to the display refresh rate, that is not an issue - it would be used for a (relatively) static parameter display that would represent a radio frequency preset

EDIT by the way, I also defined 16 bit in the in "u8g2.h" file

Cheers

Les

It seems that this particular OLED is fussy as to what pins are used for a Nano. I changed the CS / DC / SDA / SLC pins and away it went

here's the code

#include <SPI.h>

#include <Arduino.h>
#include <U8g2lib.h>
#include <Wire.h>

/*#define PIN_MOSI 18
#define PIN_CLK 19
#define PIN_DC 17
#define PIN_CS 16
#define PIN_RST 13*/



U8G2_SH1122_256X64_2_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 12, /* data=*/ 11, /* cs=*/ 9, /* dc=*/ 10, /* reset=*/ 15);        // Enable U8G2_16BIT in u8g2.h



void setup(void) {
  u8g2.begin();
  u8g2.firstPage();
  do {
    u8g2.clearBuffer();
    u8g2.setFont(u8g2_font_ncenB08_tr);
    u8g2.drawStr(180, 20, "hello");  // 0 left, 0 top bottom appx 100
  } while(u8g2.nextPage());
  delay(1000);
}

void loop() {
}


So, lesson learned that you have to try different pins

Thanks for the input

Les

I don't get that. The pins you were using should have been fine. The display doesn't know what pins it is connected to.

Is it possible some of your Nano pins were damaged?

You didn't have other i2c devices connected to A4/5 at the same time as the display?

Glad it's working for you now.

It's just that one device connected, so not sure if it's the Nano or the OLED. I'll grab another couple of Nanos and see if it behaves the same, if nothing else it may help someone in the future

Les

Hi there again

I tested using another Nano, and it looks like the original Nano had a duff pin, either the A4 or A5 pins. On a different AT328 it works.

However I do still have a puzzling problem. Using the sketch above, I am able to place and display the text anywhere on the OLED display, yet when I use the following sketch (which pulls a data string from a flight sim game and displays it) if I set the setcursor vertical value to anything higher than 24, nothing is displayed. If I set it lower, anything below 24 is truncated

#define DCSBIOS_IRQ_SERIAL

//#include <AccelStepper.h>
#include "DcsBios.h"
#include <U8g2lib.h>
#include <Wire.h>

//U8G2_SH1122_256X64_2_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 12, /* data=*/ 11, /* cs=*/ 9, /* dc=*/ 10, /* reset=*/ 15);        // Enable U8G2_16BIT in u8g2.h

void onUhfFrequencyChange(char* newValue) {

  u8g2.clearBuffer();
  u8g2.setFont(u8g2_font_inb24_mr );
  u8g2.setCursor(80, 14);
  u8g2.print(newValue);
  u8g2.sendBuffer();
}
DcsBios::StringBuffer<7> uhfFrequencyBuffer(0x1180, onUhfFrequencyChange);

void setup() {
  u8g2.begin();

  DcsBios::setup();
}
// fonts https://github.com/olikraus/u8g2/wiki/fntlistall#4-pixel-height

void loop()
{

  DcsBios::loop();
}

Both use the same constructor

U8G2_SH1122_256X64_2_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 12, /* data=*/ 11, /* cs=*/ 9, /* dc=*/ 10, /* reset=*/ 15);

One of the guys on the flight sim forums thinks this may be due to only using half the buffer so only half the screen would be rendered, but that seems contradictory as the first sketch does not behave the same way. I thought the buffer was the number of pre-rendered frames.

Can you give us your opinion?

Cheers

Les

I will have to apologise here for not being very fast out of the blocks - the answer had been given earlier in the thread with the suggestion of the while-loop, and it didn't click until I had a while to think about it without distractions - having two simultaneous punctures and waiting 2 1/2 hours in the middle of nowhere for a tow truck does that.

I spliced in the loop and now can successfully place the text output from the game on the entire display surface.

If you would be so kind as to explain why/how that changes the way the sketch works I would be interested

Cheers and thanks once again for the assistance

Les

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.