LCD artifacts with RC7

[Sicon76]

Hello! I have the following problem with the RC7:

It's compiled for a Melzi board with IDE 1.6.9 and pragma optimize (3) commented in ultralcd_st7920_u8glib_rrd.h, the RC6 didn't have this problem so it shouldn't be the hardware. I did the following tests:

1. decomment the pragma in ultralcd_st7920_u8glib_rrd.h: arduino can't upload the hex due to an "avrdude: verification error; content mismatch" ?!?!?

2. try the latest rcbugfix but I receive this "error: expected initializer before 'homing_feedrate_mm_s'"

Do you have any idea?

Thank you!

[tampas]

have you tried to reduce de spi_speed for you lcd? i was getting the same error with a Viki2.
In your configuration.h just find and uncomment #define SPI_SPEED SPI_HALF_SPEED

[Sicon76]

I tried, even with the other SPI_SPEED, but nothing :( . It's really strange, I didn't have this problem with the other RC (always commenting the pragma optimize), it starts with the RC7

[Sicon76]

Well, I found a solution: since the RC6 works well, I simply overwrite the ultralcd_st7920_u8glib_rrd.h from the RC6 and now the LCD works with the RC7. It seems that the new changes to the ST7920_SWSPI_SND_8BIT function don't work with a melzi board with a RRDS LCD, hope it helps

[Blue-Marlin]

Did you find to try the optimised delays for your board and display combination?

Simply uncomment

//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_0_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP

and replace DELAY_0_NOP with higher and higher values (DELAY_1_NOP, DELAY_2_NOP, DELAY_3_NOP, DELAY_4_NOP) until the display problems disappear. Then try to minimise the sum of the delays.

for example:
1,0,0 no
1,1,0 no
1,1,1 no
2,1,1 no
2,2,1 works sum 5
1,2,1 works sum 4
0,2,1 works sum 3
0,1,1 no
0,2,0 works sum 2
fin

This loop is called 1 time for every byte on the screen. The delays sum up. But since RC7 we can precisely adjust them and have not to hope for a better result with switching #pragma GCC optimize (3) off and hoping GCC makes the code worse enough.
You just have to find your optimum.

We would be very glad if you could test the Melzi - RRDS combination in this way.
Up to now we have no report for this combination - and for that we have no special case for it.

[Blue-Marlin]

@tampas
We do make our own software SPI here with the ST7920. To get some more speed we replaced the standard routine in u8glib which is considerably slower (~+50%).
Reducing SPI_SPEED for a VIKI2 may help - but not with this special display.

[Sicon76]

It's a pleasure for me to help you :) . I tried different combinations and the optimum seems these ones:

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_1_NOP
#define ST7920_DELAY_3 DELAY_1_NOP

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_0_NOP
#define ST7920_DELAY_3 DELAY_2_NOP

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_2_NOP
#define ST7920_DELAY_3 DELAY_0_NOP

My board is an Anet V1.0 (a Melzi 2.0 clone) with the classic RRDS full graphic LCD module and compiled with Arduino 1.6.9

[thinkyhead]

I think all we can really do is document this option and include it in the "Troubleshooting" section of the documentation.

[shacal]

Tested this with RAMPS 1.4 and RAMPS Plus boards with reprap original full lcd and 3 china copy and this works best for all of them:

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_2_NOP
#define ST7920_DELAY_3 DELAY_0_NOP

Maybe this can be default for RepRap Full LCD...

PS: If you shield your cables and have ground shield around the LCD and cables you can tweak that value down to DELAY_1_NOP.

[thinkyhead]

@shacal Currently we specify defaults on a per-motherboard basis. I'm not sure why these differences exist. I'd be hesitant to override them all based on the controller. The original concept was integrated by @AnHardt so perhaps he can comment.

[AnHardt]

The delays for 16 and 20MHz are determined by the ST7920 datasheet and the disassembled Arduino code to fulfill the requirements. At 16MHz 0,0,0 is just a little to fast for the datasheet values but works usually flawlessly on a Arduino MEGA - RAMPS 1.4 - REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER combination with the original 200-300mm long cables.
If you get pixel errors with this combination usually, the cables are too long, the plugs or crimps are bad or you have interferences with other cables near by. Also having a programmer or other devices plugged to the ISP-port have been reported to have bad influences. Weak power supplies as well as external thermocopler boards have been reported to me.
For some boards we have reports - they never work with these short delays - regardless of the circumstances. I don't know why these boards need longer delays. The possible reasons include: Too long traces, additional resistors, capacitors, inductivities, LEDs, ... on the relevant lines, onboard SPI devices, level shifter, untuned chistals, bad filtered voltage regulators, omitted blocking capacitors at the processor, ...

For some common boards we have added exceptions in ultralcd_st7920_u8glib_rrd.h but if the number of exception grows this will be unmaintainable.
For users with long cables we already have the possibility to define

// If you want you can define your own set of delays in Configuration.h
//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_0_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP

in their configurations.
I see no reason why this should not work for boards. Putting the defines into the pin-files should do the job.

If 0,0,1 would not work for almost all 16MHz boards we'd have much more trouble with it.

Every nop counts! Each of the nops is used vor every pixel transferred to the display.

[jpasqua]

The docs for the Einsy Rambo board suggested using a non-zero value for ST7920_DELAY_2 , but their suggestion was in terms of NOPs. I started with a value of DELAY_NS(800) and turned it down until I found a value that seems to work reliably. Here's where I ended up:

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
  #define ST7920_DELAY_1 DELAY_NS(0)    // Einsy Rambo
  #define ST7920_DELAY_2 DELAY_NS(200)  // Einsy Rambo
  #define ST7920_DELAY_3 DELAY_NS(0)    // Einsy Rambo

[duembeg]

This is an old thread that I arrived at because I was having this kind of issue... after deep debugging (take out the oscilloscope and other measuring tools) I found the culprit to my problems. Hopefully this might shed some light for some folks.

The symptoms here can be caused by several issues including timing; my issue at the end wasn't timing but voltage levels, it was resolved by adding a 3.3v reg (MCP1700-3302E) to power the LCD instead of the 5V from EXP1 (5VCC -> MCP1700->LCD).

Setting up context: I bought several of these displays (7) from different brands most look the same and some have no branding. Most are advertised as having a VCC capability of 3 to 5V. Out of the 7, 3 worked with no issues (getting lucky). The rest had artifact problems as above, especially when browsing through the menus (using the knob). sometimes just going back to the top menu clears the display.

I had a set-up working with 1.1.9 and when moved to 2.0.0 started having this issue (suspected it was timing and how I found this thread) at that time it was also on a 8 bit CPU (einsy rambo). Now on the skr v1.4... Still the issue remained.

After taking a deeper look with the oscilloscope I noticed that the SPI signals were 3.3V level not 5V level, but the display was powered by 5V rail. I know you can get lucky if the signal is clean and 3.3v signaling can work with 5V but these were not pretty signals specially with long ribbon cable from board to lcd. After that I got myself a 3.3v regulator to power the LCD, 5V to 3.3 REg to LCD... and magic all the 7 Display work no issues.

Advice from old engineering unspoken rules, always check power first. Then check your timing.

[capibara1]

Hi @duembeg ,

Thanks for the comment.
I am interested to see how you connected the 3.3v regulators to the LCDs. Can you share pictures of your setup?

Thanks in advance

[duembeg]

 Sure this is a schematic of my Marlin UI board... you can see VCC coming via EXP1 then trough U1 to LCD header

…

On Tue, Jun 2, 2020 at 12:13 PM capibara ***@***.***> wrote: Hi @duembeg <https://github.com/duembeg> , Thanks for the comment. I am interested to see how you connected the 3.3v regulators to the LCDs. Can you share pictures of your setup? Thanks in advance — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4994 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZX5LW54DWFAPZO7BJES4LRUVFN3ANCNFSM4CSL6DOA> .

[github-actions]

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.

[github-actions]

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.

[github-actions]

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.