SSD1329 96x96 OLED with no Reset pin

[cranefist]

Hello

Is there possibility to get support for this display:

https://www.aliexpress.com/item/32779152549.html

Its 6 PIN SPI, and lacks the CS pin. I tried the only SSD1329 setup there is (U8G2_SSD1329_128X96_NONAME_F_4W_HW_SPI), but did not work. Also not sure what to do with the CS pin?

Also, i can confirm that the U8G2_SSD1317_96X96_F_4W_SW_SPI setup works, as it was listed as "not tested, not confirmed"
I tested it on this OLED : https://www.aliexpress.com/item/4000270343852.html
And it worked fine.

[olikraus]

You can pass U8X8_PIN_NONE as argument for the C's pin with any constructor.

[cranefist]

Thanks for the reply, it seems it was the DC pin, not the CS pin.
But could not get anything out of this, i though at least it would show some distorted frames with the 128x96 constructor. Tried both displays i had, and soldered the connections to be sure. Used the SW mode just to be sure i had the right pins.

[olikraus]

Do you have the PCB version of the display?

It does not make sense to remove the DC pin. DC connection is required unless this display is configured to 9 Bit SPI or I2C.
In fact looking at this picture: https://ae01.alicdn.com/kf/HTB1199UXcrrK1RjSspaq6AREXXaF.jpg I assume that your display is configured as I2C. Did you try any I2C constructor?

Maybe you can also post a better picture of the PCB back side. The picture from aliexpress does not reveal any details.

[cranefist]

There is only one constructor with the SSD1329 driver, and its SPI. I do also think its SPI as its stated so many times in the listing. Apparently its also a 4bit display.

[olikraus]

There is only one constructor with the SSD1329 driver,

Existing constructors are listed here: https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#ssd1329-128x96_noname

Thanks for the picture and yes, I agree looks like SPI. I assume pin labeled as RS is the D/C (DC or CD) pin.
Regarding U8g2 names, the mapping should be (see also https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#wiring):
clock <--> SCK
data <--> MOSI
cs <--> CS
dc <--> RS

[cranefist]

You assumed correctly :)

Ok, so i can change the connection mode in the constructor, and to mirror the image in correct orientation. But i can't change the pixel dimensions? That seems to be the last issue.

[olikraus]

Which constructor did you use?
This one: U8G2_SSD1329_128X96_NONAME ?

Some updates are needed, I guess. Please locate file u8x8_d_ssd1329.c on your local hard disc

Left-Right mirror:
Please locate this line:

u8g2/csrc/u8x8_d_ssd1329.c

Line 52 in 670d4de

U8X8_CA(0x0a0, 0x052), /* remap configuration, horizontal address increment (bit 2 = 0), enable nibble remap (upper nibble is left, bit 1 = 1) */

Please change the second value (0x052) so that the text is not mirrored. Good candidates might be 0x42 or 0x51. Is there any value, where the text is not mirrored?

Next step would be to fix the display y-offset:
Unfortunately there are two commands with two values and I also do not know how to change this:

u8g2/csrc/u8x8_d_ssd1329.c

Lines 49 to 50 in 670d4de

	U8X8_CA(0x0a2, 0x000), /* display offset, shift mapping ram counter */
	U8X8_CA(0x0a1, 0x000), /* display start line */

Maybe start with 0xa1:
Instead of
U8X8_CA(0x0a1, 0x000),
try
U8X8_CA(0x0a1, 0x008),
and see what happens. Goal will be to see the complete page on your display.

Once the correct values are known I will create the correct 96x96 constructor for your display.

[olikraus]

Just for reference. Details on the above command 0xa0, 0xa1 and 0xa2 are described in the controller datascheet:
https://www.bolymin.com.tw/uploadfiles/862/IC-Controller-Datasheet/ssd1329.pdf

page 36ff, sections 10.12 to 10.14

[cranefist]

U8G2_SSD1329_128X96_NONAME is correct, will start fiddling then! Really appreciate your help, this was the only display i could find that was the correct size for my needs.

The mirroring worked with the U8G2_MIRROR.

[cranefist]

0x42 worked for the mirroring, and i can actually now fill the whole screen.. its only 64 pixels wide and starts 32 pixels to the left.
u8g2.drawFrame(32,0,96,96); draws a box around the whole screen.

U8X8_CA(0x0a1, 0x008), this one caused some corruption. I will test more, but even now it would be functional.

[olikraus]

So with "0x42" you can use U8G2_R0 instead of U8G2_MIRROR, right?

u8g2.drawFrame(32,0,96,96);

Obviously the goal should be to see the frame with u8g2.drawFrame(0,0,96,96);

