ER-OLEDM032-1, SSD1322 on Arduino Nano: SPI works, parallel fails....

Hello everybody,

I am a newbie and trying to make an ER-OLEDM032-1 work with Arduino Nano I run into the problem:
It works in 4-Wire SW-SPI mode (jumper settings on OLED R19, R21 short; R18, R20 open), but the screen updating is too sluggish for my application (feels like 0.2-0.3 sec, you see the picture fill up to down;
using buffer size 2 rather than 1 does not feel to bring much;
unfortunately the Nano will be busy as SPI slave in my application, so attaching display to HW SPI would be a major effort for me).
I wanted to try parallel mode (jumpers resoldered to R18, R21 short; R19, R20 open), but the screen just remains black.
What I tried: Not having level shifter by hand, I fed Arduino Nano and the display from 3.3 Volts altogether (external power supply connected to +5V pin). Also in this setup SPI works, parallel - not.
The U8G2 16 bit mode is set.

My wiring:

oled oled Nano
signal pin pin
d0 4 D4
d1 5 D5
d2 6 D6
d3 7 D7
d4 8 D10
d5 9 D11
d6 10 D12
d7 11 D2
/RD (E) 12 D8
/WR 13 GND
DC 14 D9
/Reset 15 A4
/CS 16 D3

Code that works (R19, R21 short; R18, R20 open):
(I know, I should tie unused display pins 7-13 to GND in SPI mode, but it works also with floating pins - finally this is not the issue here).

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

//U8G2_SSD1322_NHD_256X64_1_8080 u8g2(U8G2_R0,  4,  5,  6,  7, 10, 11, 12, 2, /*enable*/ 8, /*cs*/  3, /*dc*/ 9,/*rst*/ A4);
  //U8G2_SSD1322_NHD_256X64_1_8080(rotation,   d0, d1, d2, d3, d4, d5, d6, d7,       enable,        cs,       dc     [, reset])

  U8G2_SSD1322_NHD_256X64_1_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 4, /* data=*/ 5, /* cs=*/  3, /* dc=*/ 9, /* reset=*/ A4);  
//U8G2_SSD1322_NHD_256X64_1_4W_SW_SPI u8g2(U8G2_R0,     clock     ,    data=   11,   cs=     ,    dc=    ,     reset=    );  

void setup(void) {
   u8g2.begin();  
}

void loop(void) {
  u8g2.firstPage();
  do {
    u8g2.setFont(u8g2_font_fub42_tr);
    u8g2.drawStr(0,50,"HELLO!");
  } while ( u8g2.nextPage() );
  //delay(1000);
}

Code that does not work (R18, R21 short; R19, R20 open):

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

  U8G2_SSD1322_NHD_256X64_1_8080 u8g2(U8G2_R0,  4,  5,  6,  7, 10, 11, 12, 2, /*enable*/ 8, /*cs*/  3, /*dc*/ 9,/*rst*/ A4);
  //U8G2_SSD1322_NHD_256X64_2_8080(rotation,   d0, d1, d2, d3, d4, d5, d6, d7,       enable,        cs,       dc     [, reset])

// U8G2_SSD1322_NHD_256X64_1_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 4, /* data=*/ 5, /* cs=*/  3, /* dc=*/ 9, /* reset=*/ A4);  
//U8G2_SSD1322_NHD_256X64_1_4W_SW_SPI u8g2(U8G2_R0,     clock     ,    data=   11,   cs=     ,    dc=    ,     reset=    );  

void setup(void) {
   u8g2.begin();  
}

void loop(void) {
  u8g2.firstPage();
  do {
    u8g2.setFont(u8g2_font_fub42_tr);
    u8g2.drawStr(0,50,"HELLO!");
  } while ( u8g2.nextPage() );
  //delay(1000);
}

I don't understand it, and I've got a couple of questions...

  • *if * parallel mode (8080) worked, would it improve the display refresh speed significantly?
  • is there anything I am doing evidently wrong, or is it rather an OLED hardware issue? (2 Nanos tried)
  • will the display refresh speed improve significantly if I use a Nano Every in SW-SPI mode (full frame buffer+ higher controller freqency)?
  • if Every is not likely to be much quicker - what should I take then?
  • is there a mode for SSD1322 to accommodate the entire display picture in display's RAM (if any) and then to bring it to screen "at once", and if yes - is it supported by u8g2?
    Thank you very much in advance, I really appreciate any advice!

First off. SPI uses less pins than Parallel.
Second. HW_SPI is faster than SW_SPI.

The 256x64 display needs 2048 bytes for a "Full" Buffer. And that is for Monochrome. If you wanted to use the 16 grayscale levels it would need 8192 bytes (and U8g2 only supports Monochrome anyway).

You have a Nano which only has 2048 bytes of SRAM.
So you can't use any Full Buffer library.

I suggest that you use U8g2 with a HW_SPI_ 1 or 2 buffer constructor.

As a general rule, you update small areas of the screen. And only when they change.

I don't have a SSD1322. But I would be pretty confident that U8g2 will work fast enough.

If you are unsure what to do, attach your complete project. Readers might offer some advice.

At a guess, I would expect Parallel with data bus on random pins to be slower than HW_SPI and probably a bit slower than SW_SPI.
All the same, I am sure that Parallel will work 100%. But let's face it. You have to specify the constructor and wire it correctly.
Parallel with a fixed data bus would be fast.

David.

Thank you David,
the entire project is replacement of an LCD display on an HP measurement instrument with an OLED, inspired by this thread below, but for now just bringing a string to the display seems to be a useful test model:
Projects, Designs, and Technical Stuff - Page 1)/

I could though try to read the HP instrument's data wirh a SW-SPI and leave the HW-SPI for OLED, I am also unsure, if SW-SPI will be fast enough for reading the instrument's data.
Besides, unfortunately I have already ordered the PCB. Thus a handier option for me now would be using a more powerful MCU (thus the question about Every; also Every would be able to handle an entire frame) or adding flying wires to make a parallel connection of the display.
With a "fixed data bus" - do you mean assigning the data lines in the proper order to a single physical 8-bit MCU port?
I'll try this, but I am still confused, why it just does not work at all with random pin assignment?

First off. Please post a link to the particular part of the EEVBLOG thread that interests you.
I don't want to read 4 pages worth of messages.

It looks fairly trivial. Replace a 12 16-segment display with a 256x64 OLED. Each digit/symbol can be 20x30 and you get two rows of 12 digits.
You could even have a couple of rows of small regular text with one row of BIG digits.

There is no way that speed is important. A human actually wants to view a steady display.

David.

Thank you David,
yes, the task is principally trivial (at least after they reverse engineered the encoding). This is why I say, displaying a "HELLO" string is a reasonable model for me. And yes, I want to display a line of large figures/letters and a line of small ones (what they call annunciators there).
At the same time I can't influence the data stream coming from the instrument, and that's why I am not sure if SW-SPI would suite there (frankly, I neither tried nor estimated it yet).
And yes, a human prefers to see a steady display. However the instrument runs typically about 4 measurements per second or more and wants to display them. Decreasing the display update rate would be misleading for the operator, occasionally providing a wrong feeling about the stability of the value being acquired.
And now, once the displayed value needs to be updated say 4 times a second, I agree, toggling figures don't look exciting. But it looks much worse, if at this refresh rate you see, how the figures are being drawn. It is preferable, if the figures are "flipped" instantly. A delay is not critical, but the duration of the visible graphical update on the display - is. That's why my question about possible RAM in the SSD1322. I can spend time loading the display, but I want the picture change to be "instant".
I hope I've explained my motivation and boundary conditions. I will also report my findings, if there will be anything interesting.
But now I still don't understand why the parallel mode didn't work for me yet (i.e. if there is any explanation possible except for a HW defect), and what options are most reasonable to practically achieve what I want.