Trouble with Optrex 4x20 LCD module

[Brock]

I'm having trouble with an Optrex 4x20 LCD module. I have had no problems
with the 2x20 with a very similar program. It seems to ignore all "0"s in the
text string. This is using the LCDOUT command in PBP. I tried slowing down the
data with the defines, but it doesn't seem to help. If I put a pause in the main
loop, so that it can't refresh the screen data as fast, then it works... for a
while, then ignores the zeros again. Does the same thing weather in 4-bit or
8-bit mode. Strange... and frustrating! Anyone have any ideas?

[skimask]

I'm having trouble with an Optrex 4x20 LCD module. I have had no problems
with the 2x20 with a very similar program. It seems to ignore all "0"s in the
text string. This is using the LCDOUT command in PBP. I tried slowing down the
data with the defines, but it doesn't seem to help. If I put a pause in the main
loop, so that it can't refresh the screen data as fast, then it works... for a
while, then ignores the zeros again. Does the same thing weather in 4-bit or
8-bit mode. Strange... and frustrating! Anyone have any ideas?

How about seeing some code?
What are your delay defines set as? The data_us define is an 8 bit value (something that isn't explicitly specified in the PBP manual), so if you set the data_us define as 257, you'll actually only get 1 (257-256). Keep that in mind. The command_us is a word value, so anything 0-65535 is good.

Also, with all of the parallel type LCD's I've ever used, I usually keep command_us around 200, and data_us is around 50 (give or take). It's always worked for me.
Maybe you're losing power somewhere and the LCD is blanking out because of it. Contrast going south? Who knows, let's see some code!

[Dave]

Brock, Are you computing characters to send to it? Are there characters in the string that HOME the cursor? These characters take on an average of 1 millisecond and if your string of data is somewhat continuous then the display may be loosing characters.

Dave Purola,
N8NTA

[Brock]

My bad. I had the lcdout subroutine improperly exiting...

for example:

GOSUB display
disp_return: next line of code, and so on


display: LCDOUT "blah, blah, blah"
goto disp_return

I copied the code from another program, but that program had a "IF, THEN"
statement that determined what display subroutine to go to and I overlooked
the new subroutine.

Thanks for the help.

[skimask]

My bad. I had the lcdout subroutine improperly exiting...

for example:

GOSUB display
disp_return: next line of code, and so on


display: LCDOUT "blah, blah, blah"
goto disp_return

I copied the code from another program, but that program had a "IF, THEN"
statement that determined what display subroutine to go to and I overlooked
the new subroutine.

Thanks for the help.

DOH!!!!

[Brock]

By the way, I use

DEFINE LCD_COMMANDUS 2000
DEFINE LCD_DATAUS 100

for the LCD timing. If you go faster on the data, such as 50 us, then
the Optrex 4-line display will be garbled.

[skimask]

By the way, I use

DEFINE LCD_COMMANDUS 2000
DEFINE LCD_DATAUS 100

for the LCD timing. If you go faster on the data, such as 50 us, then
the Optrex 4-line display will be garbled.

Most likely, you can reduce that commandus down quite a bit, like I said, maybe 200.
The dataus at 100, sounds good enough. Maybe throw another cap across the power/ground at the LCD and see if it'll take a lower number; it might, might not, who knows.

[Brock]

Most likely, you can reduce that commandus down quite a bit, like I said, maybe 200.
The dataus at 100, sounds good enough. Maybe throw another cap across the power/ground at the LCD and see if it'll take a lower number; it might, might not, who knows.

I'll try that. Thanks!