New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LCD artifacts with RC7 #4994

Closed
Sicon76 opened this Issue Oct 10, 2016 · 11 comments

Comments

Projects
None yet
7 participants
@Sicon76

Sicon76 commented Oct 10, 2016

Hello! I have the following problem with the RC7:

20161010_223310

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

This comment has been minimized.

tampas commented Oct 12, 2016

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

This comment has been minimized.

Sicon76 commented Oct 12, 2016

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

This comment has been minimized.

Sicon76 commented Oct 12, 2016

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

This comment has been minimized.

Contributor

Blue-Marlin commented Oct 12, 2016

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

This comment has been minimized.

Contributor

Blue-Marlin commented Oct 12, 2016

@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

This comment has been minimized.

Sicon76 commented Oct 13, 2016

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

This comment has been minimized.

Member

thinkyhead commented Oct 22, 2016

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

@shacal

This comment has been minimized.

Contributor

shacal commented Dec 6, 2016

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

This comment has been minimized.

Member

thinkyhead commented Dec 6, 2016

@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

This comment has been minimized.

Contributor

AnHardt commented Dec 6, 2016

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

This comment has been minimized.

jpasqua commented Jul 1, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment