GLK24064-25 wide voltage LCD connection problems

JoeCool · Post by **JoeCool** » Thu Feb 07, 2002 11:03 am

The problem is that when I fprintf() a lot of characters to the LCD, it will act as though a clear screen command was issued somewhere in the middle of it (my guess is buffer overflow) and then continue printing the characters from that point on.

The connection is set to 115200 bps. I haven't tested other speeds to see if it makes a difference.

Here is the code I'm currently using (broken out from a loop)... frame is a list of *.m3u file names. (Sorry for the use of C in the hardware forum)

Code: Select all

 row = 0;
col = 0;
//while (row < 2) {
while ((frame[row][col] != 0) && (col < WIDTH-1)) {
  fprintf(lfp, "%c", frame[row][col]);
  col++;
}
col = 0;
row++;
fprintf(lfp, "%c%c%c%c", 0xFE, 71, 1, row+1);

while ((frame[row][col] != 0) && (col < WIDTH-1)) {
  fprintf(lfp, "%c", frame[row][col]);
  col++;
}

col = 0;
row++;

Up to that point, it works great. However, if I tack this line:

Code: Select all

 fprintf(lfp, "%c%c%c%c", 0xFE, 71, 1, row+1);

...on the end of it, all that ends up getting printed on the LCD is a "u" in the upper-left corner (from the .m3u).

I bought my GLK24064 graphic LCD a couple years ago and have fought with this problem since I began programming it in Linux not long after that time. I once waited on hold on the tech support line for 2 hours then got disconnected right after the phone was answered.

This is really throwing a monkey-wrench into my car mp3 player project. Thanks.

JoeCool · Post by **JoeCool** » Thu Feb 07, 2002 11:07 am

BTW, the exact contents of frame is this:

row 1: Christian Rock.m3u
row 2: Handel's Messiah - Soulful.m3u
row 3: Life is good.m3u
row 4: New Stuff.m3u
row 5: Peaceful.m3u
row 6: Praise and Worship.m3u
row 7: The Very Best.m3u

Were it a perfect world, those would all display with no problems.

Oh, and I'm currently using a font that is 40 chars wide and 7 rows high.

JoeCool · Post by **JoeCool** » Thu Feb 07, 2002 11:48 am

btw, just so it's clear that it's the serial port/LCD, I inserted a sleep(1) function (delays 1 second) after every line and all rows displayed properly.

This is a showstopper for me. I need a fix.

ctimmer · Post by **ctimmer** » Fri Feb 08, 2002 2:12 pm

You seemed to have answered your own question and your test support this. You are having buffer overflow problems.

Solutions:
1. If you don't want to throttle you application, run at a very low bps rate.

2. Place waits after sending a reasonable number of characters (less than the buffer size). It is a little more complicated that just counting characters. Certain actions can cause a much higher overhead reducing the throughput the display is able to handle. In my own experience with LCD's and regular terminals, these actions cause the most display overhead. Ranked from the worst.

CLEAR SCREEN
SCROLL
LINE INSERT
CURSOR POSITIONING
CHARACTER INSERT
CHARACTER OVERWRITE (much higher if it causes a scroll)

I have left out any file type operations. This order may not be exactly correct but it should give you an idea what to watch out for.

3. Implement flow control if it's available on this type of display.

In days of old, sending nulls accomplished the same effect as application controlled delays and didn't require your application to be able to pause for brief perions of time. I don't know if MO displays work this way.

MO - It sure would be nice if you published some timing tests on you displays.

<font size=-1>[ This Message was edited by: ctimmer on 2002-02-08 16:24 ]</font>

<font size=-1>[ This Message was edited by: ctimmer on 2002-02-08 16:25 ]</font>

JoeCool · Post by **JoeCool** » Fri Feb 08, 2002 9:49 pm

Well, I've found that to send 40 chars/line, a usleep(90000) (90,000 microseconds) seems to be as fast as I can go after writing any line. The problem with this is that this creates a noticeable scroll as the screen wipes... it's not pretty. I had it at 45,000 microseconds, which wasn't too bad, but when I started writing a ton of text to the screen at a time, I had to slow it down to 90,000.

Is this because I'm writing a char at a time vs. an entire line? Is there any way to take full advantage of the 115kbps I'm supposed to have at my finger-tips (why advertise that if it can't be practically delivered)?

I don't mind pulling down the serial port speed a little if it will stabilize it, but I want to avoid any flicker. I'm still working on being able to program a char overwrite vs. a char insert (the latter requiring a clearscreen to re-write everything).

Live and learn, I guess. I just expected more from a $200 piece of hardware.

ctimmer · Post by **ctimmer** » Tue Feb 12, 2002 12:36 pm

If I had looked a little closer at your post I would have seen that you have the same LCD that I have.

I have buffer overrun problems at the standard 19.2 bps rate. Try putting a short delay after moving the cursor to the next line. Also put a longer delay after the display clear. I just had to experiment with the delay times until the LCD would refresh reliably.

This worked for me.

JoeCool · Post by **JoeCool** » Wed Feb 13, 2002 9:03 am

So slowing down the display is the only fix then? ugh, ok. I would've thought for a display as expensive as this (I think I paid $250-280 2 years ago), they could've at least doubled the buffer size.

I'm still fighting other display issues in my code. It would be nice if this one weren't in the mix.

Post by **Henry** » Tue Feb 19, 2002 11:08 am

The GLK24064-25 has a 92byte buffer and can process a character every 2.5ms and display 25 characters per 50ms +/-. It also depends on the size of them the characters. These numbers are for small filled font. So it's really all in the optimizing of the code. Graphic displays are not as fast as the alphanumeric, we all know that, but they can do more. So it's really taking the code optimizing it and using buffer return status mode as well.

Post by **Henry** » Mon Feb 25, 2002 1:32 pm

Some flow controll code...

Code: Select all


//
// display class
//
// Contains methods for writing the display.
//

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <termios.h>
#include <assert.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/ioctl.h>

#include "global.h"


int			fdDisplay;

BOOL displayOpen()
{
	struct termios		settings;

	// open port
	//
	fdDisplay = open("/dev/ser1", O_RDWR);
	assert(fdDisplay > 0);


	// set baudrate, XON/XOFF 
	//
	tcgetattr(fdDisplay, &settings);
	settings.c_ospeed = B19200;
	settings.c_ispeed = B19200;
	settings.c_cc[VSTART] = FLOW_EMPTY;
	settings.c_cc[VSTOP] = FLOW_FULL;
//	settings.c_iflag |= IXOFF;			// don't use this flag
	settings.c_iflag |= IXON;
	tcsetattr(fdDisplay, TCSANOW, &settings);

	displayFlowOn();

	return TRUE;
}


void displayFlowOn()
{
	unsigned char	cmd[16];

	cmd[0] = 254;
	cmd[1] = 58;
	cmd[2] = 32;		// at 32 bytes, send 'full'
	cmd[3] = 16;		// down to 16, send 'empty'
	displayWrite(cmd, 4);
}


void displayWrite(unsigned char *buf, int len)
{
	write(fdDisplay, buf, len);
}