GLK: Default Flow Control Values

LK/ELK/VK/PK/OK/MX/GLK/EGLK/GVK/GLT Series

Moderators: Henry, Mods

Post Reply
vedavis
LCD Geek
Posts: 21
Joined: Wed Jul 02, 2008 5:24 am

GLK: Default Flow Control Values

Post by vedavis »

I am trying to re-create an off-the-shelf condition for the GLK24064. The command 'Turn Flow Control On' (0xFE 0x3A) has two parameters: almost full and almost empty. Can you tell me what are the default values for these two bytes?

EDIT: Ignore the above question...I see that Flow Control is default off. The paragraph below is still valid.

I am also noticing an anomaly that may or may not have been seen before because I may communicating to the display in an obscure manner. I am using the command 'Drawing a Bitmap Directly' (0xFE 0x64) to draw an entire screen-filling bitmap (240 x 64, 1920 bytes) at 115,200. I would expect that with flow control on that the XOFF/XON (0xFE/0xFF) would regulate the data flow to prevent buffer overflow. What I am noticing is that XOFF/XON characters appear AFTER the transmission completes, as though the on-board processor wants to send XOFF to the host, but can't because another input character has been detected. (BTW, I'm glad this is the way it works.) I was able to create a workaround by delaying every 512 bytes, in which I never see the XOFF's. I just wanted to point this out; it's not a problem to me because the workaround works.

Thanks, Vernon.
---------------
Vernon Davis
Thwing-Albert Instrument Company
vdavis@thwingalbert.com

Clark
Matrix Orbital
Matrix Orbital
Posts: 881
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Post by Clark »

Hi Vernon,

The default almost full value is 5, almost empty is 123; keeping in mind the value references how much space is left in the display buffer. But, of course, flow control is off by default.

Flow control works as a flag only, the display will not stop accepting data until the buffer fills completely, so the onus is on the host to regulate data appropriately. The flag works on a less than relationship, so pushing in a byte that results in only 5 left in the buffer (default settings) will warrant no response, but the next byte will result in the almost full response. The display will always continue to chew through the data in the buffer, but flow control is handy to let you know when it may be time to slow down or speed up the rate at which information is provided.

If you are having trouble with flow control, the old fashioned solution will be to add delays as mentioned. This will be a trial and error process, but remembering the buffer is 128 bytes in length, and knowing basic testing here indicates it takes about 146ms to draw a closely sized 192x64 bitmap from memory may help.

~Troy
Troy Clark
Design & Development
Matrix Orbital

vedavis
LCD Geek
Posts: 21
Joined: Wed Jul 02, 2008 5:24 am

Post by vedavis »

vedavis wrote:
I am also noticing an anomaly that may or may not have been seen before because I may communicating to the display in an obscure manner. I am using the command 'Drawing a Bitmap Directly' (0xFE 0x64) to draw an entire screen-filling bitmap (240 x 64, 1920 bytes) at 115,200. I would expect that with flow control on that the XOFF/XON (0xFE/0xFF) would regulate the data flow to prevent buffer overflow. What I am noticing is that XOFF/XON characters appear AFTER the transmission completes, as though the on-board processor wants to send XOFF to the host, but can't because another input character has been detected. (BTW, I'm glad this is the way it works.) I was able to create a workaround by delaying every 512 bytes, in which I never see the XOFF's. I just wanted to point this out; it's not a problem to me because the workaround works.

Thanks, Vernon.
Well, it appears that I may have spoken too soon. The batch of GLK24064-25-GW displays that we have received from a vendor is displaying garbage because of the overload of data, although there is no garbage with the display that I tested with. There is probably nothing you can do, but can you confirm that the XOFF/XON does not work under the conditions as quoted above?
---------------
Vernon Davis
Thwing-Albert Instrument Company
vdavis@thwingalbert.com

Post Reply