LK204-7T-1U HW Flow control
Posted: Thu Jun 20, 2013 8:49 am
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.
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.