Maybe 0xa2 has to be used instead of 0xa1.
Will "U8X8_CA(0x0a2, 32), " work (with 0x0a1,0x000)?

[cranefist]

Yes, R0 works now. I seem to be able to move it up and down, using the display offset. But i cant seem the change it horizontally.

It is still vertically flipped, though. Based on the pcb board text.

Changing "display start line" always seems to result in corruption.

"Obviously the goal should be to see the frame with u8g2.drawFrame(0,0,96,96);" I fully agree :) Just though if it would help you to understand what is happening here.

"Maybe 0xa2 has to be used instead of 0xa1.
Will "U8X8_CA(0x0a2, 32), " work (with 0x0a1,0x000)?"
I had tested this, and it always moves the frame vertically.. i cant seem figure how to move it horizontally. Even in the datasheet, the examples show it moving vertically.

[cranefist]

First frame with just the 0x42, and u8g2.drawFrame(32,0,96,96);
Second is display offset, 0x020
Third is start line 0x020

[cranefist]

So maybe it should be rotated more... so that the display offset and start line would affect the 128px side? To make the 128px dimension vertical.. so that i could just move the start line by 32 pixels?

[olikraus]

so that i could just move the start line by 32 pixels?

Look like, that the SSD1329 can not do this, so we need to use a software approach. Let me check.

[olikraus]

Please try the following:

1. Revert the values for 0xa1 and 0xa2 to zero (as it had been initially)
2. Change the following line
   

   u8g2/csrc/u8x8_d_ssd1329.c

   Line 211 in 670d4de

   y += u8x8->x_offset; /* x_offset is used as y offset for the ssd1329 */

   
   from

      y += u8x8->x_offset;		/* x_offset is used as y offset for the ssd1329 */

to

      x += u8x8->x_offset;

3. Change the following offset to 32:
   

   u8g2/csrc/u8x8_d_ssd1329.c

   Line 282 in 670d4de

   /* default_x_offset = */ 0, /* x_offset is used as y offset for the ssd1329 */

  /* default_x_offset = */ 32,		/* x_offset is used as y offset for the ssd1329 */

[cranefist]

I dont think this works, its still 128px wide.. it simply moves the frame left or right.. i still need 128px to fill the whole frame, so if i use 96px.. there is unused screen space. Basically the pixel dimensions are wrong in the horizontal.

[olikraus]

Basically the pixel dimensions are wrong in the horizontal.

Yes, but I just wanted to see, whether we can control the left / right shift via software.

It is still vertically flipped, though. Based on the pcb board text.

I started to work on this also. There is a special u8g2 command, setFlipMode to controll this. Give me a minute, I will create the new constructor, then we can test the flip mode and also the horizontal offset.

[cranefist]

After fiddling... -14 puts it in the center. It hink its actually correct with this value... i have 96 addressable pixel in the horizontal

[olikraus]

hmmm -14?

[olikraus]

I have create beta 2.29.6 of u8g2 with all your research results so far.
Constructor names are:
U8G2_SSD1329_96X96_NONAME_1_4W_SW_SPI
and
U8G2_SSD1329_96X96_NONAME_1_4W_HW_SPI

I have extended the u8x8_d_ssd1329.c file, your display is now added to this file.

You can download the latest U8g2 beta release from here: https://github.com/olikraus/U8g2_Arduino/archive/master.zip

1. Remove the existing U8g2_Arduino library (https://stackoverflow.com/questions/16752806/how-do-i-remove-a-library-from-the-arduino-environment)
2. Install the U8g2_Arduino Zip file via Arduino IDE, add zip library menu (https://www.arduino.cc/en/Guide/Libraries).

[cranefist]

Yehs sorry ofcourse not -14.. but -16... and i realized i still had the MIRROR on... goddam.. did i test everything with the mirror mode.

[olikraus]

I still think we make good progress here.
Thanks for doing all the testing.

[cranefist]

So yes, i made an oopsie :)

I had the MIRROR mode on all this time... and now all i really had to do, was move the display offset 128 pixels

U8X8_CA(0x0a2, 0x080),

So I set my X offset back to 0 and just changed the display offset value & the remap configuration to 0x042.

I'm still not sure are my pixels correct.. the look fatter in the horizontal than on the vertical...

[cranefist]

Just to recap all the changes:

[olikraus]

Its now working correctly:
https://www.youtube.com/watch?v=qljPaIM0lQ4

Excellent. Good work.

[olikraus]

ok, I have create beta 2.29.7
hope that all changes are included
Again: Thanks a lot for your testing effort.

You can download the latest U8g2 beta release from here: https://github.com/olikraus/U8g2_Arduino/archive/master.zip

1. Remove the existing U8g2_Arduino library (https://stackoverflow.com/questions/16752806/how-do-i-remove-a-library-from-the-arduino-environment)
2. Install the U8g2_Arduino Zip file via Arduino IDE, add zip library menu (https://www.arduino.cc/en/Guide/Libraries).

[cranefist]

Perfect! Tested and works! Thanks a lot for your help! I could have never figured the RST pin thing, it was so counterintuitive for me. You were a massive help for my project.

You truly go all borg with these OLEDS :) Assimilate them all.

https://www.aliexpress.com/item/32334615160.html

Maybe this next? :) Not today though.. hah just came across it, transparent full color oled for 1.3$ .

[olikraus]

You truly go all borg with these OLEDS :) Assimilate them all.

