Matrix Orbital Corp

This is in regards to the GLK24064-25 LCD.

I have written some routines to draw a series of rectangles / solid rectangles and this is what I have noticed:

The "Draw Solid Rectangle" (FE78) Routine is really slow. Any info you can give me on this?

Is this common across all your product line? Product of the PIC micro-controller (8mhz Right?)

Hello...

Unfortunately this is a limitation between our firmware and the LCD. A bunch of different variables reduce the speed at which data can be processed on both ends. For the time being, this is the optimal speed...

It could be faster to upload black block bitmaps and recall them where you need them. Have not tried this, but it does not need the math, so it might be quicker.

Im trying to get Flow Control To work on my LCD: GLK24064-25.
Up until today, I have had great success with it. I wrote a new algortihm to handle changing a delay(x); value based on the feedback from the Flow Control functionality: my algorithm works as follows:
The problem isnt with the code, but for some reason, Im not getting any characters returned when I enable flow control. Theres nothing to read on the serial port. No characters are being returned to me to indicate FF or FE (empty / full). This is weird because everything was working yesterday? Do I need to reset something on the LCD? Have I done something inadvertantly?

Also, what would you reccomend I set the HighWater / LowWater mark too?
The LCD buffer is 96 bytes.

Hard for me to determine what the problem was, but in order to rectify it I had to perform the manual override procedure.

*shrug

Its a little difficult for me to debug a proper implementation of this software flow control. Let me make sure I have this described correctly.

1.) The buffer on the LCD is 96 Bytes
2.) If I Enable Software Flow Control the Following will happen:
a.) If the buffer has only [FULL] Bytes remaining the LCD will return an 0xFE character.
b.) If the buffer has only [EMPTY] Bytes remaining the LCD will return an 0xFF character.
3.) Thus, if I wanted to maintain my buffer, I would want to set the following. so the message I send to enable flow control would be:
FE 3A (1E) (4C)

Is there code anywhere I can look at for an implementation of flow control? What do you reccomend I do when the buffer is in the FULL Region?.

OS: N/A
Programming Language: C
Compiler: n/a
Display: Any Display with flow controll

This example is for displays that use flow controll (software handshaking)

CODE:

//
// 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);

}





OUTPUT:

None to display, and empty or full command back to host.

Thanks to Steve Wagner for this example

Yeah, thats what my intialisation code looks liek already, but as I said, somehow the LCD got into a state where I would be in FLow Control Mode, and no Flow Control Bytes (FE / FF) were being returned, getting me stuck on a blocked read. In order to rectify the situation I had to "Manually Ovveride" the LCD settings (using the jumper), my software worked fine after that.

My question would be specific too handling a "flow control" return code of "Near Full". What would you reccomend the application do? Delay for a certain time? That time would be dependant on what operations you were trying to perform. If I filled up the buffer with "SOLID RECT" commands that filled the screen, those are lengthy operations, and my delay would have to scale to handle that.

Im only running the LCD at 19200 right now, but even then I notice a slow down if I run full speed, even with a 50ms delay between calls, the LCD can slow down dramatically.

Im getting aroudn it, but, I was jsut wondering if someone has come across / solved the problem already with a hardened implementation of Flow Control.