[bugfix 2.0.x] FULL_GRAPHIC_SMART_CONTROLLER not working with RADDS (Arduino2) - *workaround found*

[mignolo4]

After the new menu and lcd rearrangements of the last days the Full Graphic LCD is not working anymore.

Before this new structure I had to edit the "ultralcd_impl_DOGM.h" file:

#elif ENABLED(U8GLIB_ST7920)
  // RepRap Discount Full Graphics Smart Controller
  #if DISABLED(SDSUPPORT) && (LCD_PINS_D4 == SCK_PIN) && (LCD_PINS_ENABLE == MOSI_PIN)
    U8GLIB_ST7920_128X64_4X_HAL u8g(LCD_PINS_RS); // 2 stripes, HW SPI (shared with SD card, on AVR does not use standard LCD adapter)
  #else
    **U8GLIB_ST7920_128X64_4X u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS);** // Original u8glib device. 2 stripes, SW SPI --- **with RADDS d Full graphics display this is the only option working!**
    //U8GLIB_ST7920_128X64_RRD u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS); // Number of stripes can be adjusted in ultralcd_st7920_u8gl  --- **default option but commented because it doesn't work!**

Compiling with Arduino IDE and the latest versions of marlin2.0 there are no errors but the lcd is empty even though the board is working perfectly with an host like Repetier.

The last working version I checked is the one with the ac5f276 commit.

[mignolo4]

After some experiment I've found the same parameter I used to change before the latest changes.
This time the correct file is ultralcd.h:

#elif ENABLED(U8GLIB_ST7920)
  // RepRap Discount Full Graphics Smart Controller
  #if DISABLED(SDSUPPORT) && (LCD_PINS_D4 == SCK_PIN) && (LCD_PINS_ENABLE == MOSI_PIN)
    #define U8G_CLASS U8GLIB_ST7920_128X64_4X_HAL
    #define U8G_PARAM LCD_PINS_RS // 2 stripes, HW SPI (shared with SD card, on AVR does not use standard LCD adapter)
  #else
    #define U8G_CLASS U8GLIB_ST7920_128X64_4X
    #define U8G_PARAM LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS     // Original u8glib device. 2 stripes, SW SPI
    //#define U8G_CLASS U8GLIB_ST7920_128X64_RRD
    //#define U8G_PARAM LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS 

So the question now is:
why we (radds+RepRap Discount Full Graphics Smart Controller owners) have to manually change those parameters?

[thinkyhead]

Did you also test changing the ST7920_DELAY values to see if it helped? If that option is required for DUE-based boards (or just RADDS), we could automate the selection, but we would want to confirm that it is a general requirement for that MCU or board.

[mignolo4]

Not tried indeed... and don't know how to be honest.

If you can, give me some instruction please... but since I don't want to waste your time, in the meanwhile I'll check on the forum to discover some info about that.

[marcio-ao]

@mignolo4: What @thinkyhead suggested is that you add the following to "Configuration.h":

#define ST7920_DELAY_1 DELAY_NS(0)
#define ST7920_DELAY_2 DELAY_NS(0)
#define ST7920_DELAY_3 DELAY_NS(0)

Then, tweak the values inside the parameters. For example, set them all to 50, or 100 and see what happens. Once you get it to work, lower the values one by one until you find the smallest values that work.

In general, however, tweaking these values tends to help if you are seeing a garbled display, which is not the problem I think you are having. It sounds like you found a workaround that has nothing to do with delays.

I'm not sure what the difference is between U8GLIB_ST7920_128X64_4X and U8GLIB_ST7920_128X64_RRD. Maybe someone who is an expert in U8G can chime in?

[AnHardt]

U8GLIB_ST7920_128X64_4X is a device driver from the original u8g-lib. On AVRs tis is very sloooooow. For that Marlin has its own implementation U8GLIB_ST7920_128X64_RRD. At 5V 8bit 16Mhz AVRs with good cabling this is as fast as the ST7920 allows, according to the datasheet, and too fast, if cables are too long, volage is 3.3V, 20 MHz or if there is anything reducing the signal quality (Symptoms: No picture is much too fast. Random pixels when a bit to fast). For that it has adjustable delays. It's even faster than hardware spi, because the hardware spi speed can only be adjusted in relatively big steps.

U8GLIB_ST7920_128X64_RRD was not made for the much faster DUE but should work with every processor when the delays are made big enough.
U8GLIB_ST7920_128X64_4X also works on the DUE and other processors (all what u8g-lib is made for) but even than it's much slower than a well tuned U8GLIB_ST7920_128X64_RRD.

Speed is that interesting here because the spi_send_byte routine for the ST7920 is called more than 2000 times a second.

U8g2 has about the same problem - but there is work in progress

[mignolo4]

@marcio-ao
Thank you ;-)
I added the parameters in configuration.h

#define ST7920_DELAY_1 DELAY_NS(50)
#define ST7920_DELAY_2 DELAY_NS(50)
#define ST7920_DELAY_3 DELAY_NS(50)

in combination with the "_RRD version" for the lcd, changing the delay from 50 to 100, 800 and 8000 but nothing changed.
The display is always empty, not a character, not a line, nothing.
(FYI the workaround means that I found the correct file for choosing my beloved working string
U8GLIB_ST7920_128X64_4X ; then, after some days/commits the modification was reverted and now we can find it in the ultralcd.h file)

@AnHardt
THAT is an explanation :-)
Now it's a little bit clearer, but it's also clear that it's something bigger than what I thought :-(
...and really interesting the introduction of the new version of the u8glib... maybe we can then jump directly there

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