SSD1322 wrong init?

[MarkoBursic]

In init for ssd1322(grayscale) you have 👍

command(0xA4) // Display off (all pixels off)

I do think it should be 0xAE, like for Newhaven type display that has the same ssd1322, also the manual says: "Send command AEh for display OFF."

[MarkoBursic]

For real:
A4 - means entire display OFF
AE - means sleep mode ON

So, not sure anymore if it's better to use A4 or AE when doint initialisation.

[rm-hull]

Hi @MarkoBursic, what issue are you facing exactly? You're suggesting a solution, but I can't clearly see what the problem is. Do you have a Newhaven SSD1322 and it is not working with the luma.oled library?

[MarkoBursic]

Not yet. The *ER-OLED032-1 <https://www.ebay.com/itm/White-Serial-SPI-Graphic-3-2-OLED-Module-Display-256x64-Arduino-PIC-AVR-ARM-/291185716166?hash=item43cc056bc6>W* is on the way, it's not Newhaven, but same SSD1322. I will test and give the results. Anyway, the init sequence for nhd_ssd1322 and ssd1322 are different, the nhd_ssd1322 is more similar as in example that comes with ER-OLED032. V V sre., 6. nov. 2019 ob 22:56 je oseba Richard Hull < [email protected]> napisala:

…

Hi @MarkoBursic <https://github.com/MarkoBursic>, what issue are you facing exactly? You're suggesting a solution, but I can't clearly see what the problem is. Do you have a Newhaven SSD1322 and it is not working with the luma.oled library? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#264?email_source=notifications&email_token=AB3XWFOU24WVCLMAL33H4HLQSM4QRA5CNFSM4JJRG5R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDID6HI#issuecomment-550518557>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3XWFKTSNAV2PONRO4EVQ3QSM4QRANCNFSM4JJRG5RQ> .

[thijstriemstra]

I will test and give the results.

any update @MarkoBursic?

[gilphilbert]

I just bought the Newhaven NHD-3.12-25664 display and wired it up, which wasn't easy. You have to ground 10 pins, which is kind of mad. But I digress.

I've tried the examples, and I get nothing... the display doesn't come on.

pi@raspberrypi:~/luma.examples/examples $ ./perfloop.py --display ssd1322 --interface=spi --spi-device=0 --spi-port=0 --height 64 --width 256
Testing display rendering performance
Press Ctrl-C to abort test

Version: luma.oled 3.4.0 (luma.core 1.12.0)
Display: ssd1322
Interface: spi
Dimensions: 256 x 64
------------------------------------------------------------
#### iter =   3720: render time = 1.08 ms, frame rate = 864.88 FPS

So the controller is working fine, presumably, but since the backlight isn't being activated the screen remains dark.

Any way I can easily test a different init sequence?

Documentation is here: http://www.newhavendisplay.com/specs/NHD-3.12-25664UCB2.pdf

Thanks!

[rm-hull]

@gilphilbert presumably you should be using ssd1322_nhd driver if you have the newhaven device?

[gilphilbert]

Ah, yes, I realized after I wrote the above that there's a separate driver for Newhaven, but the backlight still didn't come on when I used ssd1322_nhd:

pi@raspberrypi:~/luma.examples/examples $ ./perfloop.py --display ssd1322_nhd --interface=spi --spi-device=0 --spi-port=0 --height 64 --width 256
Testing display rendering performance
Press Ctrl-C to abort test

Version: luma.oled 3.4.0 (luma.core 1.12.0)
Display: ssd1322_nhd
Interface: spi
Dimensions: 256 x 64
------------------------------------------------------------
#### iter =    713: render time = 37.93 ms, frame rate = 26.30 FPS

Interestingly, performance drops from ~800fps for the ssd1322 vs ~25fps for the ssd1322_nhd on the perf test.

[rm-hull]

OLEDs dont have a backlight - they are light emitting diodes (see https://en.wikipedia.org/wiki/OLED).
I don't know much about the newhaven driver - it was submitted by a contributor and i have not got a device to test with.

What could be happening is that the ssd1322 may have the diff_to_previous framebuffer as the default which gives an artificially high FPS on the perf test whereas the newhaven one might not.

26 FPS is pretty good going in my opinion, and about what i'd expect.

[rm-hull]

@gilphilbert Try adding --framebuffer full_frame to the args when you run the perfloop program with the ssd1322 driver and let me know what FPS you get.

[gilphilbert]

Thanks!

Oh yes, I did know that but I've spent too much time with LCDs just recently!

As requested:

pi@raspberrypi:~/luma.examples/examples $ ./perfloop.py --display ssd1322 --interface=spi --spi-device=0 --spi-port=0 --height 64 --width 256 --framebuffer=full_frame
Testing display rendering performance
Press Ctrl-C to abort test

Version: luma.oled 3.4.0 (luma.core 1.12.0)
Display: ssd1322
Interface: spi
Dimensions: 256 x 64
------------------------------------------------------------
#### iter =    124: render time = 67.95 ms, frame rate = 14.70 FPS

Any ideas on how to get started troubleshooting this? I'd like to get this working but I have no idea where to start. I know enough about these devices to be dangerous but not much more...

From the documentation it looks like the initialization sequence may be different as the commands for the screen are different (or maybe I'm not looking at this right...):

0xA4 = Entire display OFF
0xA5 = Entire display ON, all pixels Grayscale level 15
0xA6 = Normal display
0xA7 = Inverse display

Thanks!

[gilphilbert]

Oh, hang on... it's working!

Using the ssd1322 driver with --framebuffer full_frame brought it to life. Strangely, it now also works with diff_to_previous which it didn't before. So I'm not quite sure what triggered it, but happy it's now working!

[rm-hull]

Hmmm.. sounds more like dodgy wiring ! ;-p

This was the PR where the newhaven driver was merged: #245 - you could reach out to @doug-burrell for assistance maybe?

[gilphilbert]

The display was being very intermittent, sometimes it would work other times not. I was about to throw it away and buy another when it occurred to me that the power draw on the 3v3 line might be too much, especially since I had it paired with an I2S DAC that's powered directly from the 3v3 rail. So I removed the DAC... and now it works perfectly, every time. I've introduced a 3v3 regulator for the display so it's powered from the 5v line and now the two work together.

Long story short... I can confirm that the init sequence in the ssd1322 driver works just fine on the Newhaven NHD-3.12-25664 - the ssd1322_nhd drive is not required. I suspect that's just for another display they made.