Trying to test LCD character displays using pogo pins - characters are garbled

[seanspotatobusiness]

I wanted to test about 20 LCD character displays to make sure they're working as expected but there is a perculiarity which has thwarted me. I'm using pogo pins so I don't have to solder anything to the LCD PCBs. The problem is that if I start sending stuff to display on the LCD and then connect the LCD, the output is garbled. I only get the expected display if I connect the LCD and then start the script which is not practical with one pair of hands. The script is as follows:

Code: Select all

import RPi.GPIO as GPIO
from RPLCD.gpio import CharLCD
import time

     
# Initialize display. All values have default values and are therefore optional.
lcd = CharLCD(pin_rs=36, pin_e=38, pins_data=[31, 33, 35, 37],
              numbering_mode=GPIO.BOARD,
              cols=16, rows=2, dotsize=8,
              auto_linebreaks=False,)

while True:
    lcd.write_string("abcdefghijklmnop\r\nqrstuvwxyz012345")
    time.sleep(1)
    lcd.clear()

Any idea why this happens? Since the characters are transmitted again every second, I'd expect maybe the first connection to display garbled letters, if anything, but the nect transmission should give the correct letters, right? Apparently not.

[pcmanbob]

Probably because the lcd setup line calls an Initialize routine within the RPLCD software that sets the display up, I would try including the setup line within the while loop and increase the time.sleep to several seconds so each display has time to be setup and display the text before being setup again.

[seanspotatobusiness]

You're right; thanks. I thought that part was just to configure the RPLCD code to send the correct signals - I didn't realise it was communicating to the LCD at that point. It works as well as I need it to now, to check that my LCD screens are functioning but there is still one perculiarity. In the video below, you see that the screen occasionally changes to display some seemingly random characters on the bottom the line. Ocasionally it also goes completely blank. Any idea what that's about? It happens with other screens too. (The one in the video has a header soldered to it but the others don't).

https://www.youtube.com/watch?v=uTN3Vad8qDI

The code is now:

Code: Select all

import RPi.GPIO as GPIO
from RPLCD.gpio import CharLCD
import time

while True:
    lcd = CharLCD(pin_rs=36, pin_e=38, pins_data=[31, 33, 35, 37],
              numbering_mode=GPIO.BOARD,
              cols=16, rows=2, dotsize=8,
              auto_linebreaks=False,)
    lcd.write_string("abcdefghijklmnop\r\nqrstuvwxyz012345")
    time.sleep(1)
    lcd.clear()
    

[pcmanbob]

My guess would be that its because you are constantly resetting the display with the set up routine , which is why I suggested you increase the delay at the end of your program to several seconds to allow the display to settle and it will mean you are not resetting the display so often.

[seanspotatobusiness]

Oh yeah, sorry I missed that in my excitement to try your first suggestion! Thanks again.

[FTrevorGowen]

In addition to @pcmanbob comments it may be worth checking the (fixed) timings for E-strobe lengths, delays etc. within the code. In my experience with quite a few display samples some codes use nominal values (eg. 50uS) which may need to be tweaked depending upon an individual display module the supply voltage and interface method. FWIW see my notes and examples for various interface configurations here: http://www.cpmspectrepi.uk/raspberry_pi ... gData.html
Trev.

[seanspotatobusiness]

In addition to @pcmanbob comments it may be worth checking the (fixed) timings for E-strobe lengths, delays etc. within the code. In my experience with quite a few display samples some codes use nominal values (eg. 50uS) which may need to be tweaked depending upon an individual display module the supply voltage and interface method. FWIW see my notes and examples for various interface configurations here: http://www.cpmspectrepi.uk/raspberry_pi ... gData.html
Trev.

Thanks very much. I'm trying to look up information on what this e-strobe thing is that you're referring to and my searches aren't returning anything relevant. Is e-strobe known as anything else which might be more amenable to Googling? Thanks again.

[FTrevorGowen]

In addition to @pcmanbob comments it may be worth checking the (fixed) timings for E-strobe lengths, delays etc. within the code. In my experience with quite a few display samples some codes use nominal values (eg. 50uS) which may need to be tweaked depending upon an individual display module the supply voltage and interface method. FWIW see my notes and examples for various interface configurations here: http://www.cpmspectrepi.uk/raspberry_pi ... gData.html
Trev.

Thanks very much. I'm trying to look up information on what this e-strobe thing is that you're referring to and my searches aren't returning anything relevant. Is e-strobe known as anything else which might be more amenable to Googling? Thanks again.

The e-strobe signal is that applied to the E pin of the LCD display. That may be provided by a GPIO pin directly or by a similar output on another I.C. There are various examples within my webpages. For more info see the HD44780 datasheet w.r.t. timings etc.
Trev.

[seanspotatobusiness]

Changing the sleep time in my script to five seconds did not fix the problem so I suppose it is to do with the underlying timing of the signals.

[FTrevorGowen]

Changing the sleep time in my script to five seconds did not fix the problem so I suppose it is to do with the underlying timing of the signals.

Are you using 4-bit data (D4 ... D7 on the LCD) interface, or the full 8-bits (D0 ... D7)? The latter is the default on reset and, if the LCD (controller) is not (re-)initialised to 4-bit mode will result in a garbage display similar to the timing error behaviour. (My interpretation, but not confirmed since I no longer have access to an oscilloscope, is that longer E-high times help to ensure that the data lines are stable when the LCD's controller "samples them"). Another issue I've just thought of is, since you're using pogo-pin connections, the R/¬W signal may not be stable - a Pi is rarely used to read the LCD's data (or the data-bit used as a handshake with some micro-controllers) and, unlike some, usually I2C/PC8574-based, pre-built I/Face modules, I always arrange for the LCD to be "write-only" by tying R/¬W low where possible.
Trev.

[seanspotatobusiness]

Indeed it was the timings; adding "compat_mode=True" to the initialisation parameters fixes the problem (by using slower/longer timings). Thus the code is now:

Code: Select all

import RPi.GPIO as GPIO
from RPLCD.gpio import CharLCD
import time

while True:
    lcd = CharLCD(pin_rs=36, pin_e=38, pins_data=[31, 33, 35, 37],
              numbering_mode=GPIO.BOARD,
              cols=16, rows=2, dotsize=8,
              auto_linebreaks=False, compat_mode=True)
    lcd.write_string("abcdefghijklmnop\r\nqrstuvwxyz012345")
    time.sleep(1)
    lcd.clear()
    

Thanks very much for your guidance!