Sanguinololu + Full graphics controller

[thucar]

I've been struggling with this one for couple months now.

I have the 12864 Full Graphics Smart Controller hooked up to my Sanguinololu but all I'm seeing is this:

At the same time, trying to blindly navigate the menu using the click-wheel works just fine. So it must be something in the pins.h that's not adding up.

[eboston]

Have you tried adjusting the contrast?

[thucar]

There does not seem to be any way to adjust the contrast on this panel. No trimpots anywhere.

[eboston]

Could be the default contrast value for the display isn't correct then. It
would require you to modify the value in the code, recompile and upload to
change it. Contrast is just one possibility though.
On Jul 20, 2015 8:45 PM, "thucar" notifications@github.com wrote:

There does not seem to be any way to adjust the contrast on this panel. No
trimpots anywhere.

—
Reply to this email directly or view it on GitHub
#2482 (comment)
.

[thucar]

Just did a quick test with a 2k2 resistor between gnd and contrast. The contrast lowered down to where the grid was barely visible, but still all I can see is the grid. So does not seem to be a contrast issue.

Btw, the picture above was taken at an angle where the grid was most visible. It does not look that bad to the naked eye

Also, what I forgot to mention earlier - the SD card fails to initialize. That's what got me to think that maybe it's as simple as having two swapped pins and LCD data is being passed to the SD and vice versa.

[ntoff]

Grab the schematic for your board and the LCD and cross reference with the pins_board.h file you're using, that would tell you whether the pins are wrong.

[Nprod]

Are you sure it's hooked on correctly?

[thucar]

I guess I'll have to bust the sanguinololu out of the printer again and take a look at the pin mapping then... That was going to be my last resort as it's the Printrbot Original and there's no easy way of doing it.

I was hoping that someone who has the panel working with Sanguinololu would just ride in on a white horse and say "Yes, this is the correct pin mapping for you: ta-dah!" :)

I'm pretty sure I have the connectors hooked up the right way, as reset button and selector wheel with click all work just fine and they use pins from both headers.

[thucar]

Progress!!

As I suspected, it was the pins.h
The definition of pins when U8GLIB_ST7920 is loaded, was made for Melzi pinout. I added one for Sanguinololu as well with correct pins and I'm now seeing things on my LCD! :)
I'm actually seeing the menu, but it's all mangled and torn as you can see on the pic.

This is what I did:

#ifdef U8GLIB_ST7920 //SPI GLCD 12864 ST7920 ( like [www.digole.com] ) For Melzi V2.0
   #if MB(MELZI) // Added check for Melzi boards
     #define LCD_PINS_RS 30 //CS chip select /SS chip slave select
     #define LCD_PINS_ENABLE 29 //SID (MOSI)
     #define LCD_PINS_D4 17 //SCK (CLK) clock
     #define BEEPER 27 // Pin 27 is take by LED_Pin, but Melzi LED do nothing with Marlin and I take this pin for BEEPER.... See here > [github.com] , If you want use this pin with Gcode M42 instead BEEPER
   #else // Added pins for Sanguinololu 1.3
     #define LCD_PINS_RS     4 
     #define LCD_PINS_ENABLE 17 
     #define LCD_PINS_D4     30 
     #define LCD_PINS_D5     29
     #define LCD_PINS_D6     28
     #define LCD_PINS_D7     27
   #endif

[Nprod]

@thucar I actually had similar-looking glitches when trying to figure out how to connect a text-based LCD to my Melzi. It was surprisingly hard to find solid info on what numbers the pins correspond to, so i uploaded a little "1 second pulse" program and checked which pin was flashing with the buzzer. The pinout i got for the Melzi is as follows:

GND	+5V
27	10
28	11
29	16
30	17

GND	RS
5	7
+5V	6

This may be different for the Sanguino because it has 4 additional pins in the header, two of which are for +12V/GND, and the other two are an extra digital and analog pin. The beeper and encoder have nothing to do with the LCD, so they will work even when it's off.

[thucar]

@Nprod Do you have any idea which pins were incorrect when you got the glitchy display? I'm trying to narrow it down to individual pins.

Right now I gather the LCD only needs 3 pins to work:
LCD_PINS_RS
LCD_PINS_ENABLE
LCD_PINS_D4

I've mapped all pins using the wiki image (it seems the silkscreen has an error - PWM/D12 should be PWM/D4):

And cross referenced that against both the sanguinololu and Full graphics display schematics. This is the physical pinout:

   EXP1
 1 BEEPER - NC
 2 BTN_ENC - D16
 3 LCDE - D17
 4 LCDRS - D12 (PWM)
 5 LCD4 - D30 (A1)
 6 LCD5 - D29 (A2) [Not used?]
 7 LCD6 - D28 (A3) [Not used?]
 8 LCD7 - D27 (A4) [Not used?]
 9 GND - GND
10 VCC - 5v

   EXP2
 1 PB3 - MISO
 2 PB1 - SCK
 3 BTN_EN2 - D11
 4 SD CSEL - D31 (A0)
 5 BTN_EN1 - D10
 6 PB2 - MOSI
 7 SD DET - NC
 8 RESET - RESET
 9 GND - NC
10 KILL - NC

[AnHardt]

If you got this far, (Having a picture but scrambled)
it smells more like a contact or timing problem than pinning.
Are you sure it's a ST7920? What branch are you on?

