SH1107 support

[T94T]

Is this library supporting the SH1107? I see the SH1106 is already implemented.

[lexus2k]

If display height is the only difference between SH1107 / SH1106, then such support can be easily added. If you agree to test, I can implement such support

[T94T]

We ordered 128x64 I2C SH1107 displays. It would be great if you can make the implementation! Of course we can test it as soon as we have access to the hardware.

[lexus2k]

Hi, I've added initial support for SH1107 display on v1.0.0_dev branch. So, your feedback is very appreciated.

[T94T]

Thank you very much! As soon as the displays arrive we will test the current code.

[T94T]

Still waiting for the hardware...

[lexus2k]

Ok, Thank you for keeping me informed

[T94T]

Now we have received the display. The library seems not to work correctly yet:

[lexus2k]

Wow, at least it works somehow. I will fix that.

[lexus2k]

Do you have link to datasheet for your display? I see that addressing mode looks non-standard. Do you know if display matrix is 128x64 or 64x128?

[T94T]

We will receive the datasheet tomorrow. It is a 64x128 matrix (vertical screen).

[lexus2k]

@T94T Please, check new update (the commit is attached to this issue), but use different constructor for your display:

DisplaySH1107_64x128_I2C display(-1);

[T94T]

DisplaySH1107_64x128_I2C display(-1);

DisplaySH1107_128x64_I2C display(-1);

[T94T]

Datasheet: 0.96竖屏ZJY096-6428TSWKG01.pdf

[lexus2k]

Thank you for helpful picture and for datasheet. I'm still trying to understand how they did connect SEG and COM pins to display matrix. According to SH1107 datasheet (page 18) display pages relate to SEG pins, and columns are connected to COM pins. On one of your pictures, I see that text is displayed correctly (draw, sprite, font items, etc..). That means that pages (each page is 8 vertical pixels) aligned along with SEG pins. SEG pins are bound to multiplex value usually (at least for ssd1306 displays). What confuses me in provided datasheet, that they set multiplex to 63, but that long side should be 127. Next, I don't understand completely offset to COM pins, since program (0,0) point actually is displayed at (32,0) position.

Now I changed display initialization to the procedure described in the datasheet provided by you. Can you try and let me know the results for DisplaySH1107_64x128_I2C display(-1);?

[T94T]

DisplaySH1107_64x128_I2C display(-1);

[T94T]

Now it is working much better. Drawing lines does not seem to be ok and the screen is flickering too much (see end of gif):

[lexus2k]

I noticed that it is flickering too much in invert mode only 0xA7. And regarding light flickering in normal mode 0xA6, maybe it is required to tune some parameters, and the datasheet is not the correct. May be you may try to change here lcdgfx/src/v2/lcd/sh1107/lcd_sh1107.inl (lines 2xx ):

1. Contrast value 0x81, 0x01, 0x2F, // contrast value to 0x2F according to datasheet to 0x81, 0x01, 0x80,
2. 0xD5, 0x01, 0x51, // set to default ratio/osc frequency to 0xD5, 0x01, 0x80,
3. 0xDB, 0x01, 0x35, // vcom deselect to 0x20 // 0x40 to 0xDB, 0x01, 0x40,

Those are just assumptions, not sure if they help

Regarding lines - that's ok for all monochrome displays like sh1106, ssd1306, sh1107 and so on. That happens, because direct draw functions do not use SRAM memory buffer of microcontroller, and serial interface of these displays does not allow reading data back. At one write operation you can address 8 pixels at once, and since it is impossible to read old 8 pixels value to modify just one bit in byte, you see what actually happens. To avoid that, just use canvas buffer, draw in memory, and the output canvas to display.

[T94T]

Ok, thank you so much so far. We will test the contrast values in the next days.

[lexus2k]

And one more: in the post https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-734796561 there is no flickering reported while in the post https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-735049148 flickering is reported

There are only 2 difference between these 2 library versions (you can see that in 82c5fdc commit):

1. That display flipped horizontally and vertically in second version
2. Muxer is set to correct 127 value (128 height of the display); and that's it.

You can try 0xc0 instead 0xcf, and 0xa0 instead 0xa0 | 0x01 or to use flip functions, I described in email

[T94T]

I cannot figure the differences out. The https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-734796561 is not flickering and is also much brighter than https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-735049148

[T94T]

Those settings seem to hide the flickering issue:

2. 0xD5, 0x01, 0x51, // set to default ratio/osc frequency to 0xD5, 0x01, 0x80,
3. 0xDB, 0x01, 0x35, // vcom deselect to 0x20 // 0x40 to 0xDB, 0x01, 0x40,

This is strange because the datasheet recommends other values.

[lexus2k]

Thank you for the results. I do appreciate your help.

This is strange because the datasheet recommends other values.

