Flow control parameters?

[Dormouse]

I'm in the process of programming my GLK24064-25, and so far it's going well. Thanks guys, great product! It has a glitch that I'm trying to solve though... sometimes when I display text on it, it seems to misunderstand the commands I'm sending. The most common case is that I'll try to set the text insertion point, and instead it'll think I'm trying to draw an outline rectangle. I'm guessing this is due to the fact that I haven't tried implementing flow control yet, so I want to do so.

My question is this: what "empty/full" values should I use when I turn on flow control? I get that full has to be greater than 16 and empty has to be 96 or less, but is there some wisdom on how to pick the best values?

(And while I'm posting, do you guys think that they problem I'm seeing could be caused by lack of flow control? Or is it more likely some kind of transmission error or a defective unit or something?)

Thanks much,
-greg.

[Miles]

Hello...

It is very possible that the problem is related to flow control. I have included a quick example of implementing flow control...

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

[Dormouse]

Thanks Miles! I didn't know about tcsetattr... I bet that'll work a lot better than what I tried to do (process the 0xfe/0xff in my own code in a separate thread, etc). I'll try this out.

[Miles]

Let me know how you make out!!

[Dormouse]

Sure. I implemented what you described, although my code looks slightly different from yours because I'm working in python. I thought I got it right, but I did see one error since then... another one of those stray outline rectangles. I'll look over my code again for bugs, and maybe I'll experiment with the "full" and "empty" values a little bit too, I don't know. If I wanted to make them a little more conservative/safe, what values should I try?

[Miles]

Something conservative would definitely be a lower value...you would have to experiment to see what would work best for you!!

[Dormouse]

I haven't had much luck with this yet. I'm wondering whether my USB serial adapter doesn't do flow control correctly or something :-/. Also, I'm using a long CAT5 as a USB cable... maybe it's too long (10 feet or so), it may be introducing transmission errors. Ugh. This is giving me a headache.

In any case, let me make sure I understand the empy/full parameters... does a "full threshold" of 32 mean that the 0xfe is transmitted when (1) there are 32 bytes of data in the buffer waiting to be processed, or when (2) there are 64 bytes of data in the buffer with _room_ for only 32 more? You seem to imply #1, but the manual suggests #2. I assume the empty threshold is measured from empty though right? That is, that the 0xff is sent when there are only 16 bytes of data left waiting to be processed and 80 bytes of free space?

Thanks.

[Miles]

You said you use an USB to serial converter?? You are also correct in your analysis on how our flow control operates...!

[Dormouse]

Why, is using a USB-to-serial converter a problem? I think the one I bought is a Bytecc http://store.yahoo.com/directron/usbgmus03.html.

Also, regarding the full threshold parameter... actually, I was trying to ask a question in there . Let me try again: does it measure how _full_ the buffer is allowed to get, or does it measure the minimum amount of _space_remaining_?

[Miles]

Sorry, to answer your question...Yes, it measures how _full_ the buffer is allowed to get and not the minimum amount of _space_remaining.

[Miles]

Do you have the ability to connect directly to a serial port to run a quick test??

[Dormouse]

Not easily, no. That's part of why I've been slow making progress on this... the display is installed in my car and it's not trivial to unmount. I could do it though, and I agree with you that that might be the best next step. It might help to narrow down where the problem is: in the long cable run, in the USB adapter, in flow control, or maybe something else. What test do you have in mind?

[Miles]

Probably the first and most important, I know it'll suck, but if you can connect the display to a serial port with a shorter serial cable and avoid the converter, then we can eliminate some possibilities !! Small steps...