[thucar]

I'm running the Development branch

[chris-bo]

What resonator frequency are you using?
I run my Board at 20MHz this caused some timing issues, which looked like that (#1601 )
Since then I comment that #pragma GCC optimize (3) in ultralcd_st7920_u8glib_rrd.h, maybe this helps

[thucar]

@chris-bo You, sir, are THE man 👍

That did it! I now have a purrty and stable display. Also, this fixed my SD card initialization issue... makes sense.

However, I'm left with one last problem. The LCD screen will not scroll. So When I try to scroll down to menu items on the second page, the highlighting block just disappears.

False alarm, it was just me messing with the files I was not supposed to be messing with.

Case closed!

[thinkyhead]

So, as a summary… You found that…

• Commenting #pragma GCC optimize (3) fixed the timing problems with your display
• The Added pins for Sanguinololu 1.3 addition was unnecessary

…?

I just want to make sure that no extra changes to Marlin are needed, but maybe we need some extra documentation about that potential display issue.

[thucar]

• Yes
• The added pins were necessary.I ended up changing it from this:

    //LCD Pins
     #ifdef DOGLCD
       // Pins for DOGM SPI LCD Support
       #define DOGLCD_A0  30
       #define DOGLCD_CS  29
       // GLCD features
       #define LCD_CONTRAST 1
       // Uncomment screen orientation
         // #define LCD_SCREEN_ROT_0
         // #define LCD_SCREEN_ROT_90
       #define LCD_SCREEN_ROT_180
         // #define LCD_SCREEN_ROT_270
       #else // standard Hitachi LCD controller
       #define LCD_PINS_RS        4
       #define LCD_PINS_ENABLE    17
       #define LCD_PINS_D4        30
       #define LCD_PINS_D5        29
       #define LCD_PINS_D6        28
       #define LCD_PINS_D7        27
     #endif

To this:

    //LCD Pins
   #ifdef DOGLCD
     #ifdef U8GLIB_ST7920 //SPI GLCD 12864 ST7920 ( like [www.digole.com] )
       #define LCD_PINS_RS     4 
       #define LCD_PINS_ENABLE 17 
       #define LCD_PINS_D4     30 
       //#define LCD_PINS_D5     29
       //#define LCD_PINS_D6     28
       //#define LCD_PINS_D7     27
       #if MB(MELZI)
         #define LCD_PINS_RS 30 //CS chip select /SS chip slave select
         #define LCD_PINS_ENABLE 29 //SID (MOSI)
         #define LCD_PINS_D4 17 //SCK (CLK) clock
         #define BEEPER 27 // Pin 27 is take by LED_Pin, but Melzi LED do nothing with Marlin and I take this pin for BEEPER.... See here > [github.com] , If you want use this pin with Gcode M42 instead BEEPER
       #endif
     #else
       // Pins for DOGM SPI LCD Support
       #define DOGLCD_A0 30
       #define DOGLCD_CS 29
       #define LCD_CONTRAST 1
     #endif
     // Uncomment screen orientation
     #define LCD_SCREEN_ROT_0
       // #define LCD_SCREEN_ROT_90
       // #define LCD_SCREEN_ROT_180
       // #define LCD_SCREEN_ROT_270
     #else // standard Hitachi LCD controller
       #define LCD_PINS_RS        4
       #define LCD_PINS_ENABLE    17
       #define LCD_PINS_D4        30
       #define LCD_PINS_D5        29
       #define LCD_PINS_D6        28
       #define LCD_PINS_D7        27
     #endif

[thinkyhead]

Thanks @thucar! So it looks like the essence of your change is in the comment #2482 (comment). I've made a PR cleaning up the pins_SANGUINOLOLU_11.h file and adding the extra MB(MELZI) condition. See #2504.

[thucar]

Looking good, @thinkyhead!

Also, since I discovered that the following pins have no actual use with the Full graphics controller:
LCD_PINS_D5
LCD_PINS_D6
LCD_PINS_D7

I've gone and scavenged those for other useful purposes.

I'm now using Pin 29 for LCD RESET, which frees up the sole PWM pin to be used as FAN_PIN
Also pin 28 is now BEEPER and Pin 27 is now reserved for PS_ON_PIN

[thinkyhead]

@thucar If I merge #2504 into Development, can you submit a PR or link to a commit with your additional changes? You would then just have to grab the latest Development branch, make a copy as another branch, and start from there to add your changes.

[Nprod]

@thucar D4,5,6 and 7 are for the text-based LCD's in 4-bit parallel mode. When using SPI or I2C you need way fewer pins than that, leaving a few for the encoder, beeper and a few other things.

[wvdakker]

I have a Geeetech.com 12864 Graphics Smart Controller which is connected to a Melzi 2.0 board (ATMEGA1284P). I compiled the Marlin software with U8Glib v1.19.1 and the result is also a scrambled screen

Disabling the optimize(3) pragma did not help.
Is this problem solved and am I doing something wrong? Or is this a new issue?

[fiveangle]

@wvdakker - please open a new issue for your problem

[nkuck]

Did you get the display problem resolved? If so, can you share the fix, as Ian having the same problem. Thanks.

[AnHardt]

What problem?
These issue went through several states. Code for this display changed a lot during the last 3 years.
Open a new issue and follow the form.

[wvdakker]

See issue #3815.
That solutions works for me.

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

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