Pull request SSD1362 / SH1122

[olikraus]

#1320

[olikraus]

Code does not compile at the moment
Code has extended args for the INIT message and behaves differently for u8g2 and u8x8.
SSD1362 and SH1122 seem to be similar but SSD1362 is more powerful (window assignment). Maybe u8x8 could be implemented with SSD1362. Not sure how the PR has implemented u8x8 with SH1122.

[theeprawn]

Ok, left messages in closed pull.
The windowing feature in SSD1362, not sure if helpful, I wasnt sure RAM could be x,y addressed because way window is suppose to auto increment, seems to work fine, just made sure ends are maxed. The SSD1362 like SH1122 cant do vertical stack pixel bytes in a sensible way because they are two pixel per byte(4bit grey)
Display wise the SSD1362 is much better, with custom grey lookup table and lower luminance level are dark, on SH1122 lowest contrast and lowest grey level is still pretty bright. Also have problem with SH1122 display crashing if voltage drops, only way to restore was reset. So using SSD1362 for production.

[olikraus]

There is some more activity related to the SSD1362: #2051

[theeprawn]

Happy New Year Olikraus.
I try your code out soon, I have working code on another laptop.

[olikraus]

Happy New Year!

No hurry. I still wait for the displays.

[theeprawn]

No worries, dont mind helping. Hopefully it helps both of us, for me the more ppl that use the display the less chance it becomes obselete and hopefully becomes a little cheaper (cost £10/unit last batch I ordered in 2022).
I had quick look at driver code last night, check line 181, shouldn't that be a +3 (moves 4 bytes=8pixels) for window (I see you using the displays window feature for tiles and translating/rotating tile data block).
Some of setup/init code commands are different to SSD1362, like contrast using 0xC1 instead of 0x81.
The display ribbon is exactly same as one I use(tracks and writing) as the one in the picture, but I made my own interface module, uses 12v for display and 3v3 SPI 3w logic all direct to display with five caps & a resistor added for display.
I compiled u8g2 graphics example code this morning, it ran but contrast was so low could see display well enough even in the dark. I try later, I'll add Raystar display(they make the barebone display), so can test and adds extra display choice.
btw. hope you get your display soon, they nice displays. I been tempted to add a greyscale backgorund template and use u8g2 to update with info. But still working on functionality & issues/bugs of projects, rather than eye candy XD

[olikraus]

Hmm.. good comments. I will provide more updates here: #2051 . Feel free to add more comments there...

[theeprawn]

The drawing solved by including the common method and using 8to32 function. It just needed line 181 +3 and 186 =4. Also I had to use my setting & commands for for raystar, to get contrast and postion right.
I am not sure what common2 and 4to32 wont work, maybe if it was 2x16 or 1x8, but as tile size is 8x8, 8to32 is equvalent.
I tested using u8g2 and u8x8 including clipwindow, powersave, flipmode and contrast all seem to work fine.
Only problem is its alot of added code for raystar with settings and functions.
Would you rather I cleaned the code and saved to another driver file or change current one and send PR, so can see changes?

[olikraus]

I think PR #1320 never got merged. At least some of the functionality shouldn' t be there in u8g2 (like gray level support). Although we could discuss this, it should be at least separted from the SSD1362 topic.

For the SSD1362 support, I had added a generic driver now, which should work for almost all devices.

• The winstar from SSD1362 256x64 driver Winstar WEA025664A #2051 should be supported
• The ZJY from aliexpress has been tested by myself and seems to behave like the winstar (test pending)
• You did mention a raystart display, probably the display REX025664A-ZIF OLED 256x64 as mentioned in PR code
• And there is one more display mentioned: Midas MDOT256064G1V-WM OLED 256x64

Can you test both displays with the latest u8g2 code (beta 2.34.11? I expect that both displays will work without problems. If not, I suggest to add code for these displays on top of the latest beta release. Modifications (if any) should be very small.
I mean, I do not see the need for a PR here, you could just tell me what else is need to make the raystar and midas displays work.

[theeprawn]

Tested all worked (u8g2 & u8x8)
I see you been busy with code. Strangle pixel count the display you have, but glade you had one to test on as well.

Only one modification I had to do for my display was set it to internal regulator, which is set for use with 12v display voltage.
line 376: U8X8_CA(0xad, 0x9e), //External /Internal IREF Selection, 9e: internal, 8e: external

I also suggest adding a reset for fade mode just incase someone uses it and system resets but display doesn't.
added after line 383: U8X8_CA(0x23, 0x00), //POR 0x00; Disable fade mode

As I was testing, I tested grayscale using x position to give level=(x2)>>4. Using that tweaking settings to see if any effect.
For displays the display i have the following seemed optimal and noted there effect
added to comment line 345: U8X8_CA(0x81, 0x9f), //Set contrast (set high light level = gray@15 brightness)
value/comment line 381: U8X8_CA(0xbc, 0x16), //Set pre-charge voltage level, 0..0x1f, 0x1f = 0.51Vcc (sets low light level = grey@01 brightness)

I never did get around to using the gray level, but idea would be have say bolder or dimmer text using updateDisplayArea with different gray level set.
The one thing I definitly uses is the font scrolling #1293 its great for having animated status icons.

[olikraus]

I added the command to disable the POR feature.
Do you need a 2nd constructor with internal IREF enabled? Shell I create such a constructor?

[theeprawn]

Hmm, I say no need to add 2nd constructor, unless you already have. I can add that command seperately to my code setup or change value in driver, as my library I have to alter anyway for scroll fonts feature. I not update library unless there is a reason, trying not to break what works XD

[olikraus]

ok, then. I keep everything as it is until someone else requires the internal regulator.

[olikraus]

I think, this can be closed...