Using Win7 x64, c++.
I wonder if anyone could help with setting up the usb serial port settings to communicate correctly with the screen. I'm using 2 threads, 1 solely for writing and 1 solely for reading, but I'm getting random data being returned using similar settings that I find in the examples, however It seems that even if I change the baudrate from anything other than 115200 the screen doesnt respond and ( as might be expected ) I dont get any return messages either.

The default baud rate for your GTT50A is 115200, so you are experiencing expected behaviour there. Your serial port should be setup with Handshaking set to RequestToSend, and you might try a write timeout value of 500ms or more to start.

If you let your reading thread run, are you still seeing data? If you ask the unit for an expected response, such as the Module Type (254 54), what type of data do you receive?

I understand - the device is set to 115200 and so should the com port be too. I'm new to serial communication which is why I'm sure I have something set up incorrect.
If I don't use the reading thread then the screen works as expected. My plan is to use the second thread to 'filter' for touch response codes which my app can react to.

I'll go into more detail as to how I have the app running at the moment:

I'm creating and setting the com port in the main thread using the c++ win32 code:

The main app then starts up the second thread, sends a ResetModule command and enters a wait state ( for an event signal ). In the autoexec file I;m loading and displaying a bitmap so in the 2nd thread when I receive the first 252 97 command I set the event so that the main app can be released from the wait state.Note that I give the same handle value ( m_hDevice ) to the second thread that will read the data. If I single step through the code slowly one command at a time, giving time for the data to send ( a few seconds ), then the communication seems fine, but when the app is running full speed I get problems.

For eg Using VS2010, in the second thread I put a debug break point to halt code execution just before the read command and then in the main thread I single step to the ResetModule command, the module resets as expected and if I then wait until the screen has visually reset and is displaying the main logo screen then everything is ok ie I step through the read command and I get 252 95 ( load bitmap ) and 252 97 ( display bitmap ). However under the same circumstances but I put the break point after the read command ( which will block until data is ready ) then ( ive just been testing while typing this ) it seems that some of the data is missing, im getting random sections of the numbers that should form the return message ie Id get 0 1 254 252 97 ... This then messes with the code thats expecting the data to be in a certain format - the same format as the protocol.

Any advise here would be greatly appreciated.

[EDIT] The way I'm getting the return message is to read 4 bytes, as per the protocol the first 2 bytes are 252 followed by an id byte, and the last 2 bytes make up a short word that's the following number of bytes to read for the actual return message data. But I'm not getting this when the app is running at full speed. And as you can tell if the data coming in doesn't follow the same protocol then the app goes awry.

It looks like your serial implementation is correct, but it is possible that you're having trouble with threading. If you'd like, you could confirm by running a single thread, but I think by stepping through your program you have confirmed that you are able to correctly read responses from your GTT50A.

If you can work with a single thread, I would recommend that approach, but I understand the desire to handle events like touch reporting immediately, and asynchronously. The approach used by our C# GTT Driver, which you mentioned, is to start a reader thread that continuously looks for a single byte from the serial port. Once it receives a valid byte, it starts a state machine that works to parse the next incoming bytes. When all of the bytes from a complete response are received, the parser stores a nice package in a queue, and if necessary, provides notification to a function that may be awaiting that package. Devices such as locks and wait events are used extensively to provide a measure of thread safety, as implementing threading carries the possibility of introducing unexpected behaviour.

I understand why you mention a possible problem with threading, as threading can be notorious for bug hunting. However I'm quite well versed to threading. The main application is heavily multi-threaded. I understand lock and wait events have to be used to ensure synchronisation where needed. I use them a lot in the main application. I have the complete application working with a vga touchscreen but I'd like to use GTT50A or GTT70A screen in the production machines. It's just the serial communication that I'm relatively new to.

I've now cut down my application to the bare minimum of that I explained above and is now at these simple steps: The main app sends a command to reset the module and then starts the 2nd thread. The main thread then immediately uses a wait event (WaitForSingleObject) to halt execution until the reading thread has read the expected return message, which is then used to signal the wait event in the main thread that the screen is ready to receive commands. This does happen correctly when I single step through the code, but if I let that simple sequence ( send one command, wait for the return message data ) run at full speed then the bytes for the return message are incorrect. I can reproduce this every time. I can post the code tomorrow ( Im in the UK ) to show you how simple it is?

I did initially use a single thread approach but I had the same result, hence why I'm now using what I consider a 'more correct' multi-threaded approach.

My initial path was to write some code that would work similar to your c# library, but I feel something isn't right if I can't get communication working with 1 send command and 1 receive command using 2 simple threads.
I have a GTT70A here too and I'll test my code with that tomorrow and Ill post the results.

In the meantime do you have any other thoughts on what could be happening? I assume that my c++ code controlling the com port will over-ride the settings that can be set via the windows gui in the device manager.

Indeed it seems the solution is to read one byte at a time like you described as opposed to reading a number of bytes as to how the manual would seem to suggest. As to what's causing the problem with multiple byte reads - I don't know - it may a buffering issue within the windows system or the readfile function. I'm glad I can resolve the issue and move on with the project.

Using a one byte read method I'm still getting the wrong information come through even when reading. So I'm back to square one unfortunately.
I can filter out the incorrect data using a similar parsing technique as you describe but then after a few seconds the screen slows down to a crawl. I'm updating preloaded bitmaps at 16fps.

If I've not mentioned already: during testing, I notice that if I don't use the read thread then the screen works properly within my multithread app. The app uses appropriate locking to prevent writing to the serial port ( to the screen ) from multiple threads at once. Last weekend I left the screen running ( a long weekend ) as a test for my multithreading code sending data to the screen. Bear in mind that the read thread does just reading only - nothing else; no other interaction at all other than reading.

[edit] Ive stripped the app down to the bare bones with one thread synchronously writing and the other thread synchronously reading. If I don't use the read thread then everything is ok.
The main app is still using a mutex even though the commands are issued synchronously, and the issue is still there.

Its almost as though the com port settings or the device settings aren't correct for async read and writes?