olikraus / u8g2

U8glib library for monochrome displays, version 2
Other
5.03k stars 1.04k forks source link

SSD1329 96x96 OLED with no Reset pin #1511

Closed cranefist closed 3 years ago

cranefist commented 3 years ago

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 commented 3 years ago

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

cranefist commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

HTB1murdSpXXXXcJXVXXq6xXFXXX3 oled

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 commented 3 years ago

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 commented 3 years ago

oled1

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 commented 3 years ago

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: https://github.com/olikraus/u8g2/blob/670d4deeabfa9a19ba269a8e6f422fec5025188b/csrc/u8x8_d_ssd1329.c#L52 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: https://github.com/olikraus/u8g2/blob/670d4deeabfa9a19ba269a8e6f422fec5025188b/csrc/u8x8_d_ssd1329.c#L49-L50

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

oled3

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

cranefist commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Please try the following:

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

  2. Change the following line https://github.com/olikraus/u8g2/blob/670d4deeabfa9a19ba269a8e6f422fec5025188b/csrc/u8x8_d_ssd1329.c#L211 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: https://github.com/olikraus/u8g2/blob/670d4deeabfa9a19ba269a8e6f422fec5025188b/csrc/u8x8_d_ssd1329.c#L282

  /* default_x_offset = */ 32,      /* x_offset is used as y offset for the ssd1329 */
cranefist commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

hmmm -14?

olikraus commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

cranefist commented 3 years ago

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...

olikraus commented 3 years ago

As a next step, please execute the u8g2 Example "FlipMode" (page buffer folder) (with the new 96x96 constructor). This example will rotate and flip the content ( = 8 different modes) There should be a full frame around the display all the time in all modes. If this is not the case (U-shaped frame), then still the offset might be wrong. I have set the horizontal offset to 32, but you mentioned it to be -16. It can be changed here: https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L489

cranefist commented 3 years ago

And yes... 128 pixels :) Im feeling like an idiot now :) Ofcourse you dont need to do that.

The remap configuration of 0x042 fixed everything! It was me who had the MIRROR mode that then messed everything up after that!

cranefist commented 3 years ago

197452213_577057806614647_5441064055484652089_n

Is the new constructor still valid? Shall i test it?

cranefist commented 3 years ago

Flipmode does not work correctly yet though, it still needs 32 pixel offsets in most of the modes. I tested it with only the remap configuration of 0x042, and changed square into 96x96 in the sketch.

olikraus commented 3 years ago

Is the new constructor still valid? Shall i test it?

This would be great.

This is what I did with the new constructor: By default the 0xa0 mode is 0x42 as suggested by you: https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L330

Appling flip 1, will use 0xa0 mode 0x51: https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L304-L316

Actually I am not sure about 0x51 value for flip 1 mode, this needs to be confirmed (it was more a guess from my end).

The horizontal offset can be adjusted here: https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L489-L490

At the moment I applied 32 pixel offset for flip mode 0 (the default) and 0 for flip mode 1. As you mentioned, the value 32 as offset might be wrong and the offset in flip mode 1 we didn't test yet, right?

As a summary so far: Flip Mode 0: 0xa0: 0x42 default_x_offset: ?? Flip Mode 1: 0xa0: 0x51 ??? confirmation required flipmode_x_offset: ??

cranefist commented 3 years ago

I will test it, wait a moment!

olikraus commented 3 years ago

Nice picture and OLED by the way. Looks very good already.

cranefist commented 3 years ago

Yes, its good to feel the progress :)

With 0xa0: 0x51 i need an X offset of 16 and a display offset of 96 pixels (0x0a2, 0x060) to get it centered.

And in 0xa0: 0x42 mode X offset of 0 and display offset of 0 (0x0a2, 0x000)

But on both cases, flipomode does not work.. it rotates around a wrong point i think. And only few modes hit the center of the frame.

So its still basically 128x96 in size. Ill see if i can change the start line and then move the display offset so that the corrupted part is out of the frame. Im starting to understand how to control this finally :)

olikraus commented 3 years ago

So its still basically 128x96 in size

Yes the controller SSD1329 has a frame buffer which is 128x96 pixel. Within that frame buffer, the display vendor has placed the visible area of the OLED. Unfortunately it is not clear where exactly the visible area is located.

to get it centered.

Hmm not sure what exactly you mean... hmmm

But on both cases, flipomode does not work.

hmm...

There is one more test execample, which is a little bit simpler. It actually switches between the two flip modes only: The example is called FlipMode and is located in u8x8 folder. Constructor name also starts with U8X8. There should be a text in the uppler left corner for flip mode 0. Flip mode 1 is the same, but rotated by 180 degree.

cranefist commented 3 years ago

I think the only way would be to somehow move the start line of the 128px wide side, but that cant be done? The "remap configuration" cant turn the display 90 degrees? I can understand how it works, the start line and offsets seem to be simple, just move by pixel values.

Otherwise, no matter what we do.. the display is always 128px wide and while rotating.. part of it is going to be outside of the actual display.

olikraus commented 3 years ago

I think the only way would be to somehow move the start line of the 128px wide side, but that cant be done?

Just to be technically precise: There is a term called "start line" in the data sheet. This is the 0xa1 or 0xa2 command (at least you mentioned, they both do not move horizontally but only vertically). So we can adjust the y offset by using 0xa1 and 0xa2. However the controller has a frame buffer of 128x96 and your OLED also is a 96x96 type. So I assume that this value can be fixed to 0. Any other value would only rotate the lines.

Talking about the width of the OLED and the position of the 96x96 OLED view area within the 128x96 let me instead use the terms x-offset or start column. This is unsolved. In the initial 128x96 constructor setting the x-offset was not possible. I changed this for the new 96x96 constructor of beta 2.29.6: Here we can use the default_x_offset value to assign the horizontal position (x-position, start column) of the viewable area.

