128×64 ST7920 display problem (contrast and perturbative lines on background )

[cickok]

Hello, i have bought RepRapDiscount Full graphics controller with this display and controller from China. When I run it on Marlin FW 1.1.0 RC3, some problems with contrast appears. It is hard to describe only by words, so please take a look at attached pictures.

1. Setting high contrast To make status screen visible, I have to set contrast to high (analog via V0 pin), therefore there are some perturbative lines on the background. (mainly where are a lot of pixels active in the line)

But in this case, if i go to the menu, contrast is too high, and there are much more perturbative lines on the background.

2. Setting low contrast When I set lower contrast, to more comfortable view the menu, it is good for main menu, but for status screen and sub menu it is too low.

3. Boot logo I havent got a photo of boot logo, but only this is correct. (pretty visible on low contrast without any background lines)

4. Setting bad clock frequency The most interesting thing on this issue is, when I configure bad clock frequency of CPU in ultralcd_st7920_u8glib_rrd.h file, display goes completly crazy (it is understandable) BUT perturbative lines on the background completly DISAPPEAR.

5. Hello world project using the same u8glib library If i use the same u8glib library as marlin to view hello world or some more complicated menu etc, there is no problem with some perturbative lines.

Conclusion

If somebody ever meet with this issue, lets add your experiences or if somebody have some idea what to do with this please talk about it. My idea is:

• Set lower refresh rate of display (but i dont know where) or something like this. Or to make comunication slower etc.
• I would like to try control the display using HW spi, but i cant find contructor in the code to replace it. It seems that you are using your own constructor and script to initialize and control the disp. (not from u8glib)?
• I have read somewhere, that some cheap displays with ST7920 is to slow. Maybe this is the reason of this issue. Then, I would like to ask, how it is possible to make communication or refresh rate slower. (Then I dont know why it is "good" when bad CPU freq is configured ???)

By the way, I am still interested in HW SPI control of display to save some pins on arduino. If somebody know how to do it, please tell me.

Thank you very much for answers and ideas.

[Blue-Marlin]

We have whole bunch of these displays, from different sources, here. Usually, when the hardware (display, cables, adapter) are ok they are running flawlessly with our RAMPS boards. So my best guess is, you have a defect display.

Otherwise you did not tell us about your board.

Marlins constructor resides in ultralcd_st7920_u8glib_rrd.h. If you want to try original u8glib constructor replace

 U8GLIB_ST7920_128X64_RRD u8g(0);

in dogm_lcd_implementation.h with

U8GLIB_ST7920_128X64_4X u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS); // original u8glib device

All the full graphics displays are much 'slower' than the character displays. But at least for Marlin, the ST7920s are the fastest of them (as far as i know). Using hardware SPI for the usual REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER will not save any pin. All the buttons, the beeper, the encoder, all is directly connected.

[cickok]

Thank you. I will try to use original constructor.

About HW SPI and saving pins.... i mean if i will use HW SPI pins for SD card and also for display, i will save some pins and, what is most important, i will save computing time of MCU. Why to use SW SPI if there is determinated pheriphery for this (SPI periphery)?

To better understanding me... i am developing new control board, and i would like to implement some new features like SW control of motor currents or SW control of microstepping etc, so saving some MCU pins is interesting for me.

This is the Smart controller i bought. http://www.ebay.com/itm/391211116594?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I dont know about broken display, because as i said another sketches using u8glib is displayed without any problems.

And what about the refresh rate or something connected with refreshing the screen, do you know how to decrease it ?

Thank you for reply ones more, have a nice day.

[thinkyhead]

@cickok Can you confirm whether the situation is better with our current RCBugFix branch? We've been fixing a lot of bugs, and perhaps we fixed this one too!

[cickok]

Hello, I apology for the delay. I havent got much time now, but definately I will try it as soon as possible. I think that it is possible this week. Also new same LCD arrived to me, so i will try new HW.

I will inform you!

[jbrazio]

By looking at the pictures this issue seems to be bad wiring or cold solder points which maybe causing interference on the display and of course.. could also be a damaged display as already pointed out.

[cickok]

Hello @thinkyhead, I have tried the branch RCBugFix and it has got same behavior. I tried u8glib original contructor via HW SPI and also marlin _rrd constructor via SW SPI.

It seems to bad display HW. I am still waiting for postage with new display. Than i will update this thread.

Thank you for support. Peace

[jbrazio]

@cickok do you mind to close the issue and re-open if when the new display arrives the problem persists ?

[cickok]

I think no, leave it in this state... disp should arrive in next week, so i will update it early.

Its up to you

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[cickok]

Hello, I am sorry, but the new display still did not arrived :( due to some human factor. I will update it ones time when display will arrive. See you

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.