LK204-7T-1U HW Flow control

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

Moderators: Henry, Mods

Post Reply
HoTWiReZ
LCD?
Posts: 4
Joined: Thu Jun 20, 2013 6:55 am

LK204-7T-1U HW Flow control

Post by HoTWiReZ »

Hi, I have been working with an LK204-7T-1U LCD here (I have several of the USB and serial models and would want this to work with both) and have noticed that my software (Windows 7 C++ application) sends and receives data from the LCD without issue most of the time. However, sometimes I've found that when the display updates rather quickly or when I'm interacting with my menus via the keypad (each keypress can cause the entire display to update, so this may just be the first case again) that sometimes the LCD will just display garbage for several seconds (a bunch of up arrows and other similar characters that flash up on the screen and are changed at about the rate I would expect the screen to be updating due to my app updating it). Sometimes when I send the command to change an LED's color the command apparently didn't take effect. And most recently I've found that on two units this behavior resulted in the all the codes for the keypad being changed to non-default values, rendering them inoperable from my application's point of view (since it didn't recognize any of the codes).

All of this said, my theory is that sometimes if my application is sending data to the display too quickly, maybe the hardware on the LCD can't keep up (I'm picturing a receive buffer of fixed length that maybe I'm causing to be overrun, resulting in maybe some lost bytes, which normally isn't a big deal but if they are part of a command then we could get the display into a strange state).

So, since flow control is the typical solution to this problem, I set about to try to enable hardware flow control in my application. I didn't see any indication as to this being configurable on the LCD but did see that the manual indicates "Pins five and six can be used for serial transmission hardware flow control, and are ignored for I²C communications." when referring to an extended communication connector (although the same page shows only 4 pins for that connector). I wasn't sure whether this meant the flow control was possible with the serial or USB interfaces (my assumption is that the USB model uses the same serial interface, but just behind that FTDI converter).

The questions are whether flow control is possible with this LCD, and how would I use it (what flow control is there). For reference my application is C++ and I'm communicating with the serial port using CreateFile(), WriteFile(), GetCommProperties(), GetComState(), SetCommState(), etc. Windows API functions.

Thanks for any help offered.

Raquel
Matrix Orbital
Matrix Orbital
Posts: 796
Joined: Thu Aug 19, 2004 3:37 pm
Location: MO Office

Re: LK204-7T-1U HW Flow control

Post by Raquel »

Hello,

Thank you for posting on the forum.

The problem as you described does sound like a buffer overflow issue.
Unfortunately, the LK204-7T-1U / -USB modules do not offer hardware nor software flow control features.
I apologize for the mention of 'pins five and six..' on the manual, as this does not apply to the 4-pin data/comm connector on the LK204-7T-1U, nor are connected on the FTDI converter for the LK204-7T-1U-USB module; will inform the technical writer about this.

If it is possible, and if your application can afford it, slow communication down, ie insert delays here and there to make sure that the data sent gets processed. This would be the only way to overcome the overflow issue.

I hope this helps, please let me know if you have more questions.
Raquel Malinis
Design and Development
Matrix Orbital

HoTWiReZ
LCD?
Posts: 4
Joined: Thu Jun 20, 2013 6:55 am

Re: LK204-7T-1U HW Flow control

Post by HoTWiReZ »

Hmm, ok. That may explain my difficulties with trying to enable flow control, haha!

Do you have a statistic on the rate the display can process input data? If I knew something about how many bytes per unit of time I could probably make a governor that would rate limit the sending of data. Also, it would be good to know the buffer size on the receiving end. That way, the governor would not kick in unless I exceeded the buffer size in a short time, but for cases where I'm not sending a lot of data at once it wouldn't care.

Maybe I can add some optimizations to the code I use to detect when the screen should be updated so that it optionally sends commands to move the cursor and change individual characters if that happens to take less bytes than a full screen refresh (thinking out loud).

In my initial development I quickly ran into this issue because I would refresh the screen whether it changed or not, and at 20-30 refreshes per second it quickly messed up, haha!

Thanks for the help!

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

Re: LK204-7T-1U HW Flow control

Post by Clark »

Hello HoTWiReZ,

I can confirm that the manual will be changed and I do apologize for the confusion. As for the rate of input data, our alphanumeric units can typically display data faster than the human eye can read. Experimentally, I can successfully send 160 characters, or two screens worth of data, in 6ms at 115200 baud. However, the 128 byte input buffer will quickly overflow over subsequent writes.

If you are building in your own software flow control, one strategy might be to issue a read version command after every 80 characters and await a successful response before continuing. Alternatively, you might consider decreasing the refresh rate or using move cursor commands to update only affected values.

Thanks,
Troy
Troy Clark
Design & Development
Matrix Orbital

Post Reply