hehe

Maybe this next?

ok, u8g2 only supports monochrome displays. Still a lot of work :-p

[cranefist]

One thing i noticed, this display is noticeably dimmer than my smaller 96x96 display. I would say like about 50% dimmer. Any change this has anything to do with the brightness settings?

[olikraus]

Did you try to increase the contrast to 255?

[cranefist]

Yes, i think it might be just that they both have the same size pixels.. but the smaller has smaller spaces between the pixels. So it looks brighter.

Though it seems there is no change in brightness 128-255... it all happens in 0-128.

[olikraus]

Another problem could be the VCOMH setting. I took over this value from the 128x96 display:

u8g2/csrc/u8x8_d_ssd1329.c

Line 367 in a1d90db

U8X8_CA(0x0be, 0x01c), /* VCOMH voltage */

Better value might be 0x1f or 0x3f. Max value is 0x7f (according to the datasheet), however not sure whether very high values could damage the display).
Another issue might be your power supply: If your OLED is connected to an Arduino directly, then the Arduino may not provide sufficient current. So setting the VCOMH value to very high values probably increases the power consumption beyond 100mA which will force the Arduino into reset (if you use the 5V output of the Arduino for the display).

Let me know whether 0x3f or any higher value work better. I will then add the same to the code.

[cranefist]

Well, i tested to connect it into my lab power supply. And i think i murdered it :) I always buy two when testing new displays though.

It worked with the 0x3f value while powered by the arduino... maybe it died because i connected the power first. Hard to say when it died exactly because of this. 0x3f had no effect while powered via nano, so this is why i tested to power it via a separate supply.

I think i need to order more of these, before i test any more power settings. As i need the backup so i can get it fitted in my prototype. The size is exactly right.

When i have more, ill test these power settings better.. as brightness is an important variable in choosing a display for this project.

[olikraus]

And i think i murdered it

Oh, I actually didn't expect that this would really happen.

0x3f had no effect while powered via nano

Maybe the nano is not able to provide the required current.
BTW: Are you sure the display is broken? You could have damaged the Nano instead.

[cranefist]

"Oh, I actually didn't expect that this would really happen." I always expect that i will burn few components in the testing phase :) Should have bought more in the first go, but was unsure am i able to get it running at all as it was a bit obscure display. Now that i know it will work, i can order more. Still need to do a bit of testing though.

"BTW: Are you sure the display is broken? You could have damaged the Nano instead."

Yes, i just reuploaded the code with the original current setting and switched the display and its working just like the old one did.

"Maybe the nano is not able to provide the required current." This is what i'm thinking, that even with the original current setting it simply did not get enough juice. Ill need to do some more testing on this matter, i definitely want to push all the brightness out of it that i can. Its well worth burning few 3.5$ displays.

Actually, there was something that i noticed. There was this slight variance in the brightness of the oleds in the outline that i was using with the spinning cube. And the variance followed the cubes rotation... this is probably because of low current. And the current is most likely divided by the pixel rows somehow. So the pixels lighting up in the corners of the cube affected the pixels on the outlines.

In the end, i'm going to be using it with an ESP32. So it will be powered directly from the powersource and can pull more current. Just testing it with a nano, as i know them much better. So less unknowns when dealing with new hardware.

[cranefist]

There is still some weirdness to this, the pixel mappins are not correct.

u8g2.drawFrame(0,0,95,95);
u8g2.drawFrame(2,2,91,91);
u8g2.drawFrame(4,4,87,87);
u8g2.drawFrame(6,6,83,83);
u8g2.drawFrame(8,8,79,79);
u8g2.drawFrame(10,10,75,75);

This results in squares that have 1 pixel width spacings.

You can also see how the bottom & last vertical line is not used.

[olikraus]

For me all looks correct. Which operation is incorrect according to you?

[cranefist]

The coordinates

u8g2.drawFrame(8,8,79,79);
u8g2.drawFrame(10,10,75,75);