That's exactly what I'm talking about. BUT, could you please test latest version with official datasheet values, but use different display orientation: You can try 0xc0 instead 0xcf, and 0xa0 instead 0xa0 | 0x01 or to use flip functions, I described in email

In current library config scanning is done from 127 to 0 line and from 63 to 0 column. I consider to make one more check: use normal scanning direction from 0 to 127 for rows and from 0 to 63 for columns. Maybe, the problem relates to GDDRAM memory refresh cycles / or internal logic of display SH1107 controller.

[T94T]

All of these do not affect the flickering: display.getInterface().flipVertical( 0 or 1 ); display.getInterface().flipHorizontal( 0 or 1 ); display.getInterface().setStartLine( 0 to 127 ); // most important parameters display.getInterface().setDisplayOffset( 0 to 127 ); // most important parameters display.getInterface().setSegOffset( 0 to 127 ); // most important parameters

[lexus2k]

Thank you so much for the tests. Finally I made commit of the values from comment https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-735256206 If you need any help, let me know

[T94T]

That's great. Thank you so much for your effort. We are going to test your implementation even further when we got to the UI design stage.

[lexus2k]

@T94T

Let me know the results. If you need some additional functionality, please submit new issue. If you have any problems with SH1107 display, feel free to re-open this one issue.

[T94T]

We have some trouble displaying text and graphics. If we do not clear the display before printing it generates artefacts (example below: the bottom area of the symbols). This problem we do not have with a SSD1306 display.

[lexus2k]

Hi, let's try to fix that.

Can you do more simple test for me and record screen content?

    display.setColor( 0xFF );
    display.fillRect( 8, 8, 55, 119 );
    delay(2000);
    display.drawRect( 4, 4, 59, 123 );
    delay(2000);
    display.setColor( 0x00 );
    display.setBackground( 0xFF );
    display.drawRect( 19, 19, 44, 108 );
    display.drawRect( 21, 21, 42, 106 );
    delay(2000);
    display.setColor( 0xFF );
    display.setBackground( 0x00 );
    display.drawRect( 20, 20, 43, 107 );
    delay(2000);

[T94T]

This is the result:

[lexus2k]

The result looks good, as expected.

More questions:

1. Which micro controller is used in your project?
2. What are the dimensions of monochrome pictures, used in the project?
3. Are you using drawBitmap1() method?

If you can provide some small source code that demonstrates problem, it would be useful

[T94T]

It is strange. I now extracted the affected parts out from our repo and created a small sample program. With this it works.

1. uC: ATtiny3217
2. Dimesion is 62x62px
3. Yes, drawBitmap1() is used.

[lexus2k]

Thank you.

1. Your first answer (ATtiny3217) gives me the point, how lcduint_t and lcdint_t types are defined. So, they are 16-bit for your hardware and there is no issue with variable size.
2. Good, 62x62 is smaller even than signed char.
3. ok, I reviewed the code of drawBitmap1() once more and didn't any problems.

If you use Arduino IDE, it will not let you flash the code bigger than flash size of ATtiny3217. So, the code size is not the problem. But what about SRAM? How many free bytes do you have? Maybe free bytes is not enough for the program stack? On AVR controllers stack goes from RAM END to RAM BEGIN, and global variables are allocated from RAM BEGIN to RAM END. When both guys meet each other, wonderful and unexpected things happen.

[T94T]

Hi Aleksei,

Hope, you're doing well. We just opened a new issue on your GitHub repo. We needed to change the display. It would be great if you can add support for the ST7735 0.96'' display. If you can give me your PayPal address, we can send you $50.- Is this ok for you?

Regards, Michael

Am Fr., 8. Jan. 2021 um 12:30 Uhr schrieb Aleksei @.***

:

Thank you.

1. Your first answer (ATtiny3217) gives me the point, how lcduint_t and lcdint_t types are defined. So, they are 16-bit for your hardware and there is no issue with variable size.
2. Good, 62x62 is smaller even than signed char.
3. ok, I reviewed the code of drawBitmap1() once more and didn't any problems.

If you use Arduino IDE, it will not let you flash the code bigger than flash size of ATtiny3217. So, the code size is not the problem. But what about SRAM? How many free bytes do you have? Maybe free bytes is not enough for the program stack? On AVR controllers stack goes from RAM END to RAM BEGIN, and global variables are allocated from RAM BEGIN to RAM END. When both guys meet each other, wonderful and unexpected things happen.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lexus2k/lcdgfx/issues/32#issuecomment-756707053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDG2GZ4CS7LKDAEPPEAOETSY3UENANCNFSM4TS7MQ6A .

[lexus2k]

Hello Michael,

That's not a problem if you help to debug new display. I'm just wondering if you can provide datasheet for the display, describe the communication interface to the display, you're going to use. PS. I have the link to paypal account at lcdgfx library github page. Just I don't know if it works.

Best regards