Let us start with flip mode 0 (the default inital mode). In this mode, we have set 0xa0 to 0x41 which seems to be a good starting point. I think the correct values for 0xa1 and 0xa2 should be zero. The question is: What should be x offset. Is it 0, 16 or 32?

I know it is complicated, but it would be too good if we would have the correct values for the u8g2 users :-)

Here is another suggestion: Just sent me a picture with the constructor+c-code and the current setting with respect to default-x-offset, 0xa0, 0xa1 and 0xa2 I could then check with you what to change.

In history users also had sent me multiple pictures or complete movies of the FlipMode example. In either case I need the precise setting of the code which was used for the pictures or video.

cranefist commented 3 years ago

"The question is: What should be x offset. Is it 0, 16 or 32?" In 0xa0 0x41 mode it can be left to 0. Then the 96x96 square hits the frame.

But if i rotate it using the u8g2.setDisplayRotation or flip it using the u8g2.setFlipMode(0/1), it no longer hits the center. At least in all modes.

Im just uncertain can we accomplish this with these settings, it would almost require different offsets for different rotation modes. That's what i was thinking.

cranefist commented 3 years ago

So just to be clear, the ONLY thing that has been changed now is the 0xa0 0x41.

image

If you need, i can take a video of the flipmode test running, no problem.

The constructor that i'm now using is this : U8G2_SSD1329_96X96_NONAME_1_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ 10, /* dc=*/ 8, /* reset=*/ U8X8_PIN_NONE);

image

olikraus commented 3 years ago

Please ignore u8g2.setDisplayRotation(). u8g2.setDisplayRotation() is a pure software software solution and not relevant for the hardware setup. So all test should be done with U8G2_R0.

Again, we should have u8g2.setFlipMode(0) up and running. If u8g2.setFlipMode(0) works correctly then also all rotations will be correct (again, those rotations do not change the flip mode).

So just to be clear, the ONLY thing that has been changed now is the 0xa0 0x41.

0x41? or 0x42? I think the screenshot shows 0x42

So according to your updates, you have modified https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L489 to be zero. Great. And with this setup U8G2_R0 works correctly, right?

As a next step: Do not change anything but just use setFlipMode(1) What will it show? How will hello world and/or a full 96x96 frame look like? Can you sent a picture with setFlipMode(1)?

cranefist commented 3 years ago

https://www.youtube.com/watch?v=ZM4mU7-zHlw

Still 240p, will need to wait a bit :)

"And with this setup U8G2_R0 works correctly, right?" Yes!

cranefist commented 3 years ago

Ans yes, i changed the X offset of 32 to 0. It is not needed with the 0x042.

If you instead use the 0x51 you need an X offset of 16 and a display offset of 96 pixels (0x0a2, 0x060) to get it centered.

olikraus commented 3 years ago

looks cool already So in flipmode we have a shift in X and Y direction. Will a value of 32 for flipmode_x_offset undo the X offset? https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L490

cranefist commented 3 years ago

No, if i set any X offset.. it will be already off center in the normal mode. Thats the issue...

This setting: 0x51 you need an X offset of 16 and a display offset of 96 pixels (0x0a2, 0x060) to get it centered.

Also results in the similar flipmode test result. Where the viewport does not hit the center of the screen in but few modes.

cranefist commented 3 years ago

But you also do have this:

image

If its a separate offset for the flipmode.. maybe thats what is needed?

olikraus commented 3 years ago

If its a separate offset for the flipmode.. maybe thats what is needed?

There are indeed two different offsets: https://github.com/olikraus/u8g2/blob/b02be084947fc47f6850812a611a88ef42d268a4/csrc/u8x8_d_ssd1329.c#L489-L490

The value default_x_offset will be used for flip mode 0 The value flipmode_x_offset will be used for flip mode 1

As discussed above, default_x_offset must be 0 How will the video look like if you only change flipmode_x_offset to 32?

cranefist commented 3 years ago

I think there was no effect at all, maybe its not in use.. also... i think it would not help, as it would also need to have a Y offset.

12:45 https://www.youtube.com/watch?v=2Sg4fBJ67jw :)

olikraus commented 3 years ago

The video looks good (flip mode 0, right?)

i think it would not help, as it would also need to have a Y offset.

Yes, but we need to solve one problem after the other. Anyhow it is strange. So you say, that setting flipmode_x_offset to 32 will not change anything. hmm....

Ok, I do not want you to spent too much effort here. It looks like that flip mode 0 works correct. I modified the source above and I guess we can keep this as it is: So flip mode 0 works, but maybe flip mode 1 needs some further research.

cranefist commented 3 years ago

Actually it does image Centers it in X axis..

Yes, its all good for the X axis now. Just the Y axis also now needs to be fixed for the flipmode.

cranefist commented 3 years ago

So here is where we are now : https://www.youtube.com/watch?v=x8JNvRsgJaY

image image

olikraus commented 3 years ago

Wow, amazing. Thanks for the video. Actually the 0xa0 mode will be 0x51 as defined here:

https://github.com/olikraus/u8g2/blob/802dde59ac1e9a8c67aa934831c0cc7f020173d9/csrc/u8x8_d_ssd1329.c#L308-L324

Maybe you can takeover this code into your file. From now on, I think we need to modify only the 0xa2 argument value for flip mode 1 in line 319 from the above code.

cranefist commented 3 years ago

Yes, this makes sense.. i think it should work fine now! Ill fiddle the right values.. wait a bit.

Its now working correctly:

https://www.youtube.com/watch?v=qljPaIM0lQ4

image