75-79 has 3 pixels between them, but it shows up as 1 pixel.

While the other side works as expected ; 8-10 has one pixel between them and shows up as 1 pixel.

[cranefist]

I think its correct, does exactly the same thing on my other 96x96 display. I was thinking this somehow wrong i assume, was doing this to test the current.. as it shows as dimmer horizontal lines compared to vertical.

Though i still do not understand why it operates like this.

[cranefist]

Apparently I should have asked for the datasheet...

[cranefist]

static const uint8_t u8x8_d_ssd1329_96x96_noname_init_seq[] = {
    
  U8X8_START_TRANSFER(),             	/* enable chip, delay is part of the transfer start */
  
  
  U8X8_C(0x0ae),		                /* display off */
  U8X8_CA(0x0b3, 0x0F0),		/* set display clock divide ratio/oscillator frequency (set clock as 135 frames/sec) */			
  U8X8_CA(0x0a8, 0x05f),		/* multiplex ratio: 0x03f * 1/64 duty - changed by CREESOO, acc. to datasheet, 100317*/ 
  U8X8_CA(0x0a2, 0x000),		/* display offset, shift mapping ram counter */
  U8X8_CA(0x0a1, 0x000),		/* display start line */
  U8X8_CA(0x0ad, 0x002),		/* master configuration: disable embedded DC-DC, enable internal VCOMH */
  U8X8_CA(0x0a0, 0x042),		/* remap configuration, horizontal address increment (bit 2 = 0), enable nibble remap (upper nibble is left, bit 1 = 1) */
  U8X8_C(0x086),				/* full current range (0x084, 0x085, 0x086) */
#ifdef removed
  U8X8_C(0x0B8),				/* set gray scale table */
    U8X8_A(4),				/* */
    U8X8_A(6),				/* */
    U8X8_A(8),				/* */
    U8X8_A(10),				/* */
    U8X8_A(12),				/* */
    U8X8_A(14),				/* */
    U8X8_A(16),				/* */
    U8X8_A(18),				/* */
    U8X8_A(20),				/* */
    U8X8_A(22),				/* */
    U8X8_A(24),				/* */
    U8X8_A(26),				/* */
    U8X8_A(28),				/* */
    U8X8_A(30),				/* */
    U8X8_A(32),				/* */
#endif 

  U8X8_C(0x0B8),				/* set default gray scale table */
    
  U8X8_CA(0x081, 0x07F),		/* contrast, brightness, 0..128  */
  U8X8_CA(0x0b2, 0x023),		/* frame frequency (row period) */
  U8X8_CA(0x0b1, 0x021),                    /* phase length */
  U8X8_CA(0x0bc, 0x01F),                    /* pre-charge voltage level */
  U8X8_CA(0x0b4, 0x002),                    /* set pre-charge compensation level (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
  U8X8_CA(0x0b0, 0x028),                    /* enable pre-charge compensation (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
  U8X8_CA(0x0be, 0x01F),                     /* VCOMH voltage */
  U8X8_CA(0x0bf, 0x002|0x00d),           /* VSL voltage level (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
  U8X8_C(0x0a4),				/* normal display mode */
    
  U8X8_CA(0x023, 0x003),		/* graphics accelleration: fill pixel */
    
  U8X8_END_TRANSFER(),             	/* disable chip */
  U8X8_END()             			/* end of sequence */
};

Here is changes according to the datasheet, some of the stuff i could not add as it was missing.

But this is tested & working. There is still a bit of weirdness that im trying to solve. And i think its related to the variables i cant set:

writecommand(0x82); //second pre_charge speed writecommand(0xFE);

The spinning cube in the center dimms the lines on the edges. Not a big issue at least for my use case though.

These changes also fix the FPS example, before it was corrupted (result text was corrupted). Now it works.

[olikraus]

Variables can be sent with the sendF command:

u8g2.sendF("ca", 0xb1, 0x21);  // set phase length

I took over most of your values. The gray level definition is however defined by 0xb7 (not 0xb8).

Few days ago I received the same OLED. After testing I can see different brightness levels in the rows depending on the number of pixels used in that row. I think the charge pump on the OLED is not good enough. Maybe a cap on the PCB has a too low value.

[olikraus]

Increasing the output cap of the PCB Charge pump reduces the problem, but it is still there. I have also crosschecked this with my scope: It indeed looks like that the boost converter on the PCB is not able to provide sufficient current in case there are many pixel set in one row.

[cranefist]

Great info, that was exactly the same issue i had. So its a hardware side issue.

[olikraus]

Yes, I also assume there is a hardware problem.

[olikraus]

Ok, closing this topic. Please reopen for further issues.