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?
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.
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
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.
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.
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
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
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
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.
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