Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSD1322 wrong init? #264

Open
MarkoBursic opened this issue Nov 6, 2019 · 13 comments
Open

SSD1322 wrong init? #264

MarkoBursic opened this issue Nov 6, 2019 · 13 comments

Comments

@MarkoBursic
Copy link

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
Copy link
Author

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
Copy link
Owner

rm-hull commented Nov 6, 2019

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
Copy link
Author

MarkoBursic commented Nov 7, 2019 via email

@thijstriemstra
Copy link
Collaborator

I will test and give the results.

any update @MarkoBursic?

@gilphilbert
Copy link

gilphilbert commented Mar 12, 2020

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
Copy link
Owner

rm-hull commented Mar 12, 2020

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

@gilphilbert
Copy link

gilphilbert commented Mar 12, 2020

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
Copy link
Owner

rm-hull commented Mar 12, 2020

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
Copy link
Owner

rm-hull commented Mar 12, 2020

@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
Copy link

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
Copy link

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
Copy link
Owner

rm-hull commented Mar 12, 